How to force traffic from one LAN IP to go out from alternate IP on second WAN?

rjohnston3

We have a multi-WAN setup, using 2.3.2. Both WANs have multiple IPs associated with them.

I would like to have all traffic from one LAN IP address to be sent out (NAT to) an address on the second WAN, that is not the default address that the rest of the traffic uses.

I've tried bi-NAT, outgoing NAT, with (and maybe without) VIP, and it seems like no matter what I do, the traffic goes out using the primary (default) WAN.

It seems like I'm either doing too much or too little. Does anyone have any suggestions as to which settings are needed?

Thanks!

Derelict

You need to policy route that source IP address out the desired gateway using a LAN rule, then create an outbound NAT rule on that WAN to use the desired VIP for that source IP address.

rjohnston3

Thank you! That (plus port forwarding for the incoming traffic) seems to have done the trick. I thought I had tried that combo, but probably just did them separately.

Thanks especially for the quick reply!

rjohnston3

I spoke too soon.

It turns out that the outbound NAT is flakey, at least in the particular setup that we have.

Our setup (with bogus IPs):
WAN1: 50.1.1.2/30 - gateway is 50.1.1.1 (default route)
WAN2: 65.2.2.2/27 - gateway is 65.2.2.1
LAN: 192.168.0.1/24

IPSEC tunnel terminating on pfSense on 50.1.1.2 (from 216.3.3.3)

Trying to add IPSEC tunnel THRU the pfSense (into another device) on 65.2.2.29 (WAN2) (also from 216.3.3.3)

Added policy route and outbound NAT as suggested, as well as port forwarding 65.2.2.29:500 and 4500 to the device (at 192.168.0.9)

It worked sometimes. But most of the time it didn't.

We kept seeing an entry in the state table for the WAN1 interface, with the 65.2.2.29 IP (which should be on WAN2), but only for port 500. Doing a packet capture on WAN1 did show that a packet with a source address that should have gone out on WAN2.

After much playing around with variations on rules, packet capture, outbound NAT modes, etc., we tried disabling the IPSEC tunnel that terminates ON the pfSense box.

And everything started working fine.

So I think there is a bug, where the initial packet for building the tunnel gets sent over the wrong interface (either the default route interface, or the interface that the IPSEC tunnel is defined on).

Where / how should I report this?

Thanks!

hell bomb

I don't think this is a bug, I am at work and so I can't look right now, but in either the IPSEC tunnel config or the advanced system config menus there is a little check box that says automatically route traffic through IPSec tunnel which caused me a lot of headache because there is no visible rule showing this. Find that check box and uncheck it and then you can start manually routing traffic through the interfaces you want.

rjohnston3

I can't find the checkbox you mention, but I don't think that is the issue. Very, very little of our traffic goes down the tunnel (tunnel A), plus I'm seeing the following:

Tunnel A - terminates on the pfSense box. External IP is on WAN1.
Tunnel B - terminates on a device on the LAN. External IP is on WAN2. This is the one we're having trouble with.
Both Tunnel A and B terminate their other end on the same remote device.

The setup traffic for tunnel B isn't being routed down tunnel A. Instead, it seems to be using the routing table for the tunnel A setup packets (IKE/ISAKMP - port 500) to route the setup packets for tunnel B (they should go down a different interface). I'm actually seeing packets with WAN2's address being sent out on WAN1.