[GH-ISSUE #331] Cannot connect to server because of listening address problem

kerem commented

2026-03-02 08:01:15 +03:00

Owner

Originally created by @carbon-lab on GitHub (Dec 10, 2022).
Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/331

Checklist

[Y] I read the README
[Y] I read the Important notes
[Y] I followed instructions to configure VPN clients
[Y] I checked Troubleshooting, IKEv2 troubleshooting, enabled logs and checked VPN status
[Y] I searched existing Issues
[Y] This bug is about the IPsec VPN server Docker image, and not IPsec VPN itself

Describe the issue
The processes in docker are listening IP address 172.17.0.2 but not 0.0.0.0. So they cannot receive the udp data come from client whose target address is a public IP address but not 172.17.0.2.

I have tried to use netcat tool to test my network. This is the result:

The server host can receive the udp data (port 500 and 4500) from client netcat.
If I create a docker container with debian image whose configuration like the IPsec VPN container(port mapping), it can receive the udp data from client netcat, too.
I cannot use L2TP client to connect the IPsec server.

To Reproduce
Create a docker container and check its listen address.

Expected behavior
I expect the listening address of docker container is 0.0.0.0 but not 172.17.0.2.

Logs
Enable logs, check VPN status, and add error logs to help explain the problem, if applicable.

Server (please complete the following information)

Docker host OS: Debian 10
Hosting provider (if applicable): Private enterprise.

Client (please complete the following information)

Device: PC
OS: Windows 10
VPN mode: IPsec/L2TP

Additional context
Nothing.

Originally created by @carbon-lab on GitHub (Dec 10, 2022). Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/331 **Checklist** - [Y] I read the [README](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md) - [Y] I read the [Important notes](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#important-notes) - [Y] I followed instructions to [configure VPN clients](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#next-steps) - [Y] I checked [Troubleshooting](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#troubleshooting), [IKEv2 troubleshooting](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/ikev2-howto.md#troubleshooting), [enabled logs](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/docs/advanced-usage.md#enable-libreswan-logs) and checked [VPN status](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#check-logs-and-vpn-status) - [Y] I searched existing [Issues](https://github.com/hwdsl2/docker-ipsec-vpn-server/issues?q=is%3Aissue) - [Y] This bug is about the IPsec VPN server Docker image, and not IPsec VPN itself  **Describe the issue** The processes in docker are listening IP address `172.17.0.2` but not `0.0.0.0`. So they cannot receive the udp data come from client whose target address is a public IP address but not `172.17.0.2`. ![image1](https://user-images.githubusercontent.com/35414199/206836623-2cd11ae2-fb01-4ea1-8d6f-6d9a37893a21.png) I have tried to use netcat tool to test my network. This is the result: 1. The server host can receive the udp data (port 500 and 4500) from client netcat. 2. If I create a docker container with debian image whose configuration like the IPsec VPN container(port mapping), it can receive the udp data from client netcat, too. 3. I cannot use L2TP client to connect the IPsec server. **To Reproduce** Create a docker container and check its listen address. **Expected behavior** I expect the listening address of docker container is `0.0.0.0` but not `172.17.0.2`. **Logs** [Enable logs](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/docs/advanced-usage.md#enable-libreswan-logs), check [VPN status](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#check-logs-and-vpn-status), and add error logs to help explain the problem, if applicable. **Server (please complete the following information)** - Docker host OS: Debian 10 - Hosting provider (if applicable): Private enterprise. **Client (please complete the following information)** - Device: PC - OS: Windows 10 - VPN mode: IPsec/L2TP **Additional context** Nothing.

kerem closed this issue

2026-03-02 08:01:15 +03:00

kerem commented

2026-03-02 08:01:16 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Dec 10, 2022):

@carbon-lab Hello! The IPsec VPN (Libreswan) is listening on the Docker container's internal IP address (172.17.0.2 in your case), which is normal. The Docker host should have IPTables rules in place (created automatically by Docker) that are responsible for forwarding the incoming UDP 500 and 4500 traffic to the Docker container.

For example, on the Docker host, you might see:

# sudo iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  udp  --  *      *       172.17.0.2           172.17.0.2           udp dpt:4500
    0     0 MASQUERADE  udp  --  *      *       172.17.0.2           172.17.0.2           udp dpt:500

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0
    0     0 DNAT       udp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:4500 to:172.17.0.2:4500
    0     0 DNAT       udp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:500 to:172.17.0.2:500

If these rules are missing, there may be an issue with your Docker installation. On the other hand, if the rules are there, try enabling Libreswan logs in the container:
https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/docs/advanced-usage.md#enable-libreswan-logs

Then re-connect the client and check the logs. If no new logs appear, then the connection attempt most likely did not reach the Docker container.

@hwdsl2 commented on GitHub (Dec 10, 2022): @carbon-lab Hello! The IPsec VPN (Libreswan) is listening on the Docker container's internal IP address (`172.17.0.2` in your case), which is normal. The Docker host should have IPTables rules in place (created automatically by Docker) that are responsible for forwarding the incoming UDP 500 and 4500 traffic to the Docker container. For example, on the Docker host, you might see: ``` # sudo iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0 0 0 MASQUERADE udp -- * * 172.17.0.2 172.17.0.2 udp dpt:4500 0 0 MASQUERADE udp -- * * 172.17.0.2 172.17.0.2 udp dpt:500 Chain DOCKER (2 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT udp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 to:172.17.0.2:4500 0 0 DNAT udp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500 to:172.17.0.2:500 ``` If these rules are missing, there may be an issue with your Docker installation. On the other hand, if the rules are there, try enabling Libreswan logs in the container: https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/docs/advanced-usage.md#enable-libreswan-logs Then re-connect the client and check the logs. If no new logs appear, then the connection attempt most likely did not reach the Docker container.

kerem commented

2026-03-02 08:01:16 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Dec 10, 2022):

@carbon-lab Please try the suggestions above. If you have additional information feel free to reply here.

@hwdsl2 commented on GitHub (Dec 10, 2022): @carbon-lab Please try the suggestions above. If you have additional information feel free to reply here.

kerem commented

2026-03-02 08:01:16 +03:00

Author

Owner

@carbon-lab commented on GitHub (Dec 16, 2022):

I have tried to enable the Libreswan logs in the container. But when I tried to check the log file /var/log/auth.log after I tried connect to my container, I cannot find that file. And I still cannot connect to my server.
By the way, I can use netcat to send and receive data from my docker host on port 500 and 4500 by UDP.

@carbon-lab commented on GitHub (Dec 16, 2022): I have tried to enable the Libreswan logs in the container. But when I tried to check the log file `/var/log/auth.log` after I tried connect to my container, I cannot find that file. And I still cannot connect to my server. By the way, I can use netcat to send and receive data from my docker host on port 500 and 4500 by UDP.

Rows
Columns

[GH-ISSUE #331] Cannot connect to server because of listening address problem #306