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

    Old states being used after IPSEC comes up

    Scheduled Pinned Locked Moved IPsec
    4 Posts 2 Posters 921 Views
    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.
    • K
      Konan
      last edited by

      I'm having an issue with routes via WAN interface being present after an IPSEC VPN is established with the remote IP in the policy.

      That's a terrible explanation so I'll try and give the actual example.

      Local subnet is 192.168.1.0/24
      SIP phone is set with an account on 192.168.2.100
      IPSEC VPN is down (WAN connectivity, maintainence etc)

      Phones are still trying to make connections to 192.168.2.100:5600 (UDP) and follow the default route via WAN (and NAT)

      IPSEC then comes up.

      The state remains alive and is used until I manually kill it. The phone then begins to route via IPSEC

      In other firewalls I'd usually create some kind of policy route that dictated the next hop destined for the remote subnet should always go via IPSEC but I'm not seeing a way to do that with gateway rules. I'm assuming there's no script on IPSEC establishment that kills states relating to the remote subnet.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        The only way that should be possible for traffic matching the SPD is if it was initiated before IPsec was configured. Traffic matching the SPD will never leave WAN regardless of whether or not the VPN's up, it triggers it to try to connect and is dropped if it fails to connect. There's no way to kill states or policy route that traffic, as it's never been necessary.

        I'm guessing that connection was established before you'd configured the VPN?

        You can add floating rules, quick, direction out, on WAN that blocks traffic destined to 192.168.2.0/24. But with IPsec that should never be necessary.

        1 Reply Last reply Reply Quote 0
        • K
          Konan
          last edited by

          Thanks for your reply.

          I've observed this behaviour after a prolonged outage on the WAN of the remote site, no configuration changes were made to the VPN at any point. However, I think I need to take the time to try and recreate the circumstances as I observed this during a break-fix situation, so may have overlooked something in my efforts to get the affected systems up asap.

          I will try to come back with more detail.

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Hm, might be some edge case there where somehow the SPD isn't populated. If strongswan's running at all, it'll have that populated though. I can't think of any circumstance where that could occur. Definitely would be interested in steps to replicate if you come across something.

            If IPsec were disabled for any period of time during troubleshooting, that could explain it.

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