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

    Dynamic IP and remote locations

    Scheduled Pinned Locked Moved IPsec
    2 Posts 1 Posters 979 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.
    • W
      work_permit
      last edited by

      I'm attempting to create a  site-to-site VPN using IPSEC with two pfsense routers.  Each site has dynamic public IP addresses. I'm using fully qualified host names as addresses for the gateways.  Name resolution for these hostnames is provided by Dyndns.

      I'm able to successfully create a tunnel.  BUT when an IP changes on one side of the tunnel, I can only reestablish it by reconnecting from the side whose IP DIDN'T change.

      In other words, if I have a site-to-site vpn connection and the IP address of the site I am physically at changes, I need someone at the remote site to reestablish the connection (or alternatively access the firewall myself over the public network).

      Is this the expected IPSEC behavior?  If it is, how can I  maintain connections with remote locations?

      Or am I just doing something wrong?

      Here is my setup on one of the servers (I replaced my DynDNS hostname with "example.com")

      Internet Protocol: IPv4   
      Interface: WAN 
      Remote gateway:  one.example.com

      Authentication method: Mutual PSK   
      Negotiation mode: aggressive
      My identifier User distinguished name  one@example.com
      Peer identifier User distinguished name  two@example.com 
      Pre-Shared Key  xxxxx
      Policy Generation Default
      Proposal Checking Default 
      Encryption algorithm AES  256 bits 
      Hash algorithm SHA1 
      DH key group 1 (768 bit)
      Lifetime  seconds  86400

      Advanced Options
      NAT Traversal Enable
      Enable DPD
      10 seconds
      Delay between requesting peer acknowledgement.

      5 retries
      Number of consecutive failures allowed before disconnect.

      1 Reply Last reply Reply Quote 0
      • W
        work_permit
        last edited by

        Things got worse.  Racoon failed to even attempt to connect.  Specifically, hitting the connect icon returned immediately and there was no record of any connection attempt in the log. Deleted the phase one and phase two entries, and re-entering them.  Seems to be working now.

        Must have been some sort of corruption in the configuration.

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