Page MenuHomeVyOS Platform

ipsec vpn sa showing down
Closed, ResolvedPublicBUG

Description

I am running HA on vyos. It looks like vpn is up but the status is showing down.

vyos@vyos:~$ show vpn ipsec sa
Connection                     State    Up    Bytes In/Out    Remote address    Remote ID    Proposal
-----------------------------  -------  ----  --------------  ----------------  -----------  ----------
peer-x.x.x.126-tunnel-vti  down     N/A   N/A             N/A               N/A          N/A

vyos@vyos:~$ sudo ipsec status all
Security Associations (1 up, 1 connecting):
  no match

vyos@vyos:~$ cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl

config setup


conn %default
	keyexchange=ikev1


conn peer-x.x.x.126-tunnel-vti
	left=x.x.x.254
	right=x.x.x.126
	leftsubnet=0.0.0.0/0
	rightsubnet=0.0.0.0/0
	leftsubnet=0.0.0.0/0
	ike=aes256-sha1-modp1536!
	keyexchange=ikev1
	ikelifetime=3600s
	dpddelay=15s
	dpdtimeout=60s
	dpdaction=restart
	esp=aes256-sha1-modp1536!
	keylife=3600s
	rekeymargin=540s
	type=tunnel
	compress=no
	authby=secret
	mark=9437185
	leftupdown="/usr/lib/ipsec/vti-up-down vti0"
	auto=start
	keyingtries=%forever
#conn peer-x.x.x.126-tunnel-vti

vyos@vyos:~$ sudo ipsec statusall peer-x.x.x.126-tunnel-vti
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.12-amd64-vyos, x86_64):
  uptime: 3 hours, since Feb 05 19:43:40 2019
  malloc: sbrk 2953216, mmap 0, used 831296, free 2121920
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 8
  loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default connmark stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock counters
Listening IP addresses:
  x.x.x.252
  x.x.x.254
Connections:
peer-x.x.x.126-tunnel-vti:  x.x.x.254...x.x.x.126  IKEv1, dpddelay=15s
peer-x.x.x.126-tunnel-vti:   local:  [x.x.x.254] uses pre-shared key authentication
peer-x.x.x.126-tunnel-vti:   remote: [x.x.x.126] uses pre-shared key authentication
peer-x.x.x.126-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
Security Associations (1 up, 2 connecting):
peer-x.x.x.126-tunnel-vti[7]: ESTABLISHED 108 seconds ago, x.x.x.254[x.x.x.254]...x.x.x.126[x.x.x.126]
peer-x.x.x.126-tunnel-vti[7]: IKEv1 SPIs: e435dd6dd79e47bd_i* b98097053e39a527_r, pre-shared key reauthentication in 44 minutes
peer-x.x.x.126-tunnel-vti[7]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
peer-x.x.x.126-tunnel-vti{6}:  REKEYED, TUNNEL, reqid 2, expires in 12 minutes
peer-x.x.x.126-tunnel-vti{6}:   0.0.0.0/0 === 0.0.0.0/0
peer-x.x.x.126-tunnel-vti{7}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: c3409a62_i c494026a_o
peer-x.x.x.126-tunnel-vti{7}:  AES_CBC_256/HMAC_SHA1_96/MODP_1536, 34176 bytes_i (284 pkts, 0s ago), 44207 bytes_o (195 pkts, 0s ago), rekeying in 43 minutes
peer-x.x.x.126-tunnel-vti{7}:   0.0.0.0/0 === 0.0.0.0/0
peer-x.x.x.126-tunnel-vti[5]: CONNECTING, x.x.x.254[%any]...x.x.x.126[%any]
peer-x.x.x.126-tunnel-vti[5]: IKEv1 SPIs: f06be25b4f0bcf53_i* 0000000000000000_r
peer-x.x.x.126-tunnel-vti[5]: Tasks queued: QUICK_MODE QUICK_MODE
peer-x.x.x.126-tunnel-vti[5]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD
peer-x.x.x.126-tunnel-vti[1]: CONNECTING, x.x.x.254[%any]...x.x.x.126[%any]
peer-x.x.x.126-tunnel-vti[1]: IKEv1 SPIs: 643469eb61e4dce8_i* 0000000000000000_r
peer-x.x.x.126-tunnel-vti[1]: Tasks queued: QUICK_MODE
peer-x.x.x.126-tunnel-vti[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0 LTS
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Event Timeline

I’ll add that I think this is happening because of the .252 and .254 addresses. The 254 address connects, but the 252 address is marked in a constant state of connecting.

This really isn’t a bug in the reporting or parsing, but more an oddity occurring because IPSec is attempting to connect on two addresses on the same subnet. With the listen-address set, this seems like a bug.

syncer changed the task status from Open to Needs testing.Apr 17 2019, 8:06 PM
syncer assigned this task to zsdc.
syncer triaged this task as Low priority.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.
zsdc set Is it a breaking change? to Unspecified (possibly destroys the router).
Unknown Object (User) added a subscriber: Unknown Object (User).Aug 20 2020, 6:03 PM