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

    IPsec on 2.5.0 uses first VIP instead of WAN address

    Scheduled Pinned Locked Moved IPsec
    5 Posts 2 Posters 679 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.
    • H
      hansmeets
      last edited by

      Hi folks,

      I have upgraded from 2.4.5_p1 to 2.5.0 and my IPsec connection has stopped working.

      I found out that the local host address for IPsec was set to the first Virtual IP (xxx.xxx.180.187 instead of the WAN address (xxx.xxx.180.186). I've fixed it temporarily by adjusting the ID's and remote peer on the other side to the VIP address.

      swanctl:

      con2000: IKEv2, no reauthentication, rekeying every 25920s, dpd delay 10s
        local:  xxx.xxx.180.187
        remote: xxx.xxx.180.170
        local pre-shared key authentication:
          id: xxx.xxx.180.186
        remote pre-shared key authentication:
          id: xxx.xxx.180.170
      

      swanctl.conf:

      local_addrs = xxx.xxx.180.187
                      remote_addrs = xxx.xxx.180.170
                      pools =
                      local {
                              id = xxx.xxx.180.186
                              auth = psk
                      }
                      remote {
                              id = xxx.xxx.180.170
                              auth = psk
                      }
      

      ifconfig:

      em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
              description: WAN
              options=81009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER>
              ether 68:05:ca:43:e2:ac
              inet6 fe80::6a05:caff:fe43:e2ac%em0 prefixlen 64 scopeid 0x1
              inet6 2001:41f0:33bc:0:6a05:caff:fe43:e2ac prefixlen 64 autoconf
              inet xxx.xxx.180.187 netmask 0xfffffff8 broadcast xxx.xxx.180.191
              inet xxx.xxx.180.188 netmask 0xfffffff8 broadcast xxx.xxx.180.191
              inet xxx.xxx.180.186 netmask 0xfffffff8 broadcast xxx.xxx.180.191
              media: Ethernet autoselect (1000baseT <full-duplex>)
              status: active
              nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
      

      Any idea? Thanks!
      Let me know if you need more input.

      viktor_gV 2 Replies Last reply Reply Quote 0
      • viktor_gV
        viktor_g Netgate @hansmeets
        last edited by

        @hansmeets There is an open bugreport for this:
        https://redmine.pfsense.org/issues/11545

        workaround:

        • Go into the WAN interface, hit save with no changes, and Apply Changes.
        • Restart IPSec service
        H 1 Reply Last reply Reply Quote 0
        • viktor_gV
          viktor_g Netgate @hansmeets
          last edited by

          @hansmeets said in IPsec on 2.5.0 uses first VIP instead of WAN address:

          Let me know if you need more input.

          Do the WAN interface use some kind of dynamic IP address (DHCP/PPPoE) or is it a static IP?

          1 Reply Last reply Reply Quote 0
          • H
            hansmeets @viktor_g
            last edited by hansmeets

            @viktor_g said in IPsec on 2.5.0 uses first VIP instead of WAN address:

            @hansmeets There is an open bugreport for this:
            https://redmine.pfsense.org/issues/11545

            Thanks, I was looking for IPsec bugs, haven't seen that one!

            @viktor_g said in IPsec on 2.5.0 uses first VIP instead of WAN address:

            Do the WAN interface use some kind of dynamic IP address (DHCP/PPPoE) or is it a static IP?

            The WAN interface is set with a static IP.

            I will try the solution later today in off-hours.

            1 Reply Last reply Reply Quote 0
            • H
              hansmeets
              last edited by

              I can confirm that saving the WAN interface (without changes) indeed worked as a workaround.

              All is working now. Thank you!

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