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

VTI gateways not adding static routes in 24.03

IPsec
5
88
10.9k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic was forked from 24.03 causes issue with remote VPN stephenw10 May 15, 2024, 10:34 PM
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    stephenw10 Netgate Administrator
    last edited by May 24, 2024, 4:46 PM

    Hmm, interesting. Presumably you don't see the route errors in 23.09?:

    May 24 10:11:07 	php-cgi 	685 	rc.bootup: route_add_or_change: Invalid gateway and/or network interface ipsec1
    May 24 10:11:07 	php-cgi 	685 	rc.bootup: route_add_or_change: Invalid gateway and/or network interface ipsec1
    

    The patch 1 update is a no-op for amd64 devices. It applies only to aarch64. It won't change anything here.

    O 2 Replies Last reply May 24, 2024, 5:25 PM Reply Quote 0
    • O
      OhYeah 0 @stephenw10
      last edited by May 24, 2024, 5:25 PM

      @stephenw10 said in VTI gateways in 24.03:

      Hmm, interesting. Presumably you don't see the route errors in 23.09?

      Nope, didn't see any..

      1 Reply Last reply Reply Quote 0
      • O
        OhYeah 0 @stephenw10
        last edited by May 24, 2024, 5:45 PM

        This post is deleted!
        1 Reply Last reply Reply Quote 0
        • O
          OhYeah 0
          last edited by May 30, 2024, 9:51 AM

          Any news from devs regarding this issue? Well actually two issues I guess.

          1 Reply Last reply Reply Quote 0
          • S
            stephenw10 Netgate Administrator
            last edited by May 30, 2024, 12:28 PM

            Not yet. In all honesty it's pretty low priority because VTI / Static routes are working as intended in 24.03. Using 0/0 for both ends of the tunnel subnet was never a supported setup.

            It is curious that is changed though.

            The issue with disabled gateways causing a problem is a bigger issue since that happens in the expected config. Updates there should be shown on the bug report: https://redmine.pfsense.org/issues/15449

            O 1 Reply Last reply May 30, 2024, 12:35 PM Reply Quote 1
            • O
              OhYeah 0 @stephenw10
              last edited by May 30, 2024, 12:35 PM

              @stephenw10 said in VTI gateways not adding static routes in 24.03:

              In all honesty it's pretty low priority because VTI / Static routes are working as intended in 24.03. Using 0/0 for both ends of the tunnel subnet was never a supported setup.

              😢 Like I said, this was the only setup that worked across multiple platforms and it worked exceptionally well... until 24.03 that is. I really hope this gets sorted out, otherwise it's a massive headache for us.

              Any chances these two issues are related somehow since they occurred at the same time?

              1 Reply Last reply Reply Quote 0
              • M
                marcosm Netgate
                last edited by May 31, 2024, 4:18 PM

                I've added a patch to the redmine that should fix the issue:
                https://redmine.pfsense.org/issues/15449

                Note that while it's valid for the routing to work for an interface regardless of its IP, the strongswan docs seem to indicate that a point-to-point link with specific local/remote addresses is expected. The IPsec P2 configuration in pfSense uses the local and remote fields to build the interface, and "0.0.0.0/0,::/0" is added on top as part of the traffic selectors. We do not recommend nor support using 0/0 as the interface address.

                L N O 3 Replies Last reply May 31, 2024, 5:47 PM Reply Quote 2
                • L
                  LarryFahnoe @marcosm
                  last edited by May 31, 2024, 5:47 PM

                  @marcosm I just applied the patch to my 2 4200 systems and then rebooted. The static route was added at boot and traffic passes as expected without having to wait for rc.newwanip to trigger the route to get loaded about 15 minutes after the reboot. Many thanks!!

                  --Larry

                  1 Reply Last reply Reply Quote 1
                  • N
                    Nikkeli @marcosm
                    last edited by Jun 1, 2024, 7:29 AM

                    @marcosm
                    Thanks, this fixed the static routes not being applied from boot for me aswell. I did not have 0/0 address in IPSec, just VTI IPsec and static routes.

                    1 Reply Last reply Reply Quote 2
                    • O
                      OhYeah 0 @marcosm
                      last edited by Jun 2, 2024, 10:03 PM

                      @marcosm said in VTI gateways not adding static routes in 24.03:

                      Note that while it's valid for the routing to work for an interface regardless of its IP, the strongswan docs seem to indicate that a point-to-point link with specific local/remote addresses is expected.

                      I applied the patch on a non-production Netgate 4100 and sadly I have to say it did not fix the problem with my 0/0 setup. I was tinkering around with various config settings but so far no luck.

                      Any idea why it was working before in earlier versions?

                      M 1 Reply Last reply Jun 3, 2024, 3:13 PM Reply Quote 0
                      • M
                        marcosm Netgate @OhYeah 0
                        last edited by marcosm Jun 4, 2024, 4:15 PM Jun 3, 2024, 3:13 PM

                        @OhYeah-0 I haven't looked into that specifically, but my guess is it's related to the error shown on https://forum.netgate.com/post/1170859

                        1 Reply Last reply Reply Quote 1
                        • O
                          OhYeah 0
                          last edited by Jun 5, 2024, 11:17 AM

                          It was mentioned before that looking into this issue wasn't "a priority", but will it investigated at a later date?

                          1 Reply Last reply Reply Quote 0
                          • S
                            stephenw10 Netgate Administrator
                            last edited by Jun 5, 2024, 1:11 PM

                            I can try to look at it later this week if I have time. The problem is that I wouldn't have expected that to work in 23.09. That fact it did could be seen as a bug that is now fixed.

                            It's unlikely we would add back code to allow it if that is the case as that's an unsupported config.

                            It might be a trivial fix though once we understand how it was working in 23.09.

                            O 1 Reply Last reply Jun 5, 2024, 1:26 PM Reply Quote 0
                            • O
                              OhYeah 0 @stephenw10
                              last edited by Jun 5, 2024, 1:26 PM

                              @stephenw10 said in VTI gateways not adding static routes in 24.03:

                              I can try to look at it later this week if I have time. The problem is that I wouldn't have expected that to work in 23.09. That fact it did could be seen as a bug that is now fixed.

                              1. Thank you in advance for at least taking a look at the problem.
                              2. I hope there is a simple fix/change available. Like I said, this functionality has performed extremely well for 1+ years with multiple clients in mixed vendor/platform environments.

                              PS. The functionality worked throughout the 23.xx branch as far as I recall, haven't tested it with earlier versions.

                              M 1 Reply Last reply Jun 5, 2024, 7:55 PM Reply Quote 0
                              • M
                                marcosm Netgate @OhYeah 0
                                last edited by marcosm Jun 5, 2024, 10:03 PM Jun 5, 2024, 7:55 PM

                                @OhYeah-0 What exactly are you trying to achieve?

                                Presumably the goal is to allow any IP to pass through the tunnel, and control what gets sent through the tunnel via static routes. For the "allow" part, that's done implicitly by the system with the traffic selectors "0.0.0.0/0,::/0". This is what IPsec uses to establish the P2. As mentioned, the local/remote address you enter in the VTI tunnel's P2 GUI is used to build the interface and gateway. Putting validity aside, let's use 0.0.0.0/0 as an example. This would tell the system:
                                route 10.1.1.0/24 through 0.0.0.0 via interface ipsec1

                                The part route 10.1.1.0/24 through 0.0.0.0 would effectively mean "use the default route for 10.1.1.0/24" which would already happen simply by having a default route. There's the additional part via interface ipsec1 which would override the default route's interface and effectively mean "send traffic destined to 10.1.1.0/24 through the interface ipsec1". Hence the address "0.0.0.0" is effectively ignored and the resulting behavior would be "send 10.1.1.0/24 through the tunnel; if the tunnel is down, send 10.1.1.0/24 through the default route instead".

                                Since the GUI doesn't currently support routing via an interface without an address (i.e. a gateway requires an address), then 0.0.0.0 can't be used. By simply changing the P2 local address to something not used anywhere else in the system (e.g. an APIPA address like 169.254.254.1), the resulting behavior remains the same while also being a supported configuration.

                                O 1 Reply Last reply Jun 6, 2024, 11:15 AM Reply Quote 2
                                • O
                                  OhYeah 0 @marcosm
                                  last edited by Jun 6, 2024, 11:15 AM

                                  @marcosm said in VTI gateways not adding static routes in 24.03:

                                  @OhYeah-0 What exactly are you trying to achieve?

                                  Presumably the goal is to allow any IP to pass through the tunnel, and control what gets sent through the tunnel via static routes. For the "allow" part, that's done implicitly by the system with the traffic selectors "0.0.0.0/0,::/0". This is what IPsec uses to establish the P2. As mentioned, the local/remote address you enter in the VTI tunnel's P2 GUI is used to build the interface and gateway. Putting validity aside, let's use 0.0.0.0/0 as an example. This would tell the system:
                                  route 10.1.1.0/24 through 0.0.0.0 via interface ipsec1

                                  Since the GUI doesn't currently support routing via an interface without an address (i.e. a gateway requires an address), then 0.0.0.0 can't be used. By simply changing the P2 local address to something not used anywhere else in the system (e.g. an APIPA address like 169.254.254.1), the resulting behavior remains the same while also being a supported configuration.

                                  I assumed (perhaps incorrectly) that setting the destination network to 0.0.0.0/0 is essentially saying "anything is allowed to be routed to that tunnel if an appropriate static route exist in the system routing table". In essence:

                                  route 10.1.1.0/24 through 0.0.0.0 via interface ipsec1 (through 0.0.0.0 part seems superfluous)

                                  The last paragraph is somewhat confusing to me from a system standpoint, since 169.254.0.0 networks are reserved for Windows OS devices unable to obtain an address. Both are unroutable networks but here 169.254.0.0 has a much more specific context while 0.0.0.0 is merely a placeholder saying "check system routing table".

                                  Again, I apologize if I have gravely misunderstood some concepts.

                                  M 1 Reply Last reply Jun 6, 2024, 6:02 PM Reply Quote 0
                                  • M
                                    marcosm Netgate @OhYeah 0
                                    last edited by Jun 6, 2024, 6:02 PM

                                    I assumed (perhaps incorrectly) that setting the destination network to 0.0.0.0/0 is essentially saying "anything is allowed to be routed to that tunnel if an appropriate static route exist in the system routing table". In essence:

                                    route 10.1.1.0/24 through 0.0.0.0 via interface ipsec1 (through 0.0.0.0 part seems superfluous)

                                    This is handled by the traffic selectors, you can see this config in /var/etc/ipsec/swanctl.conf. This already happens in addition to what you enter in the GUI.

                                    The last paragraph is somewhat confusing to me from a system standpoint, since 169.254.0.0 networks are reserved for Windows OS devices unable to obtain an address. Both are unroutable networks but here 169.254.0.0 has a much more specific context while 0.0.0.0 is merely a placeholder saying "check system routing table".

                                    It's OK to use the APIPA address space for point-to-point tunnels. I gave it as an example because it's commonly used by cloud platforms for the same purpose. You are free to use any address you want as long as you understand its context in the network.

                                    O 1 Reply Last reply Jun 7, 2024, 12:09 PM Reply Quote 2
                                    • O
                                      OhYeah 0 @marcosm
                                      last edited by Jun 7, 2024, 12:09 PM

                                      @marcosm said in VTI gateways not adding static routes in 24.03:

                                      This is handled by the traffic selectors, you can see this config in /var/etc/ipsec/swanctl.conf. This already happens in addition to what you enter in the GUI.

                                      I don't see anything extra in the config file.

                                      # This file is automatically generated. Do not edit
                                      connections {
                                      	bypass {
                                      		remote_addrs = 127.0.0.1
                                      		children {
                                      			bypasslan {
                                      				local_ts = 192.168.107.0/24
                                      				remote_ts = 192.168.107.0/24
                                      				mode = pass
                                      				start_action = trap
                                      			}
                                      		}
                                      	}
                                      	con2 {
                                      		# P1 (ikeid 2):
                                      		fragmentation = yes
                                      		unique = replace
                                      		version = 2
                                      		proposals = aes128gcm128-sha256-modp2048,aes256gcm128-sha256-modp2048
                                      		dpd_delay = 10s
                                      		rekey_time = 25920s
                                      		reauth_time = 0s
                                      		over_time = 2880s
                                      		rand_time = 2880s
                                      		encap = no
                                      		mobike = no
                                      		local_addrs = 88.xxx.xxx.xxx
                                      		remote_addrs = 80.yyy.yy.yyy
                                      		local {
                                      			id = 88.xxx.xxx.xxx
                                      			auth = psk
                                      		}
                                      		remote {
                                      			id = 80.yyy.yy.yyy
                                      			auth = psk
                                      		}
                                      		children {
                                      			con2 {
                                      				# P2 (reqid 2):
                                      				policies = no
                                      				life_time = 3600s
                                      				rekey_time = 3240s
                                      				rand_time = 360s
                                      				start_action = start
                                      				remote_ts = 0.0.0.0/0,0.0.0.0/0,::/0
                                      				local_ts = 0.0.0.0/0,0.0.0.0/0,::/0
                                      				reqid = 5002
                                      				esp_proposals = aes256gcm128-modp2048,aes128gcm128-modp2048
                                      				dpd_action = restart
                                      			}
                                      		}
                                      	}
                                      }
                                      secrets {
                                      	ike-0 {
                                      		secret = 
                                      		id-0 = %any
                                      		id-1 = 80.yyy.yy.yyy
                                      	}
                                      }
                                      
                                      
                                      1 Reply Last reply Reply Quote 0
                                      • L LarryFahnoe referenced this topic on Jun 8, 2024, 8:45 PM
                                      • O
                                        OhYeah 0
                                        last edited by Jun 20, 2024, 8:20 PM

                                        I thought I'd do some further testing with earlier versions of CE, specifically 2.6.0.

                                        I'm happy to report that 0.0.0.0/0 works identically to 2.7.2. That version was released in the beginning of 2022..

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