IPSEC site to site VPN tunnel established but not passing traffic between local subnets
-
@twocrutchez thanks for clarifying. When you ping devices on the other side are you doing it from the pfsense router itself via diagnostic tab or from a local client? Or both? Do you know what the firewall rule(s) on the other side are. With site to site IPSec, rules on the other side control what your remote side is able to do/access. That is, if pfsense network is 10.10.10.0/24 you’d need either an allow all to all rule on the other side, or a rule that says, allow if source network is 10.10.10.0/24 to any (or your remote subnet). Make sense? Can the remote side ping pfsense network? Your allow all firewall rule certainly shouldn’t be blocking anything.
-
@gabacho4 ping to the gateway on the other side shows 100 percent packet loss via the diagnostic tab ping and host unreachable via the 192.168.10.7 host that is on my LAN. Since the host is in my LAN, do I also need a rule on my LAN side allowing the remote host or just in the ipsec tab? I'm not sure on the other side firewall I'll have to wait for a response from the tech who set that up but they're saying that it's not a firewall issue on their side and their not receiving any of the pings I send. They say it shows as incomplete and aged out on their side.
-
@twocrutchez rule on the IPSec tab should be all that is needed. I have experience with pfsense to pfsense site to site IPSec so I’ve not endured the joy of mixing vendors. I don’t think you should need the static route you mentioned in your first post. Have you tried a packet capture to see if you can see packets moving over the IPSec connection when you ping the other end? Can you take screenshots of your p1 and p2 settings?
Lastly, I found this link which might be of help
https://getlabsdone.com/how-to-setup-ipsec-tunnel-between-paloalto-and-pfsense/
Not being able to access and verify settings on the remote end makes this a bit more challenging.
-
@gabacho4 I did see that link yesterday. I have a feeling his proxy ID is wrong but I have to wait to verify
I can drill down into P1 and P2 when I have more time I'd just have to do a lot of sanitizing of the screenshots. For now here is the status page. I have not tried a packet capture yet.
-
@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