IPSec tunnel - No traffic
-
Please run the ping test again and post another shot of Status > IPsec with the phase 2 expanded. Thanks.
-
@derelict
another thread-hijacker here:
I see issues on a tunnel between my 2.4.4 SG-1000 and a remote SG-3100 on 2.4.3-p1 still.tunnel comes up, no traffic goes through .. no ping via shell, nothing seen in Status page.
disabled that new async-option, checked and upgraded strongswan (on SG-1000), re-saved tunnel configs, restarted IPSEC ... I will disable other tunnels and check back with a screenshot or so.
-
If you know you're hijacking why not just start another thread?
-
@derelict said in IPSec tunnel - No traffic:
If you know you're hijacking why not just start another thread?
because it might be the same issue/bug and it will be easier to search for that ... ? sorry
-
ipsec statusall Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p3, arm): uptime: 59 seconds, since Nov 13 19:49:59 2018 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5 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: 62.40.171.237 172.32.99.254 2001:470:6f:333::1 172.32.99.97 192.168.100.1 2001:470:6e:333::2 172.31.91.1 Connections: bypasslan: %any...%any IKEv1/2 bypasslan: local: uses public key authentication bypasslan: remote: uses public key authentication bypasslan: child: 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 === 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 PASS con13000: 62.40.171.237...89.221.HIDDEN.IP IKEv2, dpddelay=10s con13000: local: [62.40.171.237] uses pre-shared key authentication con13000: remote: [89.221.HIDDEN.IP] uses pre-shared key authentication con13000: child: 172.32.99.0/24|/0 === 172.20.95.0/24|/0 TUNNEL, dpdaction=restart Shunted Connections: bypasslan: 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 === 172.32.99.0/24|/0 2001:470:6f:333::/64|/0 PASS Routed Connections: con13000{1}: ROUTED, TUNNEL, reqid 1 con13000{1}: 172.32.99.0/24|/0 === 172.20.95.0/24|/0 Security Associations (1 up, 0 connecting): con13000[1]: ESTABLISHED 33 seconds ago, 62.40.171.237[62.40.171.237]...89.221.HIDDEN.IP[89.221.HIDDEN.IP] con13000[1]: IKEv2 SPIs: c7032e2b0033885b_i* 6f31cd51da0db2d3_r, pre-shared key reauthentication in 7 hours con13000[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 con13000{2}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c4103760_i cc791808_o con13000{2}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i (0 pkts, 33s ago), 0 bytes_o (0 pkts, 33s ago), rekeying in 44 minutes con13000{2}: 172.32.99.0/24|/0 === 172.20.95.0/24|/0
I masked the WAN-IP of the SG-3100 ... looks good to me aside from traffic going through.
Same tunnel worked already earlier today ... I can log in to the SG-3100, ping to WAN is fine. -
The only bug in play is what looks like issues in the async crypto in yet-to-be-identified edge cases.
Everything else is almost certainly misconfiguration.
-
Looks fine. How are you testing?
Did you install any policy routing on the LAN rules?
-
@derelict no, I did not. So far I ping from pfsense and my system behind.
You know what? Now that I stopped IPSEC completely after disabling everything execpt that one tunnel ... waited some minutes and started the IPSEC service again, it starts pinging again.
I will monitor this for the next few days .. Thanks so far. -
When you ping from pfSense you have to be sure to source it from something interesting to IPsec. Use the
-S
flag or the Source address pulldown in Diagnostics > Ping. -
@derelict said in IPSec tunnel - No traffic:
When you ping from pfSense you have to be sure to source it from something interesting to IPsec. Use the
-S
flag or the Source address pulldown in Diagnostics > Ping.will do, thanks. So far I mostly tested from my laptop (within LAN).
-
To be fair and maybe even help others here additional information:
It turned out that my local docker-installation sometimes used a subnet 172.20.0.0/16 that overlapped the subnet behind the pfsense-IPSEC-tunnel to my customer. So this lead to routing tables on my local machine pointing "somewhere else". The IPSEC-tunnel was working all the time. Thanks anyway.
-
Thanks for coming back with the note.