IPSEC site to site VPN tunnel established but not passing traffic between local subnets
-
@twocrutchez yeah I guess it would make more sense to wait for the other side to get back to you with the settings. Would be cool if they could just give you screenshots for your reference. I’m by no means an IPSec guru. I’ve found IPSec connections between pfsense boxes to be fairly easy to set up, even behind NAT. From the link you and I have both found, it seems there is more bottonology involved on the palo side.
-
@gabacho4 my key lifetime was off. Switched that but still getting timeouts. Only question mark on my side is that the admin on the other side is using aes 256 cbc. There's not an explicit option for cbc in pfsense but I read a post that just AES is considered aes cbc. Is that true?
-
Also, the engineer on their side is suggesting that Palo alto doesn't support policy based routing and that I check my routes and point to a tunnel like he did.
Screenshots from his side attached
-
@twocrutchez my understanding is that aes 128 is CBC. You should be fine there. From your earlier screenshots you also appear to using SHA256 and DH 20 but definitely double check that.
Based on what your guy is telling you, it seems very possible that he is using a Routed IPSec (Virtual Tunnel Interface) connection. The jargon that he is using, along with the screenshots and some documentation that I looked at suggest this strongly to me. VTI is much easier to manage, creates an interface over which you can policy route traffic, and requires a static route(s) to be created. I would very much suggest you might give it try and see how it works. If Palo Alto doesn’t do policy IPSec the the only thing left is Routed IPSec.
I am a bit confused as Palo Alto suggests their devices do policy IPSec.
https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/vpns/set-up-site-to-site-vpn/set-up-an-ipsec-tunnel
For Routed IPSec though, you will need a subnet for the tunnel and then you create static routes for the subnet(s) that should be accessible over the tunnel. The below was a great hangout that Jim Pingle did a while back and it has a good step by step as far as the pfsense side is concerned.
https://www.slideshare.net/NetgateUSA/routed-ipsec-on-pfsense-244-pfsense-hangout-june-2018
Really seems to me that having a strong understanding of what type of setup the other side is using is key. As I haven’t dealt with Palo Alto it’s possible I’m missing an easy clue but the jargon used really seems similar to the VTI feature on pfsense.
-
@gabacho4 yeah it definitely is. The only part I'm unsure of is creating the subnet and pointing my LAN device to use that over the tunnel but I'll watch the hangout.
Thanks for all your help!
-
@twocrutchez no problem, though I think I might be wrong. IPSec on Palo Alto appears to be way more complicated than on pfsense. This walkthrough seems to show many of the same details that your colleague is using.
https://blog.fuelusergroup.org/how-to-build-an-ipsec-tunnel-between-a-palo-alto-networks-firewall-and-a-pfsense-firewall
You would use a policy IPSec connection but need to make sure that your P1 and P2 settings match the Palo Alto side 100%. He’s the only one that has to worry about static routes and tunnel names etc.
I’d double and triple check your p1 and P2 settings. Make sure you are using IKEv2. Sorry for the about face but that tutorial really clarified things for me.
-
@gabacho4 No worries, thats what I figured because I saw multiple tutorials between pfsense and PA and nothing mentioned static routes. The only thing not clear to me is how to replicate aes cbc on pfsense side. But we can try 3DES temporarily
-
@twocrutchez nah don’t do that. Just go with AES 128/256. Whatever the other side is using. That will be it. The key is that the P1 and P2 must match the other side completely.
-
@twocrutchez any luck?
-
@gabacho4 Ended up getting support on the case. Ended up being a couple different things. I had a second adapter for testing on my host machine in the same subnet as the VPN which caused some issues. It also appeared to be some firewall rules on their end. I still can't ping them but the devices are talking back to controllers so they must just be blocking icmp