Forum archive
ProxMox OpenVPN cannot connect
First I would like to apologize for my English.
I have server with installed ProxMox 7.1-10 and maked CT from template debian-10-turnkey-openvpn_16.1-1_amd64.tar.gz. The server has 4 IP's, configured PREROUTING and POSTROUTING nat rules for translate network from vmbr0 to vmbr1 and reverse.
# pve (ip partially hidden, correct addresses are specified in the rules) root@pve:~# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT all -- anywhere 146.0.233.* to:172.16.49.101 DNAT all -- anywhere 146.0.233.* to:172.16.49.102 DNAT all -- anywhere 146.0.233.* to:172.16.49.103 DNAT all -- anywhere 146.0.233.* to:172.16.49.104 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 172.16.49.101 anywhere to:146.0.233.* SNAT all -- 172.16.49.102 anywhere to:146.0.233.* SNAT all -- 172.16.49.103 anywhere to:146.0.233.* SNAT all -- 172.16.49.104 anywhere to:146.0.233.*
In the course of trying, I disabled the firewall on the container
And don't set any rules by ProxMox, but container has a rules:
root@ovpn ~# iptables -L Chain INPUT (policy DROP) target prot opt source destination f2b-sshd tcp -- anywhere anywhere multiport dports ssh ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:12320 ACCEPT tcp -- anywhere anywhere tcp dpt:12321 ACCEPT udp -- anywhere anywhere udp dpt:openvpn Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-sshd (1 references) target prot opt source destination REJECT all -- 129.28.199.85 anywhere reject-with icmp-port-unreachable REJECT all -- 165.232.76.182 anywhere reject-with icmp-port-unreachable REJECT all -- 104.131.181.4 anywhere reject-with icmp-port-unreachable REJECT all -- 112.85.42.229 anywhere reject-with icmp-port-unreachable REJECT all -- 122.194.229.38 anywhere reject-with icmp-port-unreachable REJECT all -- 218.92.0.206 anywhere reject-with icmp-port-unreachable REJECT all -- 137.184.131.135 anywhere reject-with icmp-port-unreachable REJECT all -- 218.92.0.221 anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere
ssh connection is work, but cannot connect by openvpn client. https web page also working.
Thu Mar 03 22:19:30 2022 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. Thu Mar 03 22:19:30 2022 OpenVPN 2.5.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 24 2021 Thu Mar 03 22:19:30 2022 Windows version 10.0 (Windows 10 or greater) 64bit Thu Mar 03 22:19:30 2022 library versions: OpenSSL 1.1.1j 16 Feb 2021, LZO 2.10 Thu Mar 03 22:19:30 2022 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25342 Thu Mar 03 22:19:30 2022 Need hold release from management interface, waiting... Thu Mar 03 22:19:30 2022 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25342 Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'state on' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'log all on' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'echo all on' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'bytecount 5' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'hold off' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'hold release' Thu Mar 03 22:19:30 2022 MANAGEMENT: CMD 'password [...]' Thu Mar 03 22:19:30 2022 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Thu Mar 03 22:19:30 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:19:30 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:19:30 2022 MANAGEMENT: >STATE:1646338770,RESOLVE,,,,,, Thu Mar 03 22:19:30 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:19:30 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:19:30 2022 UDP link local: (not bound) Thu Mar 03 22:19:30 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:19:30 2022 MANAGEMENT: >STATE:1646338770,WAIT,,,,,, Thu Mar 03 22:20:31 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:20:31 2022 TLS Error: TLS handshake failed Thu Mar 03 22:20:31 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:20:31 2022 MANAGEMENT: >STATE:1646338831,RECONNECTING,tls-error,,,,, Thu Mar 03 22:20:31 2022 Restart pause, 5 second(s) Thu Mar 03 22:20:36 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:20:36 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:20:36 2022 MANAGEMENT: >STATE:1646338836,RESOLVE,,,,,, Thu Mar 03 22:20:36 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:20:36 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:20:36 2022 UDP link local: (not bound) Thu Mar 03 22:20:36 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:20:36 2022 MANAGEMENT: >STATE:1646338836,WAIT,,,,,, Thu Mar 03 22:21:36 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:21:36 2022 TLS Error: TLS handshake failed Thu Mar 03 22:21:36 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:21:36 2022 MANAGEMENT: >STATE:1646338896,RECONNECTING,tls-error,,,,, Thu Mar 03 22:21:36 2022 Restart pause, 5 second(s) Thu Mar 03 22:21:41 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:21:41 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:21:41 2022 MANAGEMENT: >STATE:1646338901,RESOLVE,,,,,, Thu Mar 03 22:21:41 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:21:41 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:21:41 2022 UDP link local: (not bound) Thu Mar 03 22:21:41 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:21:41 2022 MANAGEMENT: >STATE:1646338901,WAIT,,,,,, Thu Mar 03 22:22:41 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:22:41 2022 TLS Error: TLS handshake failed Thu Mar 03 22:22:41 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:22:41 2022 MANAGEMENT: >STATE:1646338961,RECONNECTING,tls-error,,,,, Thu Mar 03 22:22:41 2022 Restart pause, 5 second(s) Thu Mar 03 22:22:46 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:22:46 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:22:46 2022 MANAGEMENT: >STATE:1646338966,RESOLVE,,,,,, Thu Mar 03 22:22:46 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:22:46 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:22:46 2022 UDP link local: (not bound) Thu Mar 03 22:22:46 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:22:46 2022 MANAGEMENT: >STATE:1646338966,WAIT,,,,,, Thu Mar 03 22:23:46 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:23:46 2022 TLS Error: TLS handshake failed Thu Mar 03 22:23:46 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:23:46 2022 MANAGEMENT: >STATE:1646339026,RECONNECTING,tls-error,,,,, Thu Mar 03 22:23:46 2022 Restart pause, 5 second(s) Thu Mar 03 22:23:51 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:23:51 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:23:51 2022 MANAGEMENT: >STATE:1646339031,RESOLVE,,,,,, Thu Mar 03 22:23:51 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:23:51 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:23:51 2022 UDP link local: (not bound) Thu Mar 03 22:23:51 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:23:51 2022 MANAGEMENT: >STATE:1646339031,WAIT,,,,,, Thu Mar 03 22:24:51 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:24:51 2022 TLS Error: TLS handshake failed Thu Mar 03 22:24:51 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:24:51 2022 MANAGEMENT: >STATE:1646339091,RECONNECTING,tls-error,,,,, Thu Mar 03 22:24:51 2022 Restart pause, 10 second(s) Thu Mar 03 22:25:01 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:25:01 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:25:01 2022 MANAGEMENT: >STATE:1646339101,RESOLVE,,,,,, Thu Mar 03 22:25:01 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:25:01 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:25:01 2022 UDP link local: (not bound) Thu Mar 03 22:25:01 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:25:01 2022 MANAGEMENT: >STATE:1646339101,WAIT,,,,,, Thu Mar 03 22:26:02 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Mar 03 22:26:02 2022 TLS Error: TLS handshake failed Thu Mar 03 22:26:02 2022 SIGUSR1[soft,tls-error] received, process restarting Thu Mar 03 22:26:02 2022 MANAGEMENT: >STATE:1646339162,RECONNECTING,tls-error,,,,, Thu Mar 03 22:26:02 2022 Restart pause, 20 second(s) Thu Mar 03 22:26:22 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:26:22 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Thu Mar 03 22:26:22 2022 MANAGEMENT: >STATE:1646339182,RESOLVE,,,,,, Thu Mar 03 22:26:22 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:26:22 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Thu Mar 03 22:26:22 2022 UDP link local: (not bound) Thu Mar 03 22:26:22 2022 UDP link remote: [AF_INET]146.0.233.*:1194 Thu Mar 03 22:26:22 2022 MANAGEMENT: >STATE:1646339182,WAIT,,,,,,
Domain configured on the CloudFlare, on setup ovpn server was installed security updates and Let's Encrypt for domain.
Also, when active firewall output traffic is dropped, but in firewall it is ACCEPT
Help me please find a problem and if it possible fix it.
Thank you.
Replies (6)
Strange that it breaks on migration?
Reply 1LXC container works fine under Proxmox 6.4, and not in 7.2
Reply 2I've tested one LXC container with turnkey openVPN server on the proxmox cluster with two nodes.
PVE1 node with ProxMox 6.4 - everything works fine.
After migration LXC to PVE2 node with Proxmox ver. 7.2 LXC starts, but you can't connect to the server.
Don't do it in production ;-)
Migration back from 7.2 proxmox node to the 6.4 doesn't work, so you can move it only ones from 6.4 to 7.2 proxmox node.
My conclusion is that, LXC containers of Turnkey Linux they don't work stably with newest Proxmox 7Si is not good idea for production, only labs or home.
I've never launched with success Turnkey DomainController (I've written post about this) in LXE under Proxmox 7.2, and higher ver. of Turnkey than 15.
Have you created TUN device?
Reply 3TBH, I'm not completely sure. I'm no OpenVPN expert and I know that there have been some issues with running OpenVPN in a (unpriveledged) LXC container. But I suspect that it is related to running in an unprivileged container (see this issue).
So, I'll assuming that you are running an unprivileged container (which you should be). If you haven't already, then you need to configure the host to provide a TUN device. It may also be required to enable "nesting" on your container to get everything working (but I'm not 100% on that bit).
To configure TUN device in your container guest, you need to pass it through from the host. Assuming your guest container ID is 123, then you will find it's config file (on the PVE host) at '/etc/pve/lxc/123.conf'. Add these lines:
lxc.cgroup2.devices.allow: c 10:200 rwm lxc.mount.entry: /dev/net dev/net none bind,create=dir
Then on the host, ensure that the unprivileged guest root user can access the TUN device (UID 100000 on the host, maps to root within unprivileged containers):
chown 100000:100000 /dev/net/tun
I.e.:
root@pve ~# ls -l /dev/net/tun crw-rw-rw- 1 root root 10, 200 Feb 25 15:54 /dev/net/tun root@pve ~# chown 100000:100000 /dev/net/tun root@pve ~# ls -l /dev/net/tun crw-rw-rw- 1 100000 100000 10, 200 Feb 25 15:54 /dev/net/tun
Then within the container, double check that the TUN device exists and is owned by root (reboot may be required to enable the guest config changes):
root@openvpn ~# ls -l /dev/net/tun crw-rw-rw- 1 root root 10, 200 Feb 25 15:54 /dev/net/tun
Hopefully that gets you going...
Good luck
You might also just try doing
Reply 4You might also just try doing the same thing in a full VM and see if it works on there.
I started out trying to do a lot of stuff in LXC containers in Proxmox, but found that in many cases it led to problems, so now I just do VMs for most everything. The performance is a little less but with KSM sharing in Proxmox it doesn't use as much RAM as you might think, if a lot of your VMs are the same OS their RAM usage will be deduplicated.
debian-10-turnkey-openvpn_16.1-1 in LXE works only ProxMox 6.4
Reply 5On Proxmox 7.2 you can't connect to server.
LXc container was created on Proxmox 6.4 (and worked there), and migrated to Proxmox 7.4, than broken connect.
It's shows, that problem is in the host.
Sun May 08 21:49:32 2022 SIGUSR1[soft,tls-error] received, process restarting Sun May 08 21:49:32 2022 MANAGEMENT: >STATE:1652039372,RECONNECTING,tls-error,,,,, Sun May 08 21:49:32 2022 Restart pause, 300 second(s) Sun May 08 21:54:32 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun May 08 21:54:32 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun May 08 21:54:32 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.10.100:1194 Sun May 08 21:54:32 2022 Socket Buffers: R=[65536->65536] S=[65536->65536] Sun May 08 21:54:32 2022 UDP link local: (not bound) Sun May 08 21:54:32 2022 UDP link remote: [AF_INET]192.168.10.100:1194 Sun May 08 21:54:32 2022 MANAGEMENT: >STATE:1652039672,WAIT,,,,,, Sun May 08 21:55:32 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sun May 08 21:55:32 2022 TLS Error: TLS handshake failed
Solved debian-10-turnkey-openvpn_16.1-1 in LXE works on 7.2 prox
Reply 6Jeremy shown good solution yesterday.
On 7.2 Proxmox host you need to modify container file, and change on the host:
chown 100000:100000 /dev/net/tun
It's interesting that it is not needed on proxmox 6.4.
Lots of people use our v16.x (Debian Buster/10 based) LXC templates on PVE v7. So I know that they can work there. Although, some users have reported 100% CPU usage (only seems to affect some users though? - related to the 'jitterentorpy-rngd' package). So I wonder if that's the issue? Although the fact it doesn't work when back on v6 is weird? It makes me wonder if something was mangled in the migration from Proxmox v6 to v7?
To troubleshoot the issue, try entering the migrated (or broken) container. Ensure it's started and then enter it from the PVE host with 'pct enter VMID'. Have a poke around and see what is going on. My guess is that something is either soaking up CPU cycles (e.g. 'jitterentropy-rngd') or services have failed to start. Both should be fixable fairly easily.
FWIW, we hope to have v17.0 LXC builds soon. One thing we have discovered (and I noted above) though is that they benefit from the removal of a couple of packages. Jitterentropy as noted above, but also acpid.
Re your comment about Domain Controller, unfortunately, it's a know issue that Samba doesn't play nice in an unprivileged container by default. As you can see, I never managed to get it running on LXC in an unprivileged container either. IIRC v16.x doesn't work great as a privileged container either though. IIRC that is because in a quirk of systemd, the security hardening that Debian have done cause some services to fail to start.
As noted in the issue (linked above) the workaround is to just use a full VM (install from ISO - you can download it from the Domain Controller appliance page). If you'd like to explore running Domain Controller on LXC, then that issue thread is probably the best place. TBH, I was considering not building it for LXC for v17.0 - seeing as it's essentially broken, at least until we can document how to make it work. I have read elsewhere where others have had it running though, so it should be possible. I just haven't been able to spend enough time on it...