Project

General

Profile

Issue #2462

Traffic not routing back to road warrior (regression from 5.5)

Added by arc xmncra over 1 year ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.6.0
Resolution:
No change required

Description

A server on my home network (10.1.1.32/24) is used to allow remote devices to connect to the network, and assigns road warriors an IP using DHCP from the router. This setup/config works on 5.5.3 and prior, but fails to work on 5.6.0 or 5.6.1dr3. Kernel version is 4.13.11, Arch Linux.

It's a pretty basic config where clients are configured with "leftsourceip=%config4 rightsubnet=10.1.1.0/24" and server is rightsourceip=%dhcp. Traffic from the road warrior makes it through the tunnel, but no responses are sent back to it. Pinging/accessing the client's IP from the server sends the packets off to the gateway/router instead of through the tunnel, and outgoing packet counters do not increase. Using a subnet that does not overlap (leftsourceip=10.1.2.0/24) works fine, as does IPV6. See attached for full configs, as well as ip route and ip xfrm state/policy dumps - the client is assigned 10.1.1.130 via DHCP.

client.conf (279 Bytes) client.conf arc xmncra, 08.11.2017 19:52
policy-5.5.txt (608 Bytes) policy-5.5.txt arc xmncra, 08.11.2017 19:52
policy-5.6.txt (975 Bytes) policy-5.6.txt arc xmncra, 08.11.2017 19:52
routes-5.5.txt (842 Bytes) routes-5.5.txt arc xmncra, 08.11.2017 19:52
routes-5.6.txt (899 Bytes) routes-5.6.txt arc xmncra, 08.11.2017 19:52
server.conf (264 Bytes) server.conf arc xmncra, 08.11.2017 19:52
state-5.5.txt (745 Bytes) state-5.5.txt arc xmncra, 08.11.2017 19:52
state-5.6.txt (745 Bytes) state-5.6.txt arc xmncra, 08.11.2017 19:52

History

#1 Updated by Tobias Brunner over 1 year ago

  • Status changed from New to Feedback

Do you have the bypass-lan plugin enabled on the server?

#2 Updated by arc xmncra over 1 year ago

Tobias Brunner wrote:

Do you have the bypass-lan plugin enabled on the server?

Hm looks like that's it, it was enabled recently on the arch package and is loaded by default: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/strongswan&id=b23268cbc76a09bc2273e316ad50d8f5866d664c

I guess then the issue is that the plugin's presence makes it impossible to host virtual IPs on any local networks, should the policy priorities be adjusted to prevent this from happening?

5.5.3 loaded plugins: charon aesni aes des rc2 sha2 sha3 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ntru newhope bliss curl sqlite attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity

5.6.0 loaded plugins: charon ldap aesni aes des rc2 sha2 sha3 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ntru newhope bliss curl mysql sqlite attr kernel-netlink resolve socket-default bypass-lan connmark forecast farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity

5.6.1dr3 loaded plugins: loaded plugins: charon ldap aesni aes des rc2 sha2 sha3 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ntru newhope bliss curl mysql sqlite attr kernel-netlink resolve socket-default bypass-lan connmark forecast farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity

#3 Updated by Tobias Brunner over 1 year ago

Do you have the bypass-lan plugin enabled on the server?

Hm looks like that's it, it was enabled recently on the arch package and is loaded by default: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/strongswan&id=b23268cbc76a09bc2273e316ad50d8f5866d664c

OK.

I guess then the issue is that the plugin's presence makes it impossible to host virtual IPs on any local networks, should the policy priorities be adjusted to prevent this from happening?

The whole point of the plugin is to explicitly bypass IPsec tunnels for local traffic (and it's more intended for clients than for gateways). Just disable the plugin (via /etc/strongswan.d/charon/bypass-lan.conf or directly in strongswan.conf).

#4 Updated by arc xmncra over 1 year ago

Tobias Brunner wrote:

The whole point of the plugin is to explicitly bypass IPsec tunnels for local traffic (and it's more intended for clients than for gateways). Just disable the plugin (via /etc/strongswan.d/charon/bypass-lan.conf or directly in strongswan.conf).

Yup disabling it does work, I can just edit/delete bypass-lan.conf. I did come across that plugin when trying to diagnose the issue but I incorrectly assumed it was harmless because a more specific virtual IP route/policy would take precedence over a blanket bypass - and also assumed that its default configuration would not prevent some basic functionality from working.

Part of the issue lies in that the recommended way to enable or disable plugins is during compile time and a distro will just provide precompiled packages with all plugins enabled by default (what's not clear to me is whether not enabling a plugin at compile time allows manual enabling by config later, or omits it from the build entirely). It seems like an invasive plugin that should not be enabled by default config in a generic distribution, although if disabling prevents anyone from using it then I suppose some documentation that it will conflict with server configurations would be the next best solution.

#5 Updated by Tobias Brunner over 1 year ago

I did come across that plugin when trying to diagnose the issue but I incorrectly assumed it was harmless because a more specific virtual IP route/policy would take precedence over a blanket bypass

Bypass policies currently always have the highest priority.

(what's not clear to me is whether not enabling a plugin at compile time allows manual enabling by config later, or omits it from the build entirely).

Yes, anything not enabled via configure script won't be built. But distros are free to patch the config snippets (set load = no in them) if they don't want some of the plugins to get loaded by default (or if the plugin is shipped in a separate package also ship the config snipped with it, so it is only loaded when installed).

#6 Updated by Tobias Brunner 11 months ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF