Bug #9767
closed
Interesting 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 4 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 4 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 85c85e89ec7fad6974cd008d1f25676adf8e288d.
Updated by Jim Pingle over 4 years ago
- Target version changed from 2.5.0 to 2.4.5
Updated by Jim Pingle over 4 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