starred/docker-ipsec-vpn-server

Fork 0

mirror of https://github.com/hwdsl2/docker-ipsec-vpn-server.git synced 2026-04-26 10:05:48 +03:00

[GH-ISSUE #126] Yet another "cannot connect to the server" #113

New issue

Closed

opened 2026-03-02 07:27:50 +03:00 by kerem · 5 comments

kerem commented

2026-03-02 07:27:50 +03:00

Owner

Originally created by @smoebody on GitHub (Feb 27, 2019).
Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/126

Hi. thanks for your effort to build this image. Very much appreciated.

However i struggle making it work though. I followed your documentation on creating the server. The output is


Retrieving VPN credentials...

Trying to auto discover IP of this server...

================================================

IPsec VPN server is now ready for use!

Connect to your new VPN with these details:

Server IP: xx.xx.xx.xx
IPsec PSK: presharedPassword
Username: username
Password: userPassword

Write these down. You'll need them to connect!

Important notes:   https://git.io/vpnnotes2
Setup VPN clients: https://git.io/vpnclients

================================================

Redirecting to: /etc/init.d/ipsec start
Starting pluto IKE daemon for IPsec: .
xl2tpd[1]: Not looking for kernel SAref support.
xl2tpd[1]: Using l2tp kernel support.
xl2tpd[1]: xl2tpd version xl2tpd-1.3.12 started on 52029f3e866d PID:1
xl2tpd[1]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[1]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[1]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[1]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[1]: Listening on IP address 0.0.0.0, port 1701

I configured port-forwarding for UDP ports 500 and 4500, even 1701 although you didn't mentioned it.

I setup the client with ipsec IKEv1/xauth and L2TP on Linux and Android.

I tried connectivity from linux to server with netcat (nc -u -l 500 / nc -u 500) and it worked

I am out of ideas. There seems to be nothing logged in the container. I followed your instructions to install rsyslogd and it logs pluto-logs - but nothing else comes when i try to connect.

My Docker-host is Ubuntu 18.04

Originally created by @smoebody on GitHub (Feb 27, 2019). Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/126 Hi. thanks for your effort to build this image. Very much appreciated. However i struggle making it work though. I followed your documentation on creating the server. The output is ``` Retrieving VPN credentials... Trying to auto discover IP of this server... ================================================ IPsec VPN server is now ready for use! Connect to your new VPN with these details: Server IP: xx.xx.xx.xx IPsec PSK: presharedPassword Username: username Password: userPassword Write these down. You'll need them to connect! Important notes: https://git.io/vpnnotes2 Setup VPN clients: https://git.io/vpnclients ================================================ Redirecting to: /etc/init.d/ipsec start Starting pluto IKE daemon for IPsec: . xl2tpd[1]: Not looking for kernel SAref support. xl2tpd[1]: Using l2tp kernel support. xl2tpd[1]: xl2tpd version xl2tpd-1.3.12 started on 52029f3e866d PID:1 xl2tpd[1]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc. xl2tpd[1]: Forked by Scott Balmos and David Stipp, (C) 2001 xl2tpd[1]: Inherited by Jeff McAdams, (C) 2002 xl2tpd[1]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016 xl2tpd[1]: Listening on IP address 0.0.0.0, port 1701 ``` I configured port-forwarding for UDP ports 500 and 4500, even 1701 although you didn't mentioned it. I setup the client with ipsec IKEv1/xauth and L2TP on Linux and Android. I tried connectivity from linux to server with netcat (nc -u -l 500 / nc -u <server-port> 500) and it worked I am out of ideas. There seems to be nothing logged in the container. I followed your instructions to install rsyslogd and it logs pluto-logs - but nothing else comes when i try to connect. My Docker-host is Ubuntu 18.04

kerem closed this issue

2026-03-02 07:27:51 +03:00

kerem commented

2026-03-02 07:27:51 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Feb 27, 2019):

@smoebody Hello! There is no need to open UDP port 1701. If you followed the instructions to enable Libreswan logs in the README, and there is no new log after connecting your VPN client(s), then traffic did not reach your VPN server.

