Pass through a FortiNet IPsec tunnel through pfSense?
-
I am trying to troubleshoot my wife's remote work VPN connection with the help of a few friends. She just received a laptop and her company is using FortiNet. The telemetry connection works fine and I can ping the VPN gateway, but the data tunnel fails. Bypassing the router and plugging directly into the ISP ONT allows the tunnel to connect. We have tried creating firewall rules and setting NAT to pass all data from/to the laptop through, we have tried port forwarding the IPsec ports to the laptop, and we even did a factory reset in case some obscure setting from a past config was causing a problem. pfSense Project tweeted back that I may need to create firewall rules to block IPsec, which honestly is not the answer any of us were expecting. Would creating block rules tell pfSense to not try passing it through IPsec and instead just send it through to the destination? What recommendation do you guys have for proceeding?
-
What do you mean the 'data tunnel fails'?
[1]If you have pfsense in place, do a packet capture that filters by the vpn server address and includes port filters for 500|4500 (stated just like this). If anything,
[2]make sure ports UDP 500 and UDP 4500 are permitted inbound explicitly on the pfsense - you may even want to forward them to her machine if her machine is the only one using IPSEC as an endpoint.
[3]Windows Firewall on LAPTOP, make sure there are 2 firewall rules for all 3 locations [ PUBLIC PRIVATE DOMAIN ] that
[a]permit udp 500 in [ with edge traversal enabled ]
[b]permit udp 4500 in [ edge traversal enabled ]When you say plugging directly into the ISP ONT, are you saying that her LAPTOP is getting assigned PUBLICLY ROUTABLE IP ADDRESS?
-
@HF1086 said in Pass through a FortiNet IPsec tunnel through pfSense?:
What do you mean the 'data tunnel fails'?
[1]If you have pfsense in place, do a packet capture that filters by the vpn server address and includes port filters for 500|4500 (stated just like this). If anything,
[2]make sure ports UDP 500 and UDP 4500 are permitted inbound explicitly on the pfsense - you may even want to forward them to her machine if her machine is the only one using IPSEC as an endpoint.
[3]Windows Firewall on LAPTOP, make sure there are 2 firewall rules for all 3 locations [ PUBLIC PRIVATE DOMAIN ] that
[a]permit udp 500 in [ with edge traversal enabled ]
[b]permit udp 4500 in [ edge traversal enabled ]When you say plugging directly into the ISP ONT, are you saying that her LAPTOP is getting assigned PUBLICLY ROUTABLE IP ADDRESS?
I mean that the IPsec tunnel fails to establish a connection. It calls out and then fails to get a response (per the logs from the FortiClient). We've been doing packet capture and log analysis and there are no errors showing in pfSense. We have set firewall rules to explicitly allow ESP and UDP 500/4500 through, we have established port forwarding, we set NET-transversal, we have tried every single possible setting that we could think of that might be affecting it and it won't work. I've never had any IPsec tunnel or device configured for anything on my network before.
I cannot do any configuration on the laptop because it is an enterprise device and they have it locked down. From the beginning they have claimed that it is a problem with my pfSense router, but after tonight I know it's not. Out of frustration I took a plain-Jane Netgear router with the out-of-the-box configuration - renamed the SSD and set a password - and it still won't connect the tunnel, so she is going to tell them tomorrow that it's a problem on their end.
Yes, when I said plugged into the ISP's ONT I meant giving the device a publicly routable IP address, and no I don't need a lecture on the dangers of that. It's not a permanent configuration, it was simply for the purpose of troubleshooting and removing a variable in the network configuration to determine if it was in fact a problem with my router.
-
Can you see UDP500|4500 'out' from your public IP address on the pfSense that matches the destination address?
[1]At a minimum if your rules are correct -you are going to see 'UDP 500' traffic in both directions - if you are not you have something wrong on your pfSense(make sure they are added to 'FLOATING' at the top) - All IPSEC traffic starts on UDP500 - all of it.
[2] if NAT is used it will change the MainMode messages to UDP 4500(which in your case will be a requirement) -If the IPSEC endpoint sits directly on the internet will use ESP type packets instead of UDP4500 - but these will not be applicable in your case. ESP will be sitting inside UDP4500 packets because of NAT
You should tell them to ensure 'NAT-T' is enabled/forced in the both the client/server configuration.
I ask because, if you do infact see your UDP500|UDP4500 then outward - they might not be forwarding 4500 back into themselves if the Fortigate is itself being NAT'd
-
@HF1086
I will have to ask my friend and/or check tonight when my wife gets home from work. My friend was the one doing the packet capture (we have a VPN set up and he has admin access to help out if I ever have trouble, like in this case). He said the traffic coming out looked fine.Edit: Just saw your edited post. My wife is going to tell their IT Dept to Cal me if they have questions so I will make sure to pass that on. I can tell you, from the horror stories that she's told me, I don't have a super ton of confidence in their IT Dept.
-
@HF1086 sorry just edited that post. but if you can guarantee your traffic out for UDP500|4500 with your public IP on the PFSense is occurring the onus is 100% on her company for correct NAT-T configuration
-
@HF1086 I'm going to try some more packet captures tonight to see what I can find. I also went and bought a Nighthawk R7000 today and got set up to try tonight. I confirmed that on both the old 4000 and the R7000 NAT-transversal is enabled by default, and they don't even have an option to configure it in the VPN settings. Sorry if I repeated some info here from earlier. I've been running around like crazy today and this has been adding a ridiculous amount of stress over the last few days.