AlzGamer_KR's picture

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.

Forum: 
Jeremy Davis's picture

TBH, 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

Wojciech's picture

I'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.

 

 

Jeremy Davis's picture

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.

apt purge --autoremove -y acpid jitterentropy-rng

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...

deutrino's picture

You 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.

Wojciech's picture

On 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

 

Wojciech's picture

Jeremy 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.

 

 

Add new comment