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

    [CLOSED - Can't reproduce] IPSec using alias IP instead of WAN IP

    Scheduled Pinned Locked Moved IPsec
    18 Posts 2 Posters 1.8k 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.
    • A
      amello
      last edited by amello

      Guys,

      I’ve been having this problem for some time and only now had the opportunity to get back to it. Not sure if this is a configuration issue or not, so I’d like to brainstorm with the forum.

      Below the sites configurations:

      Site A – Main

      Version
      2.4.3-RELEASE-p1 (amd64)

      CPU Type
      Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz
      Current: 3000 MHz, Max: 3001 MHz
      4 CPUs: 1 package(s) x 4 core(s)
      AES-NI CPU Crypto: Yes (active)

      Five Public IPs: x.x.x.80/29

      WAN – x.x.x.81/29
      IP Alias 1 – x.x.x.82/29
      IP Alias 2 – x.x.x.83/29
      IP Alias 3 – x.x.x.84/29
      IP Alias 4 – x.x.x.85/29

      (Also tried /32 for above IP Alias with same results – not sure of what’s the correct way to set them up or if it does meater).

      Site B – Remote

      Version
      2.4.3-RELEASE-p1 (amd64)

      CPU Type
      Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz

      2 CPUs: 1 package(s) x 2 core(s)
      AES-NI CPU Crypto: No

      Dynamic IP, updated on my DNS host. Let’s call it: remote.mydomain.net

      Main site phase I is configured with interface pointing to WAN (the .81 IP) and remote gateway as remote.mydomain.net.

      Remote site phase I is configured with interface pointing to WAN (dynamic) and remote gateway my first public IP.

      When trying to connect, the IPSec logs shows:

      charon

      11[NET] <con1|2> sending packet: from x.x.x.83[500] to x.x.x.79[500] (76 bytes)

      And won’t connect as .83 is not the IP configured on the remote site -- also not Main Site WAN IP, but one of the IP Alias.

      If I change the remote gateway IP address on the remote site phase I configuration, connects like a charm.

      Yes, it’s connected, but not as it’s supposed to. I can, after the connection, open the local IP for the remote site’s pf no problem.

      Any ideas will be appreciated.

      1 Reply Last reply Reply Quote 0
      • A
        amello
        last edited by

        By the way, as expected the tunnel is only working one way: from the Main to Remote. I do think it is due to the tunnel be using the wrong WAN IP on the Main, so when it comes back, won't reach the LAN behind it.

        1 Reply Last reply Reply Quote 0
        • A
          amello
          last edited by

          Update:

          ipsec.conf has the wrong WAN IP in it:

          --- BOF ---

          conn con1
          fragmentation = yes
          keyexchange = ikev2
          reauth = yes
          forceencaps = no
          mobike = no

              rekey = no
              installpolicy = yes
              type = tunnel
              dpdaction = restart
              dpddelay = 10s
              dpdtimeout = 60s
              auto = route
              left = x.x.x..83
          

          --- EOF ---

          Changed inside the file to the correct one, but the GUI changed back to the wrong one.

          Is this a GUI bug or IP Alias configured incorrectly?

          1 Reply Last reply Reply Quote 0
          • A
            amello
            last edited by

            Guys,

            Don't want to report this as a bug without getting confirmation it is not a misconfiguration on my part.

            Again, here's the scenario:

            • Main site with five public IPs;

            • WAN configured as x.x.x.81/29

            • IP Alias configured as:
              -- x.x.x.82/29
              -- x.x.x.83/29
              -- x.x.x.84/29
              -- x.x.x.85/29

            • IPSEC Phase 1 Interface configured as WAN

            • When trying to connect, won't connect

            • IPSEC log shows pf sending request as x.x.x.83, instead of using the WAN IP x.x.x.81

            Ideas?

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              You should probably post screen shots instead of a summary of what you think you have done. Likely that something is done incorrectly.

              WAN interface, VIPs, IPsec Phase 1.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • A
                amello
                last edited by

                As requested:

                0_1531159788069_WAN Configuration.png

                0_1531159807911_IP Alias configuration.png

                0_1531159825127_NAT 1-1.png

                0_1531159839200_IPSec Phase I.png

                0_1531159870082_IPSec log.png

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  That all looks like it should work. Sending a PM.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    Out of curiosity is the correct VIP used in IPsec of you select a VIP to bind to as the interface on the Phase 1? Say .82?

                    Not sure why yours is doing that yet. There are untold thousands of people binding IPsec to wan with IP Aliases on the interface.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • A
                      amello
                      last edited by amello

                      My phase I uses the WAN interface, wish has the .81 IP assigned to it. My .81 IP isn't used for any IP Alias or anything else. When looking my ipsec.conf I see the .83 as the left interface IP, so assume the appliance is getting the WAN on Phase I and translating to .83 - one of the IP Alias.
                      I did try to create a IP Alias for the .81 to have it on the selection for the Phase I, but it don't seem to be allowed (maybe also wrong).
                      Hope I have answered your question.
                      Will PM a screen shot with the options I have.
                      Please be careful with my Public IPs and domain :)
                      I can setup a conference call and share screen so you can see.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by Derelict

                        I was asking if you deliberately set IPsec to use .82, does it configure IPsec to use .82? You would just select the VIP in the interface selection you showed.

                        I understand that you are seeing .83 in the config even though you should be seeing .81.

                        You should not try to create a VIP for .81 nor should you have to. .81 is the interface address.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        A 1 Reply Last reply Reply Quote 0
                        • A
                          amello @Derelict
                          last edited by

                          No, haven't set my IPSec to .82. It is set to WAN you per pics sent.

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            Can you try it?

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            A 1 Reply Last reply Reply Quote 0
                            • A
                              amello @Derelict
                              last edited by

                              When setting to .82, IPSec tried to connect with it:

                              04[NET] sending packet: from x.x.x.82[500] to 24.x.x.79[500]

                              Changing back to WAN, it's back to .83:

                              04[NET] sending packet: from x.x.x.83[500] to 24.x.x.79[500]

                              1 Reply Last reply Reply Quote 0
                              • DerelictD
                                Derelict LAYER 8 Netgate
                                last edited by

                                That is really very strange. I didn't see anything in your config that would cause that. It's fairly straightforward. I will try to duplicate it here. Not sure how long that will take.

                                Chattanooga, Tennessee, USA
                                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                1 Reply Last reply Reply Quote 1
                                • A
                                  amello
                                  last edited by

                                  Doing some tests, removed my IP Alias, disabled/enabled my Phase I, and the left IP was correct. Tried to connect and it did:

                                  0_1531703521102_e4c68c57-0737-48e5-a51f-00396c308cb7-image.png

                                  I've added my IP Alias back/disconnected/reconnected fine.

                                  Disabled/re-enabled with the IP Alias configured and again, the left IP on my ipsec.conf is back to the 2nd IP Alias (my .83).

                                  Could it be something on ipsec_get_phase1_src?

                                  1 Reply Last reply Reply Quote 0
                                  • DerelictD
                                    Derelict LAYER 8 Netgate
                                    last edited by

                                    Probably not. But if you have a definitive set of steps to reproduce it can be looked at.

                                    Chattanooga, Tennessee, USA
                                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      amello
                                      last edited by

                                      Steps:

                                      • Removed IP Alias
                                      • Disabled/Enabled IPSec Phase I
                                      • IPSec tunnel connected
                                      • Added IP Alias
                                      • Disconnected/reconnected tunnel -> OK
                                      • Disabled/Enabled IPSec Phase I
                                      • Tried to connect IPSec -> Using wrong IP, so not connected

                                      Also:

                                      • Today I decided to do a fresh install with:

                                      Version 2.4.3-RELEASE (amd64)
                                      built on Mon Mar 26 18:02:04 CDT 2018
                                      FreeBSD 11.1-RELEASE-p7

                                      • Restored my config and IPSec is connecting
                                      • Will update to 2.4.3_1 and report.
                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        amello
                                        last edited by

                                        Here's the results:

                                        --- Started update ---

                                        Updating repositories metadata...
                                        Updating pfSense-core repository catalogue...
                                        pfSense-core repository is up to date.
                                        Updating pfSense repository catalogue...
                                        done.
                                        pfSense repository is up to date.
                                        All repositories are up to date.
                                        2.4.3_1 version of pfSense is available
                                        Downloading upgrade packages...
                                        Updating pfSense-core repository catalogue...
                                        pfSense-core repository is up to date.
                                        Updating pfSense repository catalogue...
                                        pfSense repository is up to date.
                                        All repositories are up to date.
                                        Checking for upgrades (9 candidates): ......... done
                                        Processing candidates (9 candidates): ......... done
                                        The following 8 package(s) will be affected (of 0 checked):

                                        Installed packages to be UPGRADED:
                                        sqlite3: 3.21.0_1 -> 3.22.0_1 [pfSense]
                                        pfSense-rc: 2.4.3 -> 2.4.3_1 [pfSense-core]
                                        pfSense-kernel-pfSense: 2.4.3 -> 2.4.3_1 [pfSense-core]
                                        pfSense-default-config: 2.4.3 -> 2.4.3_1 [pfSense-core]
                                        pfSense-base: 2.4.3 -> 2.4.3_1 [pfSense-core]
                                        pfSense: 2.4.3 -> 2.4.3_1 [pfSense]
                                        perl5: 5.24.3 -> 5.24.4 [pfSense]
                                        libnghttp2: 1.29.0 -> 1.31.1 [pfSense]

                                        Number of packages to be upgraded: 8

                                        67 MiB to be downloaded.
                                        [1/8] Fetching sqlite3-3.22.0_1.txz: .......... done
                                        [2/8] Fetching pfSense-rc-2.4.3_1.txz: .. done
                                        [3/8] Fetching pfSense-kernel-pfSense-2.4.3_1.txz: .......... done
                                        [4/8] Fetching pfSense-default-config-2.4.3_1.txz: . Done

                                        System update failed!

                                        --- Update ended with errors ---

                                        • System rebooted and shows:

                                        Version 2.4.3-RELEASE-p1 (amd64)
                                        built on Thu May 10 15:02:52 CDT 2018
                                        FreeBSD 11.1-RELEASE-p10

                                        • IPSec status shows connected ...

                                        • Failing update have been reported by several users, so not new

                                        • Can't reproduce after freshly installing for a second time -- please note the previous installation was fresh and config restored as well.

                                        • I'm closing this as can't reproduce -- please let me know if is there anything else I can test for you guys.

                                        1 Reply Last reply Reply Quote 0
                                        • J johntconklin referenced this topic on
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.