Active Phase 2s do not match traffic flowing across tunnel



  • tl;dr: When I ping a host across two IPSEC tunnels, Active Phase 2's do not match Source IP but State in States Table does.

    I have three "locations" connected via IPSEC:

    AWS VPC <---> Office <---> Vendor

    • AWS VPC: 172.31.0.0/16
      • Uses AWS VPN Tunnel (probably same IPSEC daemon that pfSense uses, no access to logs)
      • Route: 172.16.0.0/16 via Office IPSEC Tunnel
      • Route: 31.0.10.11/32 via Office IPSEC Tunnel
    • Office: 172.16.0.0/16
      • pfSense
      • Route: 172.31.0.0/16 via AWS IPSEC Tunnel
      • Route 41.0.10.11/32 via Vendor IPSEC Tunnel
        • Vendor IPSEC Tunnel NATs our requests to 192.168.1.1/32
    • Vendor: 41.0.10.11/32
      • Cisco ASA
      • Route: 192.168.1.1/32 via Office IPSEC Tunnel

    I have two hosts:

    • Office: 172.16.10.41
    • AWS: 172.31.29.196

    If I ping from Office 172.16.10.41 to 41.0.10.11:

    • I see correct Phase 2 come up on Office pfSense from 172.16.0.0/16 to 41.0.10.11/32
    • I see appropriate state under Diagnostics > States

    If I ping from AWS 172.31.29.196 to 172.16.10.41:

    • I see correct Phase 2 come up on Office pfSense from 172.31.0.0/16 to 172.16.0.0/16
    • I see appropriate state under Diagnostics > States

    If I ping from AWS 172.31.29.196 to 41.0.10.11 though it gets weird:

    • Ping succeeds
    • Correct state is present in States table
    • Incorrect Phase 2 is shown as active: 172.16.0.0/16 (Office not AWS) to 41.0.11.10/32
    • I can see Traffic counters increasing on this Phase 2 entry
    • AWS Phase 2 172.31.0.0/16 to 41.0.11.10/32 does not activate
    • If I stop Ping Traffic counters stop increasing
    • In IPSEC log I can see CHILD_SA being created for Office Subnet via NAT to Vendor IP which does not match states:
      • 15[IKE] <con4000|2624> CHILD_SA con4001{35063} established with SPIs cbdd9379_i abc05d77_o and TS 192.168.1.1/32|172.16.0.0/16 === 41.0.11.10/32|/0

    Arguably, it works so I could ignore it, but the behavior does not make sense. 172.16.0.0/16 does not overlap with 172.31.0.0/16. So why is it doing this?

    pfSense is 2.4.4-RELEASE-p1 on QEMU VM


Log in to reply