Page MenuHomePhabricator

ipsec vpn sa showing down
Needs testing, LowPublicBUG

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
liam created this task.Feb 5 2019, 11:45 PM
kroy added a subscriber: kroy.Feb 6 2019, 12:16 AM

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 assigned this task to zsdc.Wed, Apr 17, 8:06 PM
syncer triaged this task as Low priority.
syncer changed the task status from Open to Needs testing.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.