On 14-08-06 02:42 PM, Adam Williams wrote:
You've made two contradictory statements here:
1) you want to know how to *change* a WAN interface, but
2) "We're moving it over from another firewall..."
I've got two firewalls, F1 and F2, facing the public internet, each
hosting different public subnets, N1 and N2. There are computers
behind them which are dual homed - connected to both firewalls. I want
to make F2 host both N1 and N2, decommissioning F1. Then I'll
decommission N2. Since I want to decommission N2, I thought I should
make the WAN interface of F2 configured for N1.
Ouch... I'm sure I could create a more difficult setup to work with, but
it would take some time and effort to do so!
Why do you need to do things one step at a time? Again, that contradicts
#2, above.
I want to configure 87.54.0.34 (N1) on F2 before having the IP
addresses moved from F1, because of the acceptable downtime of...
about 60 seconds. Hopefully my following answers will clarify how I
think this can be done.
asdf
You also mention VRRP - pfSense doesn't do VRRP, it does CARP. Is the VRRP
from the old firewall?
It may be the uplink switches are making these VRRP advertisements. I
realize I do not understand perfectly how the protocol is implemented,
and assumed there was a relationship with CARP, though it's clear
enough now that they are different tech solving similar problems. I
suppose I need to read up on VRRP to understand why my F2 WAN address
(50.31.0.14) is the SRC address of these advertisements.
If F2 is a pfSense firewall, then you have some much larger problem to
solve before you worry about switching over to new firewalls.
Once I have the configuration I want, I will be adding another pfSense
firewall as a sync slave of F2.
I would strongly recommend starting with HA, not adding a HA peer
later. Adding HA later is much more likely to cause downtime; adding it
right away means you'll catch all the problems immediately, (hopefully)
before you put the new firewall into production.
The switches our old VLANs operated on are being replaced. There were
new VLANs created on the new switches, and the computers were made to
be dual homed for a time so I could work through getting all the
services running over the new switch VLANs/subnets. F2 is the firewall
of the new switch VLANs/subnets. Now that the computers behind the
firewalls are communicating over the new switches through F2, I'm
ready to move the IP addresses of F1 over, as I've mentioned. The ONLY
reason we need the old WAN on F2 at all is because outbound
connections to third parties must come from addresses in the old WAN.
That is happening today because the computers are still routing
Internet-bound connections through F1.
Don't bother changing WAN, add a new interface (WAN2, let's say...) and
configure it with the appropriate IP address and gateway(s), etc.
If I understand correctly, you're going to wind up with a dual-WAN
setup, right?
F1 must hold the N1 address until the last moment, since the computers
are still routing Internet-bound connections through F1, and I do not
believe I have the option of having F1 and F2 on the same uplink both
claiming the N1 address.
That's correct; they'll be fighting over the IP address (unless they are
a CARP pair, which doesn't sound likely).
If I am able to put F2 in a position where it's nearly completely
configured to host N1, such that I can have N1 moved to F2, change
outbound NAT on F2 to use the address of N1, use N1 as the default
gateway of F2, and immediately change the routing of the computers
behind the firewall so that they make Internet-bound connections
through F2, I'll be happy. If I have to move N1 to F2 before I can
configure F2 this way, downtime will be longer.
Ugh. You have set yourself a complex task; I would have simply
preconfigured a new firewall (F2) exactly the same as the existing
firewall (F1), and taken a 2-minute outage to swap firewalls.
You're almost sure to have more than 60 seconds of downtime anyway,
since ARP data typically has a 5-minute lifetime. If you can cause the
new firewall to proactively overwrite each local host's ARP cache (e.g.
by pinging each host from the firewall) then you can probably get that
down quite a bit.
--
-Adam Thompson
athom...@athompso.net
_______________________________________________
List mailing list
List@lists.pfsense.org
https://lists.pfsense.org/mailman/listinfo/list
