IPsec site-to-site tunnel with SonicWALL - tunnel is active but can't ping. Packets only travel in one direction.

  • Greetings, I was hoping someone could give me some quick pointers on setting up a site-to-site IPsec VPN between:
    -(site A) pfSense
    -(site B) SonicWALL

    Everything is set up and the tunnel is showing as active on both the pfSense and the SonicWALL.

    I am not able to ping any devices at site A from site B, nor can I ping any devices at site B from site A.

    -Pings originating from site A (pfSense) do not increase the packets out count
    -Pings originating from site B (SonicWALL) DO increase the packets out count on the SonicWALL, and also increase the packets in count on the pfSense.

    SonicWall settings

    General tab on Sonicwall:
    Authentication Method: IKE using Pre shared Secret
    Name: IPsec Tunnel to pfSense
    IPsec Primary Gateway Name or Address: <WAN IP of pfSense>
    IPsec Secondary Gateway Name or Address:
    Shared Secret: <SECRET>
    Local IKE ID: IP Address = WAN IP of SonicWALL
    Peer IKE ID: IP Address = WAN IP of pfSense

    Network tab on Sonicwall:
    Choose local network from list: LAN Subnets
    Choose destination network from list: Remote Translated (Address object Network / VPN / /

    Proposals Tab:
    Exchange: Aggressive
    DH Group: Group 2
    Encryption: 3DES
    Authentication: SHA1
    Life Time (seconds): 28800

    Protocol: ESP
    Encryption: 3DES
    Authentication: SHA1
    Enable Perfect Forward Secrecy: Checked
    DH Group: Group 2
    Life Time: 86400

    Advanced Tab:
    Enable Keep Alive: Checked
    Apply NAT Policies: Checked
    Translated Local Network: Local Translated (Address object Network / LAN / /
    Translated Remote Network: Remote Translated (Address object Network / VPN / /

    pfSense settings

    Phase 1:
    Key exchange version: IKEv1
    Internet Protocol: IPv4
    Interface: WAN

    Authentication method: Mutual PSK
    Negotiation Mode: Aggressive
    My identifier: <WAN IP of pfSense>
    Peer identifier: <WAN IP of SonicWALL>
    Pre Shared Key: <SECRET>

    Encryption Algorithm: 3DES
    Hash algorithm: SHA1
    DH key group: 2
    Lifetime: 28800

    Nat Traversal: Auto
    Dead Peer Detection: Checked

    Phase 2:
    Mode: Tunnel IPv4
    Local Network:
    Remote Network:

    Protocol: ESP

    Encryption algorithms: 3DES
    Hash algorithms: SHA1
    PFS key group: 2
    Lifetime: 84600

    NOTE: Both networks are / 24 - I feel like I may have missed some settings for translating the VPN subnets to the actual local subnets, but I am pretty new at this so I'm not sure where to look.

    Any help would be greatly appreciated as I've been working on this all day with very little success.


  • UPDATE: I appear to have gotten everything working. Funny how I can spend 8 hours working on something, post asking for help, and then figure it out myself within 20 minutes...

    For those googling: I had to add a NAT/BINAT translation to my phase 2 on the pfSense.

    NAT/BINAT translation : Network = / 24
    Local Network: Network = / 24

    I also have the following NAT policies on the SonicWALL that I think were necessary:
    Original source: X0 Subnet
    Translated source: Local Translated (same as above)
    Original Destination: Remote Translated (same as above)
    Translated destination: Original

    Original source: Remote Translated (same as above)
    Translated source: Original
    Original Destination: Local Translated (same as above)
    Translated destination: X0 Subnet

  • Only problem I'm having now is with DNS... maybe someone can shed some light.

    if I ping SERVER.SITEB.local, it grabs the local IP address of the server on site b ( and pings that. How do I get it to resolve to the VPN ip ( I will respond back here if I figure it out in the mean time...

  • My temporary solution was to manually remake all of the SITEB.local DNS entries in my local DNS (at site A) using the VPN ip addresses.

    This seems to be working fine for the most part, but I will be looking to move one of the networks to a different subnet in the near future to avoid all of these issues.

Log in to reply