IPSec bypass-lan does not work / plugin missing
we have the problem that the traffic is routed over the IPSec connection, although the target network is a local network that is connected via a second interface.
Our network setup:
Company NET: 10.64.0.0/10
Branch office A: 10.65.0.0/16
Branch office B: 10.66.0.0/16
Branch office C: 10.67.0.0/16
P2 10.65.0.0/16 <-> 10.64.0.0/10 (so each Branch office can reach the HQ and other branch offices, as far as the fw ruleset allows it.)
According to https://wiki.strongswan.org/projects/strongswan/wiki/Bypass-lan with the plugin enabled it should be possible to reach 10.65.1.X from 10.65.0.X. Instead the traffic always enters the ipsec interface
What exactly does the option "Auto-exclude LAN address" do, because it seems to have nothing to do with the bypass-lan plugin, which does not seems to be available
Status of IKE charon daemon (strongSwan 5.6.2, FreeBSD 11.1-RELEASE-p10, amd64): loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters
The pfSense option to exclude the LAN adds a set of SPDs that cause traffic from/to the interface internally labeled "lan" to not pass through IPsec.
It only works with the first local interface (internally called "lan") and not with other local interfaces.
Ok thanks, so in that case I'm looking forward for route-based IPsec.
Is there any good reason why the lan bypass is implemented as a set of SPDs instead of using the appropriate strongswan plugin?
I don't recall the history there specifically. I'm not familiar with that plugin myself. In the past, however, there were a number of strongSwan plugins that were not supported on FreeBSD or did not work properly there. It would not surprise me to find that was the case here, or that SPDs behaved in a more consistent and predictable manner.