IPsec PassThru Not Working
Our setup– Branch office with Juniper firewall doing site-to-site VPN with Juniper in colocation, via Routed IPSec tunnel.
Branch office WAN link was upgraded, beyond throughput capacity of the current Juniper box. I built a pfSense box to replace it, which easily handles the new WAN speed. Installed as 2.2.3, upgraded to 2.2.4.
I understand pfSense doesn't currently support Routed IPsec tunnels, so I put the Juniper box behind pfSense to handle the VPN tunnel.
So the path between premises Juniper and colo Juniper is:
[Juniper WAN port] –> [pfSense] –> world --> [Juniper @ colo]
** NOTE: I'm only interested in getting the tunnel up right now. I'll handle routing traffic through it after the tunnel problem is solved.
Logged on to the console of the Juniper. Tunnel won't come up. (Junipers are configured so that either endpoint can establish the connection.)
I added port forwarding rules on pfSense (which auto-created the firewall rules) to send inbound VPN traffic to Juniper:
- 500/UDP –> WAN port on Juniper
- 1701/TCP --> WAN port on Juniper
- ESP --> WAN port on Juniper
- AH --> WAN port on Juniper
- even tried 4500/NAT-T --> WAN port on Juniper
Tunnel still won't come up.
Read another post about setting Outbound NAT to Manual and disabling all NAT rules for port 500. Still no joy.
Am I overlooking something, or is there no way to get a site-to-site VPN device behind pfSense to establish a tunnel to the device in colo?
Anybody, any ideas? Unfortunately, I'll have to scrap this project and buy another Juniper if we can't get the tunnel working thru pfSense. Was really hoping to put pfSense into live production as a pilot, to consider for other locations, but things are looking a little bleak at the moment, unfortunately.
cmb last edited by
NAT is what's at question here, nothing to do with IPsec, moved thread.
Appears you have all the proper things forwarded (and then some). Should just need UDP 500 and 4500 and ESP (if not using NAT-T). That's likely a problem with your Juniper config, possibly related to the use of NAT, like using IP identifiers it auto-fills on both sides, which would leave you with a mismatch as one end would have a public IP and one private. Or the fact it's behind NAT leaving one side requiring NAT-T, and maybe the other side not allowing it.
rerouted last edited by
I had a similar issue when I upgraded trying to pass IPsec (udp 500, 4500, 1701) through the pfSense box. I was able to resolve this by making sure all the builtin pfSense IPsec and other VPN server features are disabled and not running. Then is started to work. If that fixes it then it leads me to believe there is a bug in the VPN and port forwarding running at the same time.
Thanks for all the suggestions, but still no joy. I ran through all the settings for at both ends for peer identifiers, NAT-T, ports, making sure no services on pfSense were running that might cause conflict, etc. Just can't get the tunnel up when one end is behind pfSense.
At this point I've run out of time, and am going to place an order for a new Juniper.
I really liked pfSense in the time I worked with it, insofar as performance and clean GUI. Unfortunately, it can't do routed IPsec which is a dealbreaker– except in this instance I was going to recycle the old Juniper already at this location and make it an endpoint inside the LAN.
Maybe if or when routed IPsec is supported, I'll give it another try. Thanks again for all the suggestions.
rerouted last edited by
Sorry to hear you jumping back to Juniper. I am not sure what device you have pfSense running on but I know you did not pay for the software. I know Juniper hardware will cost much more but have you looked into pfSense paid support first? I have not personally used it but all I hear is great things about it in the forums and they will turn around a fix for you ASAP. Maybe try that first since you have no $$ invested in pfSense and see if they can help you out. Don't get me wrong the forums do offer great support but not enterprise grade and no quick turn-around.
Just an idea before you go back to "the dark side" ;D
Because the underlying OS (FreeBSD) doesn't support routed IPsec at the moment, I don't expect pfSense to perform miracles. (the irony is JUNOS is based on FreeBSD, but they obviously have other things under the hood)
Routed IPsec is what connects all of our branches, corporate main, admin centers, and colo together. Without it, we're dead in the water.
I have been wanting to experiment with pfSense for quite a while but didn't have the opportunity. While I couldn't use it for new offices (due to no routed IPsec), this office was different because I had the old Juniper to open a tunnel to the rest of the company from inside the LAN. Unfortunately it didn't work out because the tunnel would not stand up behind NAT, no matter what I did.
Even if it did work, it would be limited to this one location. New locations will still need a Juniper for routed IPsec.
Although my time with it was cut short, pfSense seemed like a really nice product. If FreeBSD bakes in routed IPsec support, or if the pfSense developers can build it in themselves, I'll definitely have another look. I like the idea of running on an open source platform, not locked in to a specific vendor.
I also like that the pfSense folks sell commercial appliances with custom images, as well as commercial support. We keep all of our devices under vendor support contracts. For this test, I was using a new HP ProLiant server– one of our hot-spare chassis we keep on hand for emergency swapouts-- so we'd spend money either way. Whether we buy another Juniper, or a server chassis + pfSense, or a pfSense appliance, it's still not free. I would never run a commercial environment on freeware without paid support.