Navigation

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

    IPsec on 2.5.0 uses first VIP instead of WAN address

    IPsec
    2
    5
    199
    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_g 2 Replies Last reply Reply Quote 0
      • viktor_g
        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_g
          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

              Products

              • Platform Overview
              • TNSR
              • pfSense
              • Appliances

              Services

              • Training
              • Professional Services

              Support

              • Subscription Plans
              • Contact Support
              • Product Lifecycle
              • Documentation

              News

              • Media Coverage
              • Press
              • Events

              Resources

              • Blog
              • FAQ
              • Find a Partner
              • Resource Library
              • Security Information

              Company

              • About Us
              • Careers
              • Partners
              • Contact Us
              • Legal
              Our Mission

              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

              Subscribe to our Newsletter

              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

              © 2021 Rubicon Communications, LLC | Privacy Policy