Are you using a Raspberry Pi? If so, it is recommended to reserve a static IP for it in your router’s DHCP configuration, so that it does not change on reboot. Some ISPs use carrier-grade NAT for which it is not possible to connect to your IP from the Internet (hence this use case does not work).

Let us know if you are able to troubleshoot further.

@hwdsl2 commented on GitHub (Feb 27, 2019): @smoebody Hello! There is no need to open UDP port 1701. If you followed the instructions to enable Libreswan logs in the README, and there is no new log after connecting your VPN client(s), then traffic did not reach your VPN server. Are you using a Raspberry Pi? If so, it is recommended to reserve a static IP for it in your router’s DHCP configuration, so that it does not change on reboot. Some ISPs use carrier-grade NAT for which it is not possible to connect to your IP from the Internet (hence this use case does not work). Let us know if you are able to troubleshoot further.

kerem commented

2026-03-02 07:27:51 +03:00

Author

Owner

@smoebody commented on GitHub (Feb 28, 2019):

@hwdsl2 no I have a docker-host with several containers providing nextcloud, blogs, dnsmasq, ... stuff like this. It has a static IP and all other portforwardings are working. could it be a client-problem?
I use fedora 29. Do you know any commandline tool suitable for testing connection to a server?

@smoebody commented on GitHub (Feb 28, 2019): @hwdsl2 no I have a docker-host with several containers providing nextcloud, blogs, dnsmasq, ... stuff like this. It has a static IP and all other portforwardings are working. could it be a client-problem? I use fedora 29. Do you know any commandline tool suitable for testing connection to a server?

kerem commented

2026-03-02 07:27:51 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Feb 28, 2019):

@smoebody For the VPN you may test connection to your server’s UDP port 500, using nc perhaps.

@hwdsl2 commented on GitHub (Feb 28, 2019): @smoebody For the VPN you may test connection to your server’s UDP port 500, using `nc` perhaps.

kerem commented

2026-03-02 07:27:51 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Mar 2, 2019):

@smoebody I tested using Docker on Ubuntu 18.04/16.04 and the VPN works just fine. I think it is a client problem rather than an issue with the VPN server. Fedora Linux is known to have some bugs related to network manager and l2tp (search the web for more info). You may use VPN clients on other OS to test the server if needed. Some additional troubleshooting info can be found in [1].

[1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#troubleshooting

@hwdsl2 commented on GitHub (Mar 2, 2019): @smoebody I tested using Docker on Ubuntu 18.04/16.04 and the VPN works just fine. I think it is a client problem rather than an issue with the VPN server. Fedora Linux is known to have some bugs related to network manager and l2tp (search the web for more info). You may use VPN clients on other OS to test the server if needed. Some additional troubleshooting info can be found in [1]. [1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#troubleshooting

kerem commented

2026-03-02 07:27:52 +03:00

Author

Owner

@smoebody commented on GitHub (Mar 4, 2019):

Just to clarify, what was the problem:
in my /etc/hosts on the client was a line

127.0.0.1       localhost.localdomain localhost test.localhost

this leaded to an error in libunbound:

libunbound[19476:0] error: local-data in redirect zone must reside at top of zone, not at test.localhost A 127.0.0.1

I changed the /etc/hosts-line to

127.0.0.1       localhost.localdomain localhost test.localdomain

and it worked.

The test.localhost entry was made by myself for proper name-resolution on a test-project.

@smoebody commented on GitHub (Mar 4, 2019): Just to clarify, what was the problem: in my `/etc/hosts` on the client was a line ``` 127.0.0.1 localhost.localdomain localhost test.localhost ``` this leaded to an error in libunbound: ``` libunbound[19476:0] error: local-data in redirect zone must reside at top of zone, not at test.localhost A 127.0.0.1 ``` I changed the `/etc/hosts`-line to ``` 127.0.0.1 localhost.localdomain localhost test.localdomain ``` and it worked. The `test.localhost` entry was made by myself for proper name-resolution on a test-project.

No labels

bug

pull-request

question

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/docker-ipsec-vpn-server#113

No description provided.

Rows
Columns