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

  • 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:
      Local IPsec NAT IP: b.b.b.b

    General Config Site B:
      Public IP: c.c.c.c
      LAN subnet:
      Actual IP of server:
      "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,
            Enable reflection


    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  The response packets from will not, however, return properly.  If you dump packets on the Site B WAN interface you will find that the servers response packets (>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>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:
          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>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. =)

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


    And yes: it's really nasty.

  • 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'.

Log in to reply