Project

General

Profile

Bug #9767

Interesting Traffic Will not Initiate an IPsec VTI tunnel.

Added by Chris Linstruth about 1 month ago. Updated about 1 month ago.

Status:
Feedback
Priority:
High
Assignee:
Category:
IPsec
Target version:
Start date:
09/16/2019
Due date:
% Done:

100%

Estimated time:
Affected Version:
Affected Architecture:

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>

Associated revisions

Revision 85c85e89 (diff)
Added by Jim Pingle about 1 month ago

Add GUI option for IPsec tunnel closeaction. Fixes #9767

Revision 7529f168 (diff)
Added by Jim Pingle about 1 month ago

Add GUI option for IPsec tunnel closeaction. Fixes #9767

(cherry picked from commit 85c85e89ec7fad6974cd008d1f25676adf8e288d)

History

#1 Updated by Jim Pingle about 1 month 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.

#2 Updated by Jim Pingle about 1 month ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Also available in: Atom PDF