Redundant pfSense, NAT and Multiple WAN Interfaces

Rhongomiant

I am going to be in a situation soon where I have multiple WANs in a redundant pfSense cluster with NAT. I would like to dispell as much of my confusion related to this type of setup as possible. I assume that using gateway groups non-NAT should be simple and straight forward. My concern is the setup related to having redundant pfSense firewalls and NAT as I do not believe NAT will be quite so straight forward in this setup due to outbound NAT.

With a redundant pfSense setup, the WAN interface on each pfSense device gets a unique IP in the WAN subnet and a CARP IP in the WAN subnet is configured which is shared between the firewalls. For NAT to work properly when a failover occurs an outbound NAT rule is configured so that outbound traffic is sent using the WAN CARP IP. My confusion is with outbound NAT with multiple gateways. If a CARP IP for each WAN and an outbound NAT rule for each CARP IP, I assume that first matching will apply and all NAT traffic will flow through the CARP IP in the first applicable outbound NAT rule. While this is not desired and perhaps not terrible in a load balanced situation, it would be disastrous in a WAN failure situation.

I would like to know if my concern is valid and if there is a way to work around this issue.

If my concern is not valid, I would like any technical details that explain why my concern is not valid. e.g. Basic Reason: When outbound traffic is sent to a specific gateway, determined by a gateway group, the outbound NAT rules for an IP on that subnet are the only rules considered. Along with technical reason if you like.

Thank you for any assistance.

jimp

Each WAN should be on its own interface, e.g. WAN1 and WAN2, as with a normal Multi-WAN. They can be named whatever you want, but I'll call them WAN1/WAN2.

So you end up with CARP VIP(s) on WAN1 and some CARP VIP(s) on WAN2.

Your existing outbound NAT rules are mapping to a VIP on WAN1 right now.

Your new rules would be on WAN2, mapping to your CARP VIP there.

The rules don't conflict because they are on different interfaces. It doesn't matter what order they're in since the interface it different. For example, it can't match a WAN1 NAT rule as it's leaving WAN2.

So just duplicate your NAT rules, set them to the WAN2 interface, set the translation address to be the WAN2 CARP VIP, and that's it. The rest is the same as any other multi-wan setup.

Rhongomiant

jimp,

Thank you for the reply. If I understand what you have said, this is how it works. I setup a gateway group with two or more WANs and add this gateway group to a rule. When traffic is sent to a particular gateway, if there is an outbound NAT rule to use a particular IP on the interface that can sent traffic to that gateway, then that is the outbound NAT rule that will be used.

Is my understanding correct?

Thanks again!

jimp

Yes.

Reiner030

Hi problem… outbound NAT didn't work actually ?

I upgraded some houres ago from
amd64-20130114-1125.iso (outbound NAT was working)
to the lastest version
20130128-1655 image
and an hour ago to next latest version
built on Tue Jan 29 09:31:46 EST 2013

but there is outgoing NAT anymore working...

When I ping for instance checkip.dyndns.org I get on the outgoing interface this try wich can't be public routed:

21:10:14.212273 IP 192.168.45.16.36231 > 216.146.39.70.80: Flags [s], seq 53736575, win 5840, options [mss 1460,sackOK,TS val 902965905 ecr 0,nop,wscale 7], length 0

Perhaps it has something todo with my today new notifies:

[code][ There were error(s) loading the rules: /tmp/rules.debug:235: syntax error - The line in question reads [235]: pass out route-to ( <outgoing interface="" with="" default="" gw)="" <isp="" gateway="">) from to !/112 keep state allow-opts label let out anything from firewall host itself][/code]

/112 is network mask of my IPv6 transfer network (I try to setup BGP routing)

so I must try a rollbacks to last functional version :(

Bests

Reiner[/s]</outgoing>

eri--

Should be fixed on next coming snapshots.

Reiner030

@ermal:

Should be fixed on next coming snapshots.

OK thx… if it helps... "pure" NAT broke between snapshot Jan-25-11:45 and Jan-25-17:45 ...

NAT with gateway groups broke somewhere after 22th 05:55 image

Bests