Bug/Issue with NAT 1:1 rule operation on IPsec interface

HunterWare

I think there is a bug with the proper processing of NAT rules with regard to IPsec tunnels.

Basically I'm looking to allow NAT'd IPsec access from site A to a server at site B that is hiding behind 1:1 NAT of a public IP address. Here is a simplified configuration which I setup using 2 pfsense boxes and a linux host. This is the simplest config that I can show that illustrates the failure of NAT 1:1 reflection rules applied to an IPsec interface.

General Config Site A:
Public IP: a.a.a.a
LAN subnet: 192.168.0.0/24
Local IPsec NAT IP: b.b.b.b

General Config Site B:
Public IP: c.c.c.c
LAN subnet: 10.0.0.0/24
Actual IP of server: 10.0.0.10
"Public" IP of server: d.d.d.d

IPSec configuration:
SiteA: IPsec tunnel "to B"
V1, IPV4, LocalGW: a.a.a.a, RemoteGW: c.c.c.c
Mutual PSK, Main, IP IDs, "TestLinkKey"
AES 128, SHA1, DH2 (1024), 28800
Auto NAT

Phase 2:
Tunnel, Local: LAN Subnet, NAT IP: b.b.b.b, Remote: d.d.d.d
ESP, AES 128, SHA1, PFS 2 (1024), 3600s lifetime

SiteB: IPsec tunnel "to A"
V1, IPV4, LocalGW: c.c.c.c, RemoteGW: a.a.a.a
Mutual PSK, Main, IP IDs, "TestLinkKey"
AES 128, SHA1, DH2 (1024), 28800
Auto NAT

Phase 2:
Tunnel, Local: d.d.d.d, Remote: b.b.b.b
ESP, AES 128, SHA1, PFS 2 (1024), 3600s lifetime

SiteB NAT config:
NAT 1:1 rule
Interface: IPsec
External: d.d.d.d, Internal: Host, 10.0.0.10
Enable reflection

Symptoms:

When you attempt to connect to d.d.d.d from Site A, you get proper packet flow through Site A IPsec NAT, through the tunnel, and the redirect will forward the packets to 10.0.0.10. The response packets from 10.0.0.10 will not, however, return properly. If you dump packets on the Site B WAN interface you will find that the servers response packets (10.0.0.10->b.b.b.b) are coming out there. It looks like the reflection rule is not being hit because the response packets are never going to the IPsec interface.

In this case I would submit that for proper operation the Site B pfsense box needs to see the IPsec NAT 1:1 rule and therefor setup an additional internal rule that scoops 10.0.0.10->b.b.b.b traffic into the IPsec tunnel. Then the outgoing NAT reflection rule would happen and proper flow would occur.

Temporary work around, and why it isn't a viable solution:

You can create a second Phase2 config on each site like this.

SiteA Phase 2:
Phase 2 #2:
Tunnel, Lan Subnet, NAT IP: b.b.b.b, Remote Subnet: 10.0.0.0/24
ESP, AES 128, SHA1, PFS 2 (1024), 3600s lifetime

SiteB Phase2:
Phase 2 #2:
Tunnel, Local: Lan Subnet, Remote: b.b.b.b
ESP, AES 128, SHA1, PFS 2 (1024), 3600s lifetime

This gives the Site B pfsense box the proper setup to vacuum up 10.0.0.10->b.b.b.b packets and place them on the IPsec interface. Proper packet flow will now occur in both directions, and connections work fine.

The problem with this work-around is that you have now leaked the local subnet information of SiteB into SiteA's phase2 config, and thus into it's rules and routing. The whole point of NAT'ing to a public IP on the other side is to allow sites with possibly overlapping local IP ranges to connect.

On a side note: it would also be nice if it were possible for b.b.b.b (Site A NAT IP address) to respond to pings so that Site B would have a clean way to test if the tunnel is up.

I think this problem has hit several other people based on forum searches, but I haven't seen the realization of where the packets were actually going in the failure case. I also haven't seen proof that proper operation is possible with the work-around, given the caveat that the work-around is improperly leaking unnecessary private subnet information between the sites.

I hope this all made sense. =)

Quirinius

As far as I understood this topic covers the same issue:

https://forum.pfsense.org/index.php?topic=114095.0

And yes: it's really nasty.

dotdash

That other thread is a year old, and the OP never replied back. Doesn't sound like a bug.
As for this thread, you need to NAT BOTH sides of the tunnel? You are using the phase2 NAT/BINAT at site A and a custom rule on side B?
I can't figure out if your bbbb and dddd are addresses or subnets and I'm unclear what you mean by saying dddd is 'public'.