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

    Site-to-Site VPN: accept shared key for any IP

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 746 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.
    • C Offline
      CHfish
      last edited by

      Hi

      Disclaimer: I know the setup is problematic, but I can't change it at time.

      I have a 3rd party device behind NAT connecting to my pfSense instance for a site-to-site VPN.
      The public IP associated with that device keeps changing due to a flappy internet connection.
      Because the device is behind NAT it does not immediately update the DynDNS record.

      Knowing the security issues, how can I configure pfSense to accept an IPSec tunnel from any IP (if the peer identifier and of course the PreShared-Key matches)?
      At the moment pfSense doesn't find a matching key once the IP changed (and the DynDNS record has not yet been updated)

      Thank you

      1 Reply Last reply Reply Quote 0
      • M Offline
        mikee
        last edited by

        Hi.

        You are requesting to configure a dynamic endpoint. You should be able to achieve this by using 0.0.0.0 as the IP of the remote endpoint. This should allow ANY remote IP to connect.

        Anyway with this value the tunnel will only be able to be started from the remote side because we (the local side) do not know where to talk to. The VPN will be down until traffic from the remote side fires the VPN up.

        Cheers.

        1 Reply Last reply Reply Quote 0
        • C Offline
          CHfish
          last edited by

          @mikee:

          Hi.

          You are requesting to configure a dynamic endpoint. You should be able to achieve this by using 0.0.0.0 as the IP of the remote endpoint. This should allow ANY remote IP to connect.

          Anyway with this value the tunnel will only be able to be started from the remote side because we (the local side) do not know where to talk to. The VPN will be down until traffic from the remote side fires the VPN up.

          Cheers.

          How could I miss that, thank you very much!

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