Bridge and Translation Address causes pfSense to freezz
-
OK. I also started a ticket with some info from when I hit it last week, if you can provide any other input/observations over what I have in there already, I can add them.
http://redmine.pfsense.org/issues/910
-
Could you maybe explain how we should setup it up, if we are going with the routing mode.
What are the pro/cons of that choise?
-
You'd just move items in the DMZ to a separate subnet from those in WAN.
If you have a large enough WAN subnet and control of how it hits your network, you could split what you have into two smaller subnets and use some in the DMZ also.
There isn't anything fancy about that kind of setup, it's a standard CARP+DMZ setup. Each unit would need an IP in the new subnet, plus one shared CARP VIP to act as the gateway for the DMZ items.
Routing it is much cleaner, you won't have to worry about bridging or not being able to reach LAN, and failover is known to work flawlessly in that scenario.
Alternately, you could try two pairs of routers. A CARP HA setup for LAN, and a separate CARP HA setup that bridges that doesn't involve NAT (if that does turn out to be the problem).
-
We have a C-class provide from our co-location company.
The IP xxx.xxx.xxx.1 is the gateway provided from the co-location company.
We need to route rest of IP's to the DMZ. Are there an how-to, where it explains how to setup this in a HA enviroment.
-
Not sure if there is a how-to, some of that is covered in the book.
If many of your things will be in the DMZ, you might split that up into two /25's and have your ISP adjust their side, and route the higher IPs to your WAN CARP VIP, so you can use them internally.
The subnetting could get a bit trickier if you need more than that, and might involve some other changes on the ISP side as well.
-
I have following in my network:
One /24 subnet
One /26 subnet
One /29 subnetCan i then use the /24 subnet for the DMZ and ie. the /29 subnet for the WAN? Without having the ISP to do anything?
-
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.
