I have a setup which I dont think is very difficult but cant get it to work.

Working setup: An ipsec server running in a docker connected directly to internet. The clients can connect.

Not working setup: An ipsec server running in a docker connected to internet behind a firewall. I have node1 in an esxi server which acts as internet gateway and node2 running in same esxi server which has ipsec server running in a docker.

I have opened ports 500 and 4500 in node1 (internet gateway) and forwarded to node2 (running ipsec server in a docker).
The issue I am facing is, the clients are not able to connect.

Below is the iptables firewall rule

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

Not able to spot what else is missing. Can someone advise if my setup is correct and why it is not working?

  • 1
    NAT_TRAVERSAL is configured? I assume you use NAT in your 2nd setup. Ah, and depending on your configuration you need port 50 to be open for ESP. – Lenniey Nov 9 at 11:37
  • I have below rules in iptables firewall: -A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT -A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT -A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT – BTR Naidu Nov 9 at 12:00

Your iptables rules from the question comments:

-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 4500 -j ACCEPT 
-A FORWARD -d 192.168.2.37/32 -o ens34 -p udp -m udp --dport 53 -j ACCEPT

I don't really see why you'd need the port 53 forwarded: making the DNS server of your internal network visible to everyone on the internet is asking for DNS spoofing attacks - not a good idea. After the VPN connects, you'll be able to access it securely through the VPN pipe without any firewall rules on the internet gateway host. I'd recommend you remove the FORWARD rule for UDP port 53 unless you have a really good reason for it.

ACCEPT rules in iptables FORWARD filter table only allow the system to route traffic that is already properly addressed to the destination. Since your IPsec server seems to have an 192.168.*.* address, your clients cannot use that address to reach it through the internet.

Instead, you'll need to configure the clients to use the public IP address of the internet gateway server, and the gateway server needs some DNAT rules to redirect the incoming IPsec traffic to the IPsec server.

These rules are needed on the internet gateway server in addition to the FORWARD rules you already have:

-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 500 -j DNAT --to-destination 192.168.2.37:500
-t nat -A PREROUTING -i <internet-side NIC> -p udp -m udp --dport 4500 -j DNAT --to-destination 192.168.2.37:4500

Since there seems to be no automatic connection tracking for IPsec, you may also need the reverse rules for outgoing traffic:

-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 500 -j SNAT --to-source <public IP>
-t nat -A POSTROUTING -o <internet-side NIC> -s 192.168.2.37/32 -p udp -m udp --sport 4500 -j SNAT --to-source <public IP> 

(I'm not actually sure about this part: first try without these rules, and monitor the outgoing responses at the internet gateway host's internet-facing interface. If the outgoing IPsec packets have a 192.168.2.37 as their source IP, add the above 2 SNAT rules. If the source IP is already getting changed to the public IP of the internet gateway host, then the DNAT rule is successfully tracking the connection and you won't need the SNAT rules.)

When VPN traffic from the client arrives to the internet gateway host (initially using its IP address as its destination), the incoming traffic first passes through the PREROUTING table. The DNAT rules in them will replace the destination address. Then the incoming traffic goes through the routing check: since the DNAT rule just replaced the destination IP, the traffic is no longer addressed to the internet gateway host itself, so it goes through the routing table and then the FORWARD filter table. After that it goes out the internet gateway host's "inside" interface towards the IPsec host.

The IPsec host will receive packets with its own 192.168.2.37 address in the IP packet headers, but within the encrypted content, there will be the original public IP of the internet gateway server. The IPsec host must be NAT_TRAVERSAL aware to deal with this successfully.

When the IPsec host responds, the internet gateway host will need to replace the source IP of the outgoing IPsec packets with a valid public IP.

  • I will test the setup and come back with my comments. – BTR Naidu 11 hours ago
  • In the ipsec server log, I see "received packet: from 89.204.154.48[56939] to 172.17.0.6[500] (300 bytes)". I would have expected it to look like "received packet: from <internet_side NIC IP>[56939] to 172.17.0.6[500] (300 bytes)"? – BTR Naidu 11 hours ago
  • The source IP of the incoming packets is not changed at the gateway host. Only the destination IP of incoming packets and the source IP of outgoing packets will be changed by the NAT operation.Your gateway host needs to hide the private IP address space from the world to avoid routing problems, but there is no technical reason to hide the source IP from the destination in your gateway server. – telcoM 9 hours ago

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.