Cisco VPN UDP Client inside network and using public IP address
-
Hi everybody.
I have some clients inside our network that uses Cisco Ipsec Over UDP to connect into an University. PFsense firewall is in the border.
Our network does not perform NAT. Every single IP address are public and valid. Our PFsense only routes and perform inbound blocking. No outbound traffic is blocked.
When a client tries to connect, the connection is performed with success, but no traffic works inside the tunnel network.
I have tried to disable transparent tunnel, same result.
Of course, if clients try to connect through their homes or through a wifi router that performs NAT inside our network, everything works fine (connection and traffic inside tunnel).
As this is a new situation for me, my questions are:
1. Does IPsec over UDP works only through NAT?
2. Is there any thing that I need to adjust in PFSense to make it work?PFsense version: 2.3.3-RELEASE-p1
Thanks for the help.
-
If it's "IPsec over UDP" do you mean like NAT-T where everything runs over UDP/4500? That should work from anywhere, with or without NAT.
If it's regular IPsec, it uses udp/500 to establish the tunnel but ESP to pass data. Perhaps you are not passing ESP traffic, or it's getting blocked upstream?
-
Hi Jimp, thanks for your answer.
It is regular IPsec, with UDP 500 and ESP.
My firewall does not perform outbound filtering. I use the default allow all rule.
If a user installs a router inside my network and perform NAT, users using this connection are able to connect and send data through the tunnel. So I believe that my PFsense firewall are not blocking anything.
But if I connect directly, without NAT and with my public IP address, the connection is OK, but no traffic passes through the tunnel.Upstream do you mean with my ISP or my PFSense gateway? I am also checking that.
Is there something missing in my PFSense to recognize and allow this traffic?
Thanks one more time.
-
If you are passing everything and outbound NAT is completely disabled, then you shouldn't need to do anything else.
-
OK, no NAT and blocking on forward rules.
The VPN->Ipsec tab only refers to settings when the PFSense firewall is enabled as the VPN server and there is nothing there do enable/disable to make the ESP traffic passing through, right?
Do you have any tips for me to check or the problem is perhaps on the external destination network, where the VPN Server remains?
Thanks
-
The VPN->Ipsec tab only refers to settings when the PFSense firewall is enabled as the VPN server and there is nothing there do enable/disable to make the ESP traffic passing through, right?
Correct.
Do you have any tips for me to check or the problem is perhaps on the external destination network, where the VPN Server remains?
It's possible it works behind NAT because the endpoints see the NAT and switch to NAT-T which uses udp/4500. Without NAT, IPsec will want to use udp/500 and ESP. If your network has trouble passing out and receiving ESP traffic, that might cause it to fail in the way you describe.
Check Diagnostics > States while a client tries to connect, see if you see both the UDP and ESP states and what their status is. Run packet captures on WAN looking for ESP traffic as clients try to make connections inside the VPN, see how that traffic is flowing.
-
OK, here are the results of some tests that I performed this morning:
1. I have installed a Virtual Machine inside Virtual Box to perform the tests. I have simulated the connection with and without NAT. Both of them are using our network behind PFSense.
It's possible it works behind NAT because the endpoints see the NAT and switch to NAT-T which uses udp/4500. Without NAT, IPsec will want to use udp/500 and ESP. If your network has trouble passing out and receiving ESP traffic, that might cause it to fail in the way you describe.
You are completely right about NAT detection. When I try the connection via NAT, Wireshark shows that a first connection on UDP 500 is made, after it is changed to UDP 4500, and the tunnel works perfectly.
After changing the Virtual Machine NIC to bridge and assign a Public IP address, the connection to authenticate is performed successfully on UDP 500 and the VPN connect and authenticate, but the remaining connections still occurs on UDP 500 and tunnel traffic does not work.
The thing I don't understand is why the first connection at UDP 500 works and users are able to authenticate, which confirms that this type of connection can pass through the firewall, and the remaining connections on the same port does are not working.
Check Diagnostics > States while a client tries to connect, see if you see both the UDP and ESP states and what their status is. Run packet captures on WAN looking for ESP traffic as clients try to make connections inside the VPN, see how that traffic is flowing.
I have posted some images to ilustrate that. All captures are from the Virtual Machine, except from the "Traffic Wan Interface PFSense Without NAT image". This one is from PFsense packet capture.
The last test that I have performed is to create a floating rule, allowing any traffic on UDP 500 on any direction and any interface. Same result.
It is possible that PFsense is having trouble to identify this type of traffic? I don't know if there is any other test that I can do.
I really need to get this working and I appreciate your help.
 -
UDP/500 only establishes the tunnel it does NOT carry traffic.
IPsec traffic, without NAT-T, is carried using ESP (Encapsulating Security Payload) protocol, which is NOT UDP or TCP, but its own separate protocol.
That ESP traffic is what appears to be not passing in your environment.
-
UDP/500 only establishes the tunnel it does NOT carry traffic.
IPsec traffic, without NAT-T, is carried using ESP (Encapsulating Security Payload) protocol, which is NOT UDP or TCP, but its own separate protocol.
That ESP traffic is what appears to be not passing in your environment.
Once again, you're right. But the problem was not in my network/firewall, but inside the service provider, and we are discussing the possibilities to make the ESP traffic to pass through.
In the meantime, configuring the clients to force NAT-T to connect has solved the problem.Thank you.
