[strongSwan] opnsense: conflicts with IKE traffic

[Andrew Russell]

hello please can you advise on these errors from opnsense ipsec log:

Sep 9 01:01:24 opnsense charon: 00[DMN] signal of type SIGINT received.
Shutting down
Sep 9 01:01:37 opnsense charon: 00[DMN] Starting IKE charon daemon
(strongSwan 5.6.3, FreeBSD 11.1-RELEASE-p13, amd64)
Sep 9 01:01:37 opnsense charon: 00[KNL] unable to set UDP_ENCAP: Invalid
argument
Sep 9 01:01:37 opnsense charon: 00[NET] enabling UDP decapsulation for
IPv6 on port 4500 failed
Sep 9 01:01:37 opnsense charon: 00[CFG] loading ca certificates from
'/usr/local/etc/ipsec.d/cacerts'
Sep 9 01:01:37 opnsense charon: 00[CFG] loaded ca certificate
"XXXXXXXXXXX"XXXXXXXXXXX"XXXXXXXXXXX"XXXXXXXXXXX'
Sep 9 01:01:37 opnsense charon: 00[CFG] loading aa certificates from
'/usr/local/etc/ipsec.d/aacerts'
Sep 9 01:01:37 opnsense charon: 00[CFG] loading ocsp signer certificates
from '/usr/local/etc/ipsec.d/ocspcerts'
Sep 9 01:01:37 opnsense charon: 00[CFG] loading attribute certificates
from '/usr/local/etc/ipsec.d/acerts'
Sep 9 01:01:37 opnsense charon: 00[CFG] loading crls from
'/usr/local/etc/ipsec.d/crls'
Sep 9 01:01:37 opnsense charon: 00[CFG] loading secrets from
'/usr/local/etc/ipsec.secrets'
Sep 9 01:01:37 opnsense charon: 00[CFG] loaded IKE secret for
***@XXXXXX
Sep 9 01:01:37 opnsense charon: 00[CFG] loaded 0 RADIUS server
configurations
Sep 9 01:01:37 opnsense charon: 00[LIB] loaded plugins: charon aes des
blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints
pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf
curve25519 xcbc cmac hmac gcm attr kernel-pfkey kernel-pfroute resolve
socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2
eap-radius eap-tls eap-ttls eap-peap xauth-generic whitelist addrblock
counters
Sep 9 01:01:37 opnsense charon: 00[JOB] spawning 16 worker threads
Sep 9 01:01:37 opnsense charon: 05[CFG] received stroke: add connection
'con1'
Sep 9 01:01:37 opnsense charon: 05[CFG] added configuration 'con1'
Sep 9 01:01:37 opnsense charon: 16[CFG] received stroke: route 'con1'
Sep 9 01:01:37 opnsense charon: 16[KNL] can't install route for
192.168.2.0/24 === XXX.XXX.XXX.XXX/32 out, conflicts with IKE traffic

[Tobias Brunner]

Hi Andrew,

On BSD, a route based VPN has to be used, because it has no policy based implementation (as far as I know).

At least on FreeBSD that's not the case, i.e. it has policies just like
other IPsec implementations (including socket policies to whitelist the
IKE sockets). But for virtual IPs a TUN device and routes to it are
necessary (so the source IP matches the policies, not to replace them).
But this won't work if the remote TS includes the IKE peer as that would
route IKE packets incorrectly. While this is mainly an issue if virtual
IPs are used, that exception is currently not handled that specifically.
However, the failure to install a route is not fatal (the result is
basically ignored) so if the routing is already setup properly this
shouldn't really be an issue as long as no virtual IPs are used.

Regards,
Tobias

[Andrew Russell]

thank you for the replies. i am told the opnsense fork of pfsense runs a
hardened version of freebsd rather than openbsd.

i think their support for ike v2 is relatively recent. i will try this
again to see if i can get the routing correct.

Post by Tobias Brunner
Hi Andrew,

On BSD, a route based VPN has to be used, because it has no policy based

implementation (as far as I know).
At least on FreeBSD that's not the case, i.e. it has policies just like
other IPsec implementations (including socket policies to whitelist the
IKE sockets). But for virtual IPs a TUN device and routes to it are
necessary (so the source IP matches the policies, not to replace them).
But this won't work if the remote TS includes the IKE peer as that would
route IKE packets incorrectly. While this is mainly an issue if virtual
IPs are used, that exception is currently not handled that specifically.
However, the failure to install a route is not fatal (the result is
basically ignored) so if the routing is already setup properly this
shouldn't really be an issue as long as no virtual IPs are used.
Regards,
Tobias