Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC One-way Traffic Initiation.

    IPsec
    2
    3
    7.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jank
      last edited by

      Hello all, new here and hope I can pick your brains a bit.

      Having a problem with two ipsec tunnels.

      Problem: One tunnel is able to initialize traffic from either end, while the other two can only initialize traffic from one end.

      An overview of the tunnels would look like this:

      VPN 1

      Houston (PfSense 2.0) < - - - - - > NYC (PfSense 2.0)

      VPN 2

      Houston (PfSense 2.0) < - - - - - > San Francisco (PfSense 2.0)

      VPN 3

      Houston (PfSense 2.0) < - - - - - > Miami (Cisco ASA)

      Details:

      After restarting ipsec on VPN1, pings from NYC to Houston are sent and received as expected.

      After restarting ipsec on VPNs 2 and 3, pings from San Francisco or Miami to Houston fail until they receive pings from Houston first.

      So as you can see… VPNs 2 and 3 cannot initiate traffic across the VPN until one side (Houston) intiates first.

      Also to note, the ipsec settings for both Phase 1 and 2 on VPNs 1, 2 and 3 are all the same, including inbound and outbound firewall rules.

      Any thoughts would be appreciated,

      Thanks

      1 Reply Last reply Reply Quote 0
      • J
        jank
        last edited by

        Just wanted to update this thread with some new findings.

        Found out VPNs 2 and 3 are actually able to initialize traffic from the sites I thought weren't able to but only after 3 or so minutes after restarting ipsec. VPN 1 is able to ping from either side within seconds after restarting ip sec. Not sure why there is such a delay in VPNs 2 and 3 in sending data from one side to the other rather than the seconds it takes from the other side.

        Houston < - - - - - - - - > NYC    (Can ping from either side in a matter of seconds after establishing VPN)

        Houston < - - - - - - - - > San Francisco    (Can ping from Houston to SF 10-15 seconds after ipsec restart, from SF to Houston takes 3-4 minutes for ICMP replies to come back.)

        Houston < - - - - - - - - > Miami    (Can ping from Houston to Miami 10-15 seconds after ipsec restart, from Miami to Houston takes 3-4 minutes for ICMP replies to come back.)

        All configs are the same, I even set the firewall ipsec rule on all Pfsense routers to allow all incoming traffic, but that didn't change anything.

        Prefer older IPsec SAs  is enabled but I'm not sure what that would change.

        My problem is that these VPNs are accessed on one side to resources on the other, and they're only able to if traffic is first initiated by the opposite side. It's either that or it takes forever for the traffic to finally go after an ipsec restart or tunnel establishment. A colleague suggested we set a cron job on the device they're trying to access to send pings at regular intervals to keep the tunnel alive.

        Anyway, hope this helps.

        1 Reply Last reply Reply Quote 0
        • S
          scurry7
          last edited by

          I took over this from jank (co-worker) was able to figure it out.

          needed to add a firewall rule for the other ends peer ip (public ip) to allow udp traffic to my target wan interface that the vpn traffic is coming in on.  Once I did that they were able to initialize the tunnel with a ping or any other traffic.

          i found this by going to status > system logs > firewall and searching for anything on their lan subnet then their public ip (where i found the traffic was being dropped), auto added the rule from that page and good to go ;)

          hopefully this will help someone out in the future.

          thanks

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.