VTI gateways not adding static routes in 24.03

OhYeah 0

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

stephenw10

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.

OhYeah 0

@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.

Thank you in advance for at least taking a look at the problem.
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.

marcosm

@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.

OhYeah 0

@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.

marcosm

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.

OhYeah 0

@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
	}
}

OhYeah 0

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..