IPSec tunnel - No traffic

[bpados]

I'm not seeing phase2 related errors.

[Derelict]

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.

[bpados]

Phase 2 been coming up for weeks now.

[stephenw10]

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

[bpados]

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

[stephenw10]

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

[bpados]

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

[Grimson]

Might be a shot into the dark, but what are your firewall rules for IPsec? Did you add rules for the new tunnels?

[stephenw10]

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

[bpados]

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

[stephenw10]

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

[bpados]

I know but it doesn't.

[Derelict]

Please run the ping test again and post another shot of Status > IPsec with the phase 2 expanded. Thanks.

[sgw]

@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.

[Derelict]

If you know you're hijacking why not just start another thread?

[sgw]

@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

[sgw]

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.

[Derelict]

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.

[Derelict]

Looks fine. How are you testing?

Did you install any policy routing on the LAN rules?

[sgw]

@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.