Site-to-site IPsec connected, but no data flow (?)
-
I have 2 pfSense boxes. Both have WANs attached to a switch attached to a Comcast EoHFC. Each WAN is on a separate IP within the 6 IPs we have from Comcast.
Thinking to experiment with IPsec site-to-site, I setup a connection between the two WANs.
In Status/IPSEC the connection shows as connected (on either pfSense box; I'm connecting my laptop to the LAN on first one, then the other.
However, when I try to ping pfSense box B's LAN address from pfSense box A (or vice versa), these fail.
Both boxes have 'pass everything' on IPsec.Do I need to create static routes? This hasn't been necessary with other firewalls I've used - and if I go to Status/IPsec/SPD, I see what appear to be routes.
I've been going over tunnel phase 1 and 2 on both boxes - and it looks right (using the pfSense Book's 'example IPsec' as a guide)
Any suggestions for things I should check?
Thanks! -
Same situation…
I'm going crazy. No traffic passed, tunnels are up.Status of IKE charon daemon (strongSwan 5.6.0, FreeBSD 11.1-RELEASE-p4, amd64):
uptime: 34 minutes, since Nov 21 23:31:39 2017
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
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
Listening IP addresses:
172.17.0.1
1.1.1.1
Connections:
con1: 1.1.1.1...1.1.1.2 IKEv2, dpddelay=10s
con1: local: [1.1.1.1] uses pre-shared key authentication
con1: remote: [1.1.1.2] uses pre-shared key authentication
con1: child: 172.17.0.0/24|/0 === 172.18.0.5/32|/0 TUNNEL, dpdaction=restart
con2: 1.1.1.1…1.1.1.3 IKEv2, dpddelay=10s
con2: local: [1.1.1.1] uses pre-shared key authentication
con2: remote: [1.1.1.3] uses pre-shared key authentication
con2: child: 172.17.0.0/24|/0 === 172.19.0.0/24|/0 TUNNEL, dpdaction=restart
con3: 1.1.1.1…1.1.1.3 IKEv2, dpddelay=10s
con3: local: [1.1.1.1] uses pre-shared key authentication
con3: remote: [1.1.1.4] uses pre-shared key authentication
con3: child: 172.17.0.0/24|/0 === 172.20.0.5/32|/0 TUNNEL, dpdaction=restart
Routed Connections:
con3{31}: ROUTED, TUNNEL, reqid 12
con3{31}: 172.17.0.0/24|/0 === 172.20.5/32|/0
con2{30}: ROUTED, TUNNEL, reqid 5
con2{30}: 172.17.0.0/24|/0 === 172.19.0.0/24|/0
con1{29}: ROUTED, TUNNEL, reqid 9
con1{29}: 172.17.0.0/24|/0 === 172.18.0.5/32|/0
Security Associations (2 up, 0 connecting):
con1[11]: ESTABLISHED 21 minutes ago, 1.1.1.1[hostname]…1.1.1.2[hostname2]
con1[11]: IKEv2 SPIs: 1efef03e2b08a88d_i* 7a41b86c18992768_r, rekeying disabled
con1[11]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
con1{23}: INSTALLED, TUNNEL, reqid 9, ESP SPIs: c00b6694_i cab18720_o
con1{23}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i (0 pkts, 1264s ago), 0 bytes_o, rekeying disabled
con1{23}: 172.17.0.0/24|/0 === 172.18.0.5/32|/0
con2[2]: ESTABLISHED 33 minutes ago, 1.1.1.1[hostname]…1.1.1.3[1.1.1.3]
con2[2]: IKEv2 SPIs: c7a47c3eb18f920c_i* d2ec51de7a9225b4_r, rekeying disabled
con2[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
con2{7}: INSTALLED, TUNNEL, reqid 5, ESP SPIs: c1a231c3_i cd541fd9_o
con2{7}: AES_CBC_256/HMAC_SHA1_96, 6384 bytes_i (76 pkts, 87s ago), 16568 bytes_o (109 pkts, 87s ago), rekeying disabled
con2{7}: 172.17.0.0/24|/0 === 172.19.0.0/24|/0