Site to Site with two pfsense boxes
-
I'm not a networking expert, been trying to fake it till I make it for a few days now. I've read and followed guides upon guides. I just don't know what I don't know. I'm hoping you guys can help out and figure out where this thing is failing. Anything I may have missed let me know and I'll try my best to answer. Thanks in advance for your time.
Site 1: pfsense cloud instance
Site 2: pfsense behind ubiquiti USG (ports opened to allow tunnel traffic through) at home.Site 1 WAN: 108.61.132.110
LAN: 192.168.0.0/24
Firewall Rules: WAN: Source - Site 2 IP, Destination - WAN address.
LAN&IPsec Allow anySite 2 WAN: 107.9.10.117
(USG) LAN: 192.168.1.0/24
(USG) Firewall rules: WAN - allow all IPsec ports. LAN - Allow All
(PFSENSE) WAN: 192.168.1.125/LAN: 192.168.11.0/24
(PFSENSE) Firewall rules: WAN - allow all . LAN - Allow AllHere are the configs.
Site 1
Site 2
Site 1 Log
Site 2 Log
-
log 1 -> found 1 matching config, but none allows pre-shared key authentication using Main Mode
log 2 -> received AUTHENTICATION_FAILED error notifyEnter the Pre-Shared Key string. This key must match on both peers.
This key should be long and random to protect the tunnel and its contents. A weak Pre-Shared Key can lead to a tunnel compromise. -
I didn't snippet that part of the config for obvious reasons but the two PSKs are identical.
-
i have made a test with your configuration and it is working on my side the only difference is that i have 2 pubblic ip to test with, i see you have a USG in the middle on site 2
Try with NAT-Traversal Force
what i notice is that on log 2 you have
12[NET]<conn1000|3>sending packet: from 192.168.1.125[500] to 108.61.132.110[500]
but maybe 192.168.1.125 is not the ip site 1 is expecting
or change the other end of the tunnel to peer 0.0.0.0 so it would just listen for a connection -
I set the NAT-T to force on both sides of the tunnel. It's still getting an error on authentication. Everything looks right. As the logs above show the encryption settings for both p1 and p2 match. I've re-verified the PSK is identical on both boxes. Is there any setting somewhere else that I've missed that might be causing the tunnel to fail?
Jul 22 12:23:37 charon 01[IKE] <con1000|12> received NAT-T (RFC 3947) vendor ID Jul 22 12:23:37 charon 01[CFG] <con1000|12> selecting proposal: Jul 22 12:23:37 charon 01[CFG] <con1000|12> proposal matches Jul 22 12:23:37 charon 01[CFG] <con1000|12> received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Jul 22 12:23:37 charon 01[CFG] <con1000|12> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Jul 22 12:23:37 charon 01[CFG] <con1000|12> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Jul 22 12:23:37 charon 01[IKE] <con1000|12> reinitiating already active tasks Jul 22 12:23:37 charon 01[IKE] <con1000|12> ISAKMP_VENDOR task Jul 22 12:23:37 charon 01[IKE] <con1000|12> MAIN_MODE task Jul 22 12:23:37 charon 01[ENC] <con1000|12> generating ID_PROT request 0 [ KE No NAT-D NAT-D ] Jul 22 12:23:37 charon 01[NET] <con1000|12> sending packet: from 192.168.1.125[500] to 108.61.132.110[500] (372 bytes) Jul 22 12:23:37 charon 12[NET] <con1000|12> received packet: from 108.61.132.110[500] to 192.168.1.125[500] (372 bytes) Jul 22 12:23:37 charon 12[ENC] <con1000|12> parsed ID_PROT response 0 [ KE No NAT-D NAT-D ] Jul 22 12:23:37 charon 12[IKE] <con1000|12> local host is behind NAT, sending keep alives Jul 22 12:23:37 charon 12[IKE] <con1000|12> remote host is behind NAT Jul 22 12:23:37 charon 12[IKE] <con1000|12> reinitiating already active tasks Jul 22 12:23:37 charon 12[IKE] <con1000|12> ISAKMP_VENDOR task Jul 22 12:23:37 charon 12[IKE] <con1000|12> MAIN_MODE task Jul 22 12:23:37 charon 12[ENC] <con1000|12> generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] Jul 22 12:23:37 charon 12[NET] <con1000|12> sending packet: from 192.168.1.125[4500] to 108.61.132.110[4500] (108 bytes) Jul 22 12:23:38 charon 12[NET] <con1000|12> received packet: from 108.61.132.110[4500] to 192.168.1.125[4500] (92 bytes) Jul 22 12:23:38 charon 12[ENC] <con1000|12> parsed INFORMATIONAL_V1 request 245351411 [ HASH N(AUTH_FAILED) ] Jul 22 12:23:38 charon 12[IKE] <con1000|12> received AUTHENTICATION_FAILED error notify Jul 22 12:23:38 charon 12[IKE] <con1000|12> IKE_SA con1000[12] state change: CONNECTING => DESTROYING
-
on site 1
Peer Identifier -> any -
I decided to test without the USG in front. USG NAT was the issue. The tunnel is active however no traffic is passing through. both sites the firewall rules allow any protocols on both the LAN and IPsec sides.
If I'm pinging from site 1(192.168.0.0) via pfsense webfig
-
Can ping 192.168.0.4(itself)
-
Can ping 192.168.0.3(server 2016 box)
-
Cannot ping 192.168.11.1 (LAN of site two pfsense)
-
Cannot ping 192.168.11.10 (Win 10 Client at site 2)
If I'm pinging from site 2(192.168.11.0) via pfsense webfig
-
Can ping 192.168.11.1(itself)
-
Can ping 192.168.11.10(win 10 box)
-
Cannot ping 192.168.0.4 (LAN of site one pfsense)
-
Cannot ping 192.168.0.3 (server 2016 at site 2)
-
-
if you use ipsec you can't ping from the pfsense gui.
You MUST use a host in the network
it is "normal" that you can't ping via pfsense gui
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/accessing-firewall-services-over-ipsec-vpns.html -
You can ping from the pfSense GUI if one of the firewall interfaces is an interesting source for the traffic selector.
For instance, if the pfSense LAN network is a local network in IPsec you just need to select LAN as the Source address in Diagnostics > Ping. It sets the
-S
flag to theping
command.