Wrong route installed on FreeBSD? #1807
Comments
The route is needed exactly in order for packets to match the policy as it forces the virtual IP (the local traffic selector in the policy) as source IP when sending packets to the destination (remote traffic selector). On Linux, we use routes with preferred source IP, on FreeBSD/macOS, we use routes via TUN devices instead (which are only used to force the source IP, not to actually send any traffic through).
This looks like the virtual IP is not treated as such. If it was, you'd see a message saying
At a first glance this looks fine. That is, the interface is known, as is the IP address on it (otherwise, we'd see an error saying However, after waiting for the virtual IP address to appear on an interface, we mark the address as virtual in the internal address list so it can later be treated differently (as described above). The problem is that the event that handles changes of interface flags (in this case that the interface is activated) clears and repopulates the internal address list for that interface. If this happens after the address has already been marked, that virtual IP status is currently lost. I've pushed a possible fix for this to the 1807-pfroute-vip branch. |
I see. I don't think I could infer this from the docs, so thank you for the explanation. As a side note, is there a way to select the source ip address used by the responder for the inner packets?
Thank you for the thorough explanation. Glad to hear it wasn't a misconfiguration on my side.
Thanks, I'll give it a try later today. |
Depends on the platform, the existing routes and interfaces etc. If the server is running FreeBSD as well, you might have to enable Also, since the virtual IPs are from your remote LAN, are you using the farp plugin? |
Yes, it is running FreeBSD. I'll give it a shot.
Not yet, but it is on my list of things to setup. |
I compiled it, and run charon and swanctl from the build directory. I don't see any difference: the route is still installed "through" |
|
I should also note that I get the following message when trying to terminate the connection: and the |
That won't work as the kernel-pfroute plugin will just be dynamically loaded from the default location (i.e. you won't get the new code). Only for the unit tests (
Note that with That CHILD_SA is apparently in a state that doesn't allow a proper delete.
The virtual IP and with it the TUN device are properties of the IKE_SA. |
Hah, that's exactly why I mentioned running from the build directory, so you could tell me if what I did was wrong. I'll try again this afternoon.
Okay, thanks!
Got it! |
|
I installed the version from the 1807-pfroute-vip branch, and the route is correctly added to be "through" Everything seems to be working correctly. |
|
Great, thanks for testing. I've pushed the fix to master. |
System:
Describe the bug
Strongswan installs what seems a wrong route to the remote network specified in the remote traffic selector.
To Reproduce
swanctl -i -c myvpn-lan(see config below). Get virtual ip171.24.1.1, belonging to remote lan is172.24.0.0/16, specified throughremote_ts)ping 172.24.2.1)tcpdumping onenc0, thus no packets seem to be leaving the host through the VPN.nestat -rn4W. Notice an unexpected route to the remote LAN, which did not exist before (output given below).Workaround: manually remote the route added by strongswan (
route delete 172.24.0.0/16), add new route to remote LAN usingtun0as interface (route add 172.24.0.0/16 -interface tun0). Pinging172.24.2.1now works. Output given below.Expected behavior
Pinging should work.
(I'm also a bit surprised that a route is needed: I thought the policies visible through
setkey -D -Pwere supposed to be enough).Additional context
My client config:
The routing table on my client before initiating the ipsec connection with
swanctl -i -c myvpn-lan:The
ifconfigon my client before initiating the ipsec connection:The log collected from charon when initializing the remote connection:
The
ifconfigon my client after having established the remote connection:The routing table on my client after having established the remote connection:
The line
seems weird to me.
The output of
setkey -DPon the client after having established the remote connection:The output of
ping 172.24.2.1The commands given to workaround the issues, and their output
The text was updated successfully, but these errors were encountered: