Using Mobile IPSec for Site-to-Site with DHCP

mynd

I'm using pfSense 2.1.4-RELEASE (amd64)

Long story short, I am trying to use BINAT so that the traffic over the VPN uses the "external" address of the pfSense firewall, instead of the real IP of the web-server. The traffic will always be initiated from the clients to the web-server, so in theory this should work.

I'm using a single interface pfSense to create this scenario. If I create the PhaseI as a "normal" site-to-site with the PhaseII "Local Network" as the web-server and the "BINAT" as the pfSense "external" IP all is right in the world. However, creating the Mobile Client configuration, the packets are not being "unNAT'd" when they come out the IPsec interface and traverse the WAN interface.

To work around this, I have to force the real IP of the web-server across the VPN, instead of the "public" IP.

Setup:

web-server -- gw -- WAN pfSense -- WAN pfSense -- Internet router -- Internet -- DHCP VPN endpoint -- clients

PhaseI:
Interface: WAN
Authentication: Mutual PSK
mode: aggressive

PhaseII:
mode: tunnel
local network: 10.2.1.2
BINAT: 1.1.1.1 <-currently set to "none" since not "unNAT'ing"

web-server: 10.2.1.2
pfSense gw: 10.1.1.1
pfSense WAN: 10.1.1.2
pfSense public: 1.1.1.1
clients: 10.128.128.x

In all scenarios below, the VPN comes up on both sides and client's can pass traffic. However, since the BINAT is not working properly, the responding traffic is not sent over the VPN tunnel.

When trying to us BINAT with the Mobile Client config, I do a packet capture on the WAN interface and I see:

10.128.128.x -> 1.1.1.1

When doing the same using "normal" site-to-site, I see:

10.128.128.x -> 10.2.1.2
10.2.1.2 -> 10.128.128.x

I can create port forwards (1.1.1.1:80 -> 10.2.1.2:80), but the NAT'd traffic just goes back out the WAN interface (as I understand, NAT takes place after being put on the ipsec tunnel):

10.128.128.x -> 10.2.1.2
10.2.1.2 -> 10.128.128.x
1.1.1.1 -> 10.128.128.x

So because this works when creating a "normal" site-to-site IPsec tunnel where the VPN endpoint's public IP is known, I suspect this is a bug. Anyway to clarify?

–Richard