IPSec tunnel - No traffic
-
I have a similar problem with pfSense 2.4.4.
LAN interface stops routing traffic, tunnels stop working after some minutes or sometimes hours
I have multiple Phase 2 tunnels, if i restart a computer in local network or restart IPsec service multiple times and try to ping tunnel remote IP then tunnels start to get packets but after a while traffic stops again.
People had the same problem before : https://forum.netgate.com/topic/98893/pfsense-2-3-lan-interface-stops-routing-traffic-stops-working-after-2-or-3-day
And it was fixed with 2.3.1, i think it was a solution by disabling all but 1 CPU. May it be the same?
-
If it works at all on upgraded devices then you have a different issue. Please start a new thread to address that.
Steve
-
Sorry. Still having this issue I'll try to get some ipsec status printed out this week. It's been busy.
Thank you. -
Just to confirm; the traffic counters on the phase 2 status shows 0 at both ends and in both directions?
Steve
-
You just pointed out to something I never paid attention to.
In lack of time I looked at one of the setups and Connection is established but phase to status is not available on the connection that's not working. -
Ah, phase 1 comes up but not phase 2? Then check for a mismatch there. The IPSec logs should show an error.
Steve
-
No intention of hijacking the thread.
I'm using 2.4.4-RELEASE (amd64)
built on Thu Sep 20 09:33:19 EDT 2018
FreeBSD 11.2-RELEASE-p3I create an ipSec tunnel with identical configuration of others created on a previous rev (2.4.3p1) and the tunnel itself establishes, but no traffic passes through. On the phase 2 items, they're configured in a fashion similar to the other working tunnels. One thing I noticed that was very strange. In Static -> IPsec -> SADs, the whole section on this 2.4.4 instance is EMPTY, but on the others, it's populated with two entries per phase 2 item.
-
The SADs will only appear once the tunnel is up. The SPDs should be be there whether it is up or not though.
If you see no SADs it's not establishing. Check the ipsec logs.
Steve
-
con2000: #3 toOffice pu.bl.ic.ip 10.xx.xx.xx NAT-T re.mo.te.ip re.mo.te.ip IKEv2
initiator 23725 seconds (06:35:25) AES_CBC
HMAC_SHA1_96
PRF_HMAC_SHA1
MODP_1024 ESTABLISHED
4026 seconds (01:07:06) agoStatus shows as "ESTABLISHED" for the main tunnel.
log snippet:
Nov 8 18:28:26 charon 09[NET] <con2000|3> received packet: from re.mo.te.ip[4500] to 10.xx.xx.1[4500] (76 bytes)
Nov 8 18:28:26 charon 09[ENC] <con2000|3> parsed INFORMATIONAL request 252 [ ]
Nov 8 18:28:26 charon 09[ENC] <con2000|3> generating INFORMATIONAL response 252 [ ]
Nov 8 18:28:26 charon 09[NET] <con2000|3> sending packet: from 10.xx.xx.1[4500] to re.mo.te.ip[4500] (76 bytes)
Nov 8 18:28:30 charon 12[CFG] vici client 574 connected
Nov 8 18:28:30 charon 16[CFG] vici client 574 registered for: list-sa
Nov 8 18:28:30 charon 16[CFG] vici client 574 requests: list-sas
Nov 8 18:28:30 charon 16[CFG] vici client 574 disconnected -
You want to look for log messages detailing bringing up the ESP inner tunnels based on the traffic selectors.
-
@derelict How do I do that? I'm in Status -> System Logs -> System -> General
what would I filter by? -
Look on the IPSec tab there. Errors will likely be evident just by reading it unless you have a few IPSec tunnels in which case they may be lost in the logging from that. Try restarting the problem tunnel and then immediately checking the IPSec log again.
Look for phase 2 issues such as those shown here:
https://www.netgate.com/docs/pfsense/vpn/ipsec/ipsec-troubleshooting.html#phase-2-network-mismatchSteve
-
Thanks, it was a phase 2 no acceptable ENCRYPTION_ALGORITHM found message
Mismatched AES128 on one side and AES256 on the other.Sorry for the thread-jack, I'll go away now.
-
I'm not seeing phase2 related errors.
-
That is all dead peer detection.
Your Phase 2 looks like it is coming up.
Obfuscating the private addresses makes it almost impossible to help you. Nobody cares what your private addresses are.
-
Phase 2 been coming up for weeks now.
-
Ok, so where are you actually sending traffic from?
Does pfSense have an IP in 192.168.27.0/24? If so try sending some pings to any address in 192.168.97.0/24 from Diag > Ping using the 192.168.27.0/24 interfaces as the source. Those should definitely appear in the traffic counter as outbound packets even if there are no replies.
Steve
-
from 192.168.27.1 to 192.168.97.1 No traffic is showing/passing on IPSEC.
PING 192.168.97.1 (192.168.97.1): 56 data bytes
--- 192.168.97.1 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss -
You didn't select a source interface as I said otherwise it would show that. That traffic won't go over the VPN unless the source IP matching the local subnet selector.
Steve
-
Sorry Steve. I did overlook that request.
PING 192.168.97.50 (192.168.97.50) from 192.168.27.1: 56 data bytes
--- 192.168.97.50 ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss -
Might be a shot into the dark, but what are your firewall rules for IPsec? Did you add rules for the new tunnels?
-
Ok so that target may not respond to pings or is blocked etc but did you see 10 packets on the Phase 2 status outbound?
Traffic from the firewall itself should always be allowed out across the tunnel. Unless you have specific blocking 'OUT' floating rules.
Steve
-
at this point for testing I have a very open rule set on both ends.
As for traffic It doesn't even display the phase2 for ipsec tunnels -
Your screenshot above shows the Phase 2 as established but the traffic counters show 0 packets in or out. After running that ping it should show 10 packets out.
Steve
-
I know but it doesn't.
-
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.