Bridge and Translation Address causes pfSense to freezz
-
That should work, if your Master/Back/WAN CARP VIPs are in the /29, and the /24 is completely on the DMZ (Master, Backup, and Shared CARP for DMZ)
It should work fine
-
And it would be a better solution, instead of a bridge+CARP configuration.
Are there any downsides of using the routing setup combined with CARP?
-
For at routing setup I do the following:
Subnets: xxx.xxx.183.168/29 and xxx.xxx.214.0/24
pfSense - Master:
WAN: xxx.xxx.183.171
DMZ: xxx.xxx.214.3pfSense - Backup:
WAN: xxx.xxx.183.172
DMZ: xxx.xxx.214.4CARP IPS:
WAN: xxx.xxx.183.170
DMZ: xxx.xxx.214.2WAN are using xxx.xxx.183.169 as Gateway (Provide by ISP)
Hosts on the DMZ network are using xxx.xxx.214.3 as gateway (The CARP IP for DMZ)Is that a working enviroment?
What about the IP: xxx.xxx.214.1 that are provide from our ISP as Gateway for the xxx.xxx.214.0/24 subnet?
-
Your ISP would have to stop being a gateway for that subnet. The entire 214.0/24 subnet should be routed to x.x.183.170.
-
jimp: Thanks for all your help. I have contacted our ISP.
I have found the example of setting up CARP and routing to DMZ in your book, so now I only need the ISP to make their changes.
-
By the way: What are the technically definitions of the operation our ISP has to do?
-
They would just be considered routing changes.
-
Perfect. Thanks. I was looking for it, at their self-service system.
-
Now I got it all to work. And the failover works perfect.
But when I try to traceroute a host inside my DMZ, the last HOP before the host is the gateway. But it is not the CARP IP of the WAN interface, but the IP-assigned on the interface.
The CARP is: xxx.xxx.xxx.170
pfSense1: xxx.xxx.xxx.171
pfSense2: xxx.xxx.xxx.172It is the active pfSense's interface IP, that are returned by the trace route. Is that correct?
I have checked that my ISP, are routing the DMZ subnet to the xxx.xxx.xxx.170 IP. -
The way traceroute works I think that is expected. If the IPs are really routed to the CARP VIP, I wouldn't worry about it, though if you want to be absolutely certain, you can always do a traceroute, force a failover, and try it again.
If it works both times, it's probably just a quirk of how traceroute shows up in the scenario.
