Home / server / Questions / 939301
Accepted
BTR Naidu
Asked: 2018-11-10 03:30:37 +0800 CST

Can't connect to ipsec server running in docker behind firewall

  • 772

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?

vpn

1 Answers

  1. Best Answer

    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.

    • 3