Bug #9767
closedInteresting Traffic Will not Initiate an IPsec VTI tunnel.
100%
Description
Interesting Traffic Will not Initiate an IPsec VTI tunnel.
Steps to reproduce:
Configure a VTI tunnel between two pfSense nodes, assign the interfaces, etc.
Set a ping target on each side for the other side of the VTI. It looks like this must be saved after the if_ipsec is assigned/created or /var/db/ipsecpinghosts is not properly-populated which is probably another bug.
Let the tunnel come up and verify it works.
Manually disconnect one side or the other on the IPsec > Status page.
Wait for ping_hosts to fire.
The IPsec logs will show this:
Sep 16 18:20:53 charon 09[KNL] received an SADB_ACQUIRE with policy id 580 but no matching policy found
Sep 16 18:20:53 charon 09[KNL] creating acquire job for policy 172.25.228.5/32|/0 === 172.25.228.9/32|/0 with reqid {0}
Sep 16 18:20:53 charon 09[CFG] trap not found, unable to acquire reqid 0
The tunnel will not come up again until something causes an IPsec reload, the user manually connects the tunnel, etc.
This was tested with a tunnel between a 2.4.4-p3 and 2.5.0 host with the current snapshot version.
It has also been seen on a customer tunnel between pfSense and AWS VPC.
Was also tested with static routes and LAN-to-LAN traffic. Same reqid 0 logs.
/var/etc/ipsec/ipsec.conf ipsec statusall swanctl --list-conns ifconfig -vm ipsec1000 From each side. 2.4.4-p3 first, 2.5.0 second. # This file is automatically generated. Do not edit config setup uniqueids = yes conn bypasslan leftsubnet = 172.25.232.0/24,fda7:d53d:e3d3:1::/64 rightsubnet = 172.25.232.0/24,fda7:d53d:e3d3:1::/64 authby = never type = passthrough auto = route conn con1000 reqid = 1000 fragmentation = yes keyexchange = ikev1 reauth = yes forceencaps = no mobike = no rekey = yes installpolicy = no dpdaction = restart dpddelay = 10s dpdtimeout = 60s auto = start left = 172.25.228.5 right = 172.25.228.9 leftid = 172.25.228.5 ikelifetime = 28800s lifetime = 3600s ike = aes128-sha1-modp1024! esp = aes128-sha1-modp1024! leftauth = psk rightauth = psk rightid = 172.25.228.9 aggressive = no rightsubnet = 172.22.177.1,0.0.0.0/0 leftsubnet = 172.22.177.2/30,0.0.0.0/0 Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p10, amd64): uptime: 70 minutes, since Sep 16 17:33:41 2019 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10 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 Listening IP addresses: 172.25.232.1 fda7:d53d:e3d3:1::1 172.25.101.1 2001:470:f00e:ff01:789e:acff:fe9a:e764 172.25.232.234 172.25.228.5 2001:470:f00e:7fff::c8fb:f578 2001:1111:2222:0:d8fa:e0ff:feb4:73cd 192.168.2.1 172.25.16.1 172.25.227.5 172.22.177.2 Connections: bypasslan: %any...%any IKEv1/2 bypasslan: local: uses public key authentication bypasslan: remote: uses public key authentication bypasslan: child: 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 === 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 PASS con1000: 172.25.228.5...172.25.228.9 IKEv1, dpddelay=10s con1000: local: [172.25.228.5] uses pre-shared key authentication con1000: remote: [172.25.228.9] uses pre-shared key authentication con1000: child: 0.0.0.0/0|/0 === 0.0.0.0/0|/0 TUNNEL, dpdaction=restart Shunted Connections: bypasslan: 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 === 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 PASS Security Associations (0 up, 0 connecting): none bypasslan: IKEv1/2, reauthentication every 10260s, no rekeying local: %any remote: %any local public key authentication: remote public key authentication: bypasslan: PASS, no rekeying local: 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 remote: 172.25.232.0/24|/0 fda7:d53d:e3d3:1::/64|/0 con1000: IKEv1, reauthentication every 28260s, dpd delay 10s local: 172.25.228.5 remote: 172.25.228.9 local pre-shared key authentication: id: 172.25.228.5 remote pre-shared key authentication: id: 172.25.228.9 con1000: TUNNEL, rekeying every 3060s, dpd action is restart local: 0.0.0.0/0|/0 remote: 0.0.0.0/0|/0 ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 tunnel inet 172.25.228.5 --> 172.25.228.9 inet6 fe80::1cbb:e5a5:cb74:41fd%ipsec1000 prefixlen 64 scopeid 0xa inet 172.22.177.2 --> 172.22.177.1 netmask 0xfffffffc nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> reqid: 1000 groups: ipsec # This file is automatically generated. Do not edit config setup uniqueids = yes conn bypasslan leftsubnet = 172.25.233.0/24,2001:470:f00e:7b01::/64 rightsubnet = 172.25.233.0/24,2001:470:f00e:7b01::/64 authby = never type = passthrough auto = route conn con1000 reqid = 1000 fragmentation = yes keyexchange = ikev1 reauth = yes forceencaps = no mobike = no rekey = yes installpolicy = no dpdaction = restart dpddelay = 10s dpdtimeout = 60s auto = start left = 172.25.228.9 right = 172.25.228.5 leftid = 172.25.228.9 ikelifetime = 28800s lifetime = 3600s ike = aes128-sha1-modp1024! esp = aes128-sha1-modp1024! leftauth = psk rightauth = psk rightid = 172.25.228.5 aggressive = no rightsubnet = 172.22.177.2,0.0.0.0/0 leftsubnet = 172.22.177.1/30,0.0.0.0/0 Status of IKE charon daemon (strongSwan 5.8.0, FreeBSD 12.0-RELEASE-p10, amd64): uptime: 64 minutes, since Sep 16 17:35:09 2019 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 10 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 xauth-pam whitelist addrblock counters Listening IP addresses: 172.25.233.1 2001:470:f00e:7b01::1 10.10.10.1 172.25.228.9 2001:470:f00e:7fff::ac19:e409 172.25.228.10 192.168.1.1 172.25.227.227 10.10.12.1 10.11.12.1 10.40.80.1 172.22.177.1 Connections: bypasslan: %any...%any IKEv1/2 bypasslan: local: uses public key authentication bypasslan: remote: uses public key authentication bypasslan: child: 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 === 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 PASS con1000: 172.25.228.9...172.25.228.5 IKEv1, dpddelay=10s con1000: local: [172.25.228.9] uses pre-shared key authentication con1000: remote: [172.25.228.5] uses pre-shared key authentication con1000: child: 0.0.0.0/0|/0 === 0.0.0.0/0|/0 TUNNEL, dpdaction=restart Shunted Connections: bypasslan: 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 === 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 PASS Security Associations (0 up, 0 connecting): none bypasslan: IKEv1/2, reauthentication every 10260s, no rekeying local: %any remote: %any local public key authentication: remote public key authentication: bypasslan: PASS, no rekeying local: 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 remote: 172.25.233.0/24|/0 2001:470:f00e:7b01::/64|/0 con1000: IKEv1, reauthentication every 28260s, dpd delay 10s local: 172.25.228.9 remote: 172.25.228.5 local pre-shared key authentication: id: 172.25.228.9 remote pre-shared key authentication: id: 172.25.228.5 con1000: TUNNEL, rekeying every 3060s, dpd action is restart local: 0.0.0.0/0|/0 remote: 0.0.0.0/0|/0 ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400 tunnel inet 172.25.228.9 --> 172.25.228.5 inet6 fe80::ecb1:1d31:aa45:6ee%ipsec1000 prefixlen 64 scopeid 0x9 inet 172.22.177.1 --> 172.22.177.2 netmask 0xfffffffc groups: ipsec reqid: 1000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Updated by Jim Pingle over 5 years ago
- Assignee set to Jim Pingle
- Target version set to 2.5.0
The behavior is consistent with the config, which is set for auto=start
. That connects at startup, but won't reconnect. Unfortunately, setting that to auto=route
doesn't appear to work for VTI, which is likely why the backend is set to force that to auto=start
for VTI interfaces. I suspect auto=route
doesn't work because it relies on trap policies, but VTI cannot not install any policies, so it can't find anything to do.
I have been able to sort of work around this with closeaction=restart
but then it always keeps two instances of the child SA open if both sides initiate. Might need a GUI option to control that, and then only set it on one side (like setting one side responder only). When set this way you cannot manually disconnect the tunnel because strongswan will always immediately reestablish the child SA, but that is a good thing in this case.
I'll work on adding a GUI option for the various closeaction values:
closeaction = none | clear | hold | restart defines the action to take if the remote peer unexpectedly closes a CHILD_SA (see dpdaction for meaning of values). A closeaction should not be used if the peer uses reauthentication or uniqueids checking, as these events might trigger the defined action when not desired. Prior to 5.1.0, closeaction was not supported for IKEv1 connections.
This could be beneficial for other non-VTI cases as well.
Updated by Jim Pingle over 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 85c85e89ec7fad6974cd008d1f25676adf8e288d.
Updated by Jim Pingle about 5 years ago
- Target version changed from 2.5.0 to 2.4.5
Updated by Jim Pingle about 5 years ago
- Status changed from Feedback to Resolved
Close Action option is present in the GUI and is working as expected in 2.4.5.a.20191218.2354