has anyone seen this issue before:
.186 and .114 tunnels have many duplicates appearing, though I think it can happen with any. I dont know if this is also related to the memory leak issue Im seeing. Currently running: 1.2-rolling-201911161154
Hi @kav can you try update your router to the latest rolling release?
Will be good look into /var/atop/ for memory leak diagnostic
Hi @Dmitry
Have updated to latest rolling release now, will keep eye on memory consumption. The multiple tunnels issue is still occurring though.
Did you mean /var/log/atop/ ? What can I check?
Hi @kav, exactly /var/log/atop/. You need open these files and see memory utilisation, or provide all files from this directory and attach.
on the latest rolling release memory seems more stable. I will monitor a bit longer and attach logs if I notice memory leaking again.
Any idea on the duplicates being shown for VPN SA’s?
When I have two tunnels (2 pairs of remote/local, tunnel 1 & 2), it shows 4 SA’s, but it shows them all as ‘tunnel 1’
Doesnt seem to have the duplicates as it did with previous rolling release, but actual data seems wrong
Hi @kav, provide please configuration commands for these tunnels include ike and esp groups.
note: replace private data, ip addresses and shared secret
Its duplicating tunnels again. Here you go:
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn ipsec nat-traversal 'enable'
set vpn ipsec auto-update '60'
set vpn ipsec esp-group esp_1 compression disable
set vpn ipsec esp-group esp_1 lifetime 1800
set vpn ipsec esp-group esp_1 mode tunnel
set vpn ipsec esp-group esp_1 pfs disable
set vpn ipsec esp-group esp_1 proposal 1 encryption aes256
set vpn ipsec esp-group esp_1 proposal 1 hash sha1
set vpn ipsec ike-group ike_1 dead-peer-detection action restart
set vpn ipsec ike-group ike_1 dead-peer-detection interval 30
set vpn ipsec ike-group ike_1 dead-peer-detection timeout 120
set vpn ipsec ike-group ike_1 ikev2-reauth no
set vpn ipsec ike-group ike_1 key-exchange ikev2
set vpn ipsec ike-group ike_1 lifetime 3600
set vpn ipsec ike-group ike_1 proposal 1 dh-group 2
set vpn ipsec ike-group ike_1 proposal 1 encryption aes256
set vpn ipsec ike-group ike_1 proposal 1 hash sha1
set vpn ipsec site-to-site peer x.x.x.12 authentication id '@abc'
set vpn ipsec site-to-site peer x.x.x.12 authentication remote-id '@123'
set vpn ipsec site-to-site peer x.x.x.12 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer x.x.x.12 authentication pre-shared-secret 'somesecret'
set vpn ipsec site-to-site peer x.x.x.12 connection-type 'initiate'
set vpn ipsec site-to-site peer x.x.x.12 default-esp-group 'esp_1'
set vpn ipsec site-to-site peer x.x.x.12 ike-group 'ike_1'
set vpn ipsec site-to-site peer x.x.x.12 local-address '10.2.0.5'
set vpn ipsec site-to-site peer x.x.x.12 tunnel 1 local prefix '10.2.0.0/16'
set vpn ipsec site-to-site peer x.x.x.12 tunnel 1 remote prefix '10.0.0.0/16'
The other tunnels are similar, just with different prefixes:
set vpn ipsec site-to-site peer x.x.x.17 authentication id '@abcd'
set vpn ipsec site-to-site peer x.x.x.17 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer x.x.x.17 authentication pre-shared-secret 'somesecret'
set vpn ipsec site-to-site peer x.x.x.17 authentication remote-id '@1234'
set vpn ipsec site-to-site peer x.x.x.17 connection-type 'initiate'
set vpn ipsec site-to-site peer x.x.x.17 default-esp-group 'esp_1'
set vpn ipsec site-to-site peer x.x.x.17 ike-group 'ike_1'
set vpn ipsec site-to-site peer x.x.x.17 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer x.x.x.17 local-address '10.2.0.5'
set vpn ipsec site-to-site peer x.x.x.17 tunnel 1 local prefix '10.2.0.0/24'
set vpn ipsec site-to-site peer x.x.x.17 tunnel 1 remote prefix '192.168.11.0/24'Also I can see memory is slowly leaking again, though much slower than 1.2.x. Have attached atop logs.atop.log (5.1 MB)
It wouldnt let me attach a zip, so its renamed to .log, just rename to .zip.
I’m running VyOs V.1.2.5 and experience the same issue.
When the VPN tunnel is restarted (for example changing the logging level) it creates new phase 2 tunnels but keep the existing one.
The “old” tunnels doesn’t event disappear after the lifetime expiration.
My configuration is totally similar to Kav’s one except for the lifetimes and the fact I don’t use authentication ID.
This tunnel is established with a Fortinet peer (not under my control).
show vpn ipsec sa verbose
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.19.114-amd64-vyos, x86_64):
uptime: 23 hours, since Apr 20 14:15:04 2020
malloc: sbrk 2011136, mmap 0, used 1237712, free 773424
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
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:
203.0.113.17
Connections:
peer-198.51.100.137-tunnel-1: 203.0.113.17...198.51.100.137 IKEv2, dpddelay=15s
peer-198.51.100.137-tunnel-1: local: [203.0.113.17] uses pre-shared key authentication
peer-198.51.100.137-tunnel-1: remote: [198.51.100.137] uses pre-shared key authentication
peer-198.51.100.137-tunnel-1: child: 172.30.3.0/24 === 10.10.1.0/24 TUNNEL, dpdaction=clear
peer-198.51.100.137-tunnel-2: child: 172.30.3.0/24 === 10.10.3.0/24 TUNNEL, dpdaction=clear
peer-198.51.100.137-tunnel-3: child: 172.30.3.0/24 === 10.10.5.0/24 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
peer-198.51.100.137-tunnel-1[2]: ESTABLISHED 23 hours ago, 203.0.113.17[203.0.113.17]...198.51.100.137[198.51.100.137]
peer-198.51.100.137-tunnel-1[2]: IKEv2 SPIs: 30e0142ea546831c_i 9ad732d7615981e4_r*, rekeying in 39 minutes
peer-198.51.100.137-tunnel-1[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
peer-198.51.100.137-tunnel-3{16}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: c4842779_i 1f3fd6d7_o
peer-198.51.100.137-tunnel-3{16}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 2 minutes
peer-198.51.100.137-tunnel-3{16}: 172.30.3.0/24 === 10.10.5.0/24
peer-198.51.100.137-tunnel-2{17}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: cd0bfa20_i 1f3fd6d8_o
peer-198.51.100.137-tunnel-2{17}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 59039 bytes_i (574 pkts, 317s ago), 37194 bytes_o (574 pkts, 317s ago), rekeying in 7 minutes
peer-198.51.100.137-tunnel-2{17}: 172.30.3.0/24 === 10.10.3.0/24
peer-198.51.100.137-tunnel-1{18}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c83d47a9_i 1f3fd6d9_o
peer-198.51.100.137-tunnel-1{18}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i (0 pkts, 310s ago), 0 bytes_o, rekeying in 6 minutes
peer-198.51.100.137-tunnel-1{18}: 172.30.3.0/24 === 10.10.1.0/24
peer-198.51.100.137-tunnel-1{19}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cbd3cfeb_i 1f3fd6da_o
peer-198.51.100.137-tunnel-1{19}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 14957113 bytes_i (11062 pkts, 310s ago), 439873 bytes_o (7108 pkts, 310s ago), rekeying in 9 minutes
peer-198.51.100.137-tunnel-1{19}: 172.30.3.0/24 === 10.10.1.0/24
peer-198.51.100.137-tunnel-2{20}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: caeda430_i 1f3fd6db_o
peer-198.51.100.137-tunnel-2{20}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 3933535 bytes_i (38714 pkts, 317s ago), 2492789 bytes_o (38724 pkts, 317s ago), rekeying in 8 minutes
peer-198.51.100.137-tunnel-2{20}: 172.30.3.0/24 === 10.10.3.0/24
peer-198.51.100.137-tunnel-3{21}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: cf6ebf6c_i 1f3fd6dc_o
peer-198.51.100.137-tunnel-3{21}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 0 bytes_o, rekeying in 14 minutes
peer-198.51.100.137-tunnel-3{21}: 172.30.3.0/24 === 10.10.5.0/24Did you manage to solve this problem? We have the same one.
memory leak issue seems resolved with 1.3.x, duplicate tunnels appearing seems also resolved with latest rolling release but not 100%. I notice though the tunnels dont seem correctly numbered
You can see two remote endpoints/addresses and each has 2 tunnels, but they are both listed as being tunnel 1, I assume they should be tunnel 1 and tunnel 2 as per the remote/local peer config.