OpenVPN on MrVM LES nat VPS : no forwarding

tonytony
in Technical

Hello,

I installed OpenVPN using https://github.com/angristan/openvpn-install and it seems to work ok as I am able to establish a connection, ping the VPS and even ssh into it using the VPN private ip. The problem is that the client does not have full Internet access. Ping to 8.8.8.8 does not succeed, using tcpdump I see the ICMP packets arriving on the VPS but I guess they are not correctly forwarded.

I tried every iptables rule I could find here and there, either MASQUERADE or SNAT but with no success (iptables is not complaining but it does not work). net.ipv4.ip_forward is obviously set to 1.

I am clueless, if anyone has an idea I would be really grateful.

OpenVPN client log :

sudo openvpn --config tony.ovpn 
Sun May  3 23:10:47 2020 Unrecognized option or missing or extra parameter(s) in tony.ovpn:19: block-outside-dns (2.4.7)
Sun May  3 23:10:47 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  5 2019
Sun May  3 23:10:47 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Sun May  3 23:10:47 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun May  3 23:10:47 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun May  3 23:10:47 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun May  3 23:10:47 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun May  3 23:10:47 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]213.239.XXX.YYY:19001
Sun May  3 23:10:47 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun May  3 23:10:47 2020 UDP link local: (not bound)
Sun May  3 23:10:47 2020 UDP link remote: [AF_INET]213.239.XXX.YYY:19001
Sun May  3 23:10:47 2020 TLS: Initial packet from [AF_INET]213.239.XXX.YYY:19001, sid=8bc6ec6a f365ad3c
Sun May  3 23:10:47 2020 VERIFY OK: depth=1, CN=cn_x07KORhkeMrqJgrY
Sun May  3 23:10:47 2020 VERIFY KU OK
Sun May  3 23:10:47 2020 Validating certificate extended key usage
Sun May  3 23:10:47 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun May  3 23:10:47 2020 VERIFY EKU OK
Sun May  3 23:10:47 2020 VERIFY X509NAME OK: CN=server_NoElFKC3RsPyQtKK
Sun May  3 23:10:47 2020 VERIFY OK: depth=0, CN=server_NoElFKC3RsPyQtKK
Sun May  3 23:10:47 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Sun May  3 23:10:47 2020 [server_NoElFKC3RsPyQtKK] Peer Connection Initiated with [AF_INET]213.239.XXX.YYY:19001
Sun May  3 23:10:48 2020 SENT CONTROL [server_NoElFKC3RsPyQtKK]: 'PUSH_REQUEST' (status=1)
Sun May  3 23:10:48 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 1.0.0.1,dhcp-option DNS 1.1.1.1,redirect-gateway def1 bypass-dhcp,tun-ipv6,route-ipv6 2000::/3,redirect-gateway ipv6,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fd42:42:42:42::1000/112 fd42:42:42:42::1,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-128-GCM'
Sun May  3 23:10:48 2020 OPTIONS IMPORT: timers and/or timeouts modified
Sun May  3 23:10:48 2020 OPTIONS IMPORT: --ifconfig/up options modified
Sun May  3 23:10:48 2020 OPTIONS IMPORT: route options modified
Sun May  3 23:10:48 2020 OPTIONS IMPORT: route-related options modified
Sun May  3 23:10:48 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun May  3 23:10:48 2020 OPTIONS IMPORT: peer-id set
Sun May  3 23:10:48 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Sun May  3 23:10:48 2020 OPTIONS IMPORT: data channel crypto options modified
Sun May  3 23:10:48 2020 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun May  3 23:10:48 2020 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun May  3 23:10:48 2020 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlp2s0 HWADDR=98:5f:d3:d2:d3:49
Sun May  3 23:10:48 2020 GDG6: remote_host_ipv6=n/a
Sun May  3 23:10:48 2020 ROUTE6_GATEWAY fe80::8e97:eaff:fe02:c542 IFACE=wlp2s0
Sun May  3 23:10:48 2020 TUN/TAP device tun0 opened
Sun May  3 23:10:48 2020 TUN/TAP TX queue length set to 100
Sun May  3 23:10:48 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun May  3 23:10:48 2020 /sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
Sun May  3 23:10:48 2020 /sbin/ip -6 addr add fd42:42:42:42::1000/112 dev tun0
Sun May  3 23:10:48 2020 /sbin/ip route add 213.239.XXX.YYY/32 via 192.168.1.1
Sun May  3 23:10:48 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Sun May  3 23:10:48 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Sun May  3 23:10:48 2020 add_route_ipv6(2000::/3 -> fd42:42:42:42::1 metric -1) dev tun0
Sun May  3 23:10:48 2020 /sbin/ip -6 route add 2000::/3 dev tun0
Sun May  3 23:10:48 2020 add_route_ipv6(::/3 -> fd42:42:42:42::1 metric -1) dev tun0
Sun May  3 23:10:48 2020 /sbin/ip -6 route add ::/3 dev tun0
Sun May  3 23:10:48 2020 add_route_ipv6(2000::/4 -> fd42:42:42:42::1 metric -1) dev tun0
Sun May  3 23:10:48 2020 /sbin/ip -6 route add 2000::/4 dev tun0
Sun May  3 23:10:48 2020 add_route_ipv6(3000::/4 -> fd42:42:42:42::1 metric -1) dev tun0
Sun May  3 23:10:48 2020 /sbin/ip -6 route add 3000::/4 dev tun0
Sun May  3 23:10:48 2020 add_route_ipv6(fc00::/7 -> fd42:42:42:42::1 metric -1) dev tun0
Sun May  3 23:10:48 2020 /sbin/ip -6 route add fc00::/7 dev tun0
Sun May  3 23:10:48 2020 Initialization Sequence Completed

Comments

  • schnafischnafi OG

    Well, with this little information we can't help much. The client conf looks ok as
    Sun May 3 23:10:48 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
    Sun May 3 23:10:48 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
    shows that the correct route is routes are added. Have you got ufw / any other firewall installed? How about anything in /etc/iptables/rules.v4?

  • flipsflips OG

    Maybe try the original script by @Nyr ?
    https://github.com/Nyr/openvpn-install

    Thanked by (4)skorous Ympker Nyr mikho
  • tonytony

    The OS is Debian 10.3, I think the only firewall is iptables and here is the content of /etc/iptables/add-openvpn-rules.sh :

    #!/bin/sh
iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -o venet0 -j MASQUERADE
iptables -I INPUT 1 -i tun0 -j ACCEPT
iptables -I FORWARD 1 -i venet0 -o tun0 -j ACCEPT
iptables -I FORWARD 1 -i tun0 -o venet0 -j ACCEPT
iptables -I INPUT 1 -i venet0 -p udp --dport 19001 -j ACCEPT
ip6tables -t nat -I POSTROUTING 1 -s fd42:42:42:42::/112 -o venet0 -j MASQUERADE
ip6tables -I INPUT 1 -i tun0 -j ACCEPT
ip6tables -I FORWARD 1 -i venet0 -o tun0 -j ACCEPT
ip6tables -I FORWARD 1 -i tun0 -o venet0 -j ACCEPT
ip6tables -I INPUT 1 -i venet0 -p udp --dport 19001 -j ACCEPT

    There is also /etc/iptables/rm-openvpn-rules.sh but no other script in this directory

  • YmpkerYmpker OGContent Writer
    edited May 2020

    I don't by what this was caused back then, however when I had a NAT VPS from @mikho I remember that angristans script for ovpn also did not work, however @Nyr script worked. Try @Nyr script :)

    Thanked by (2)Abdullah mikho

    Ympker's Shared/Reseller Hosting Comparison Chart, Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.

  • tonytony

    On the client side these are the routes before connecting to the VPN :

    default via 10.10.125.1 dev eth0
10.10.125.0/24 dev eth0 proto kernel scope link src 10.10.125.155

    And here are the routes after connecting to the VPN :

    0.0.0.0/1 via 10.8.0.1 dev tun0
default via 10.10.125.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
10.10.125.0/24 dev eth0 proto kernel scope link src 10.10.125.155
128.0.0.0/1 via 10.8.0.1 dev tun0
213.239.213.138 via 10.10.125.1 dev eth0
  • tonytony

    @Ympker said:
    I don't by what this was caused back then, however when I had a NAT VPS from @mikho I remember that angristans script for ovpn also did not work, however @Nyr script worked. Try @Nyr script :)

    I will try today but as the VPN connection does not look to be the issue it is really frustrating.

    Thanked by (1)Ympker
  • NyrNyr OG

    @tony said: I will try today but as the VPN connection does not look to be the issue it is really frustrating.

    Try my installer, preferably in a clean server. It does both IP detection and the NAT in a better way, so that could be enough. It 100% works in LES.

    It you are still having issues, we can troubleshoot from there, but the installer works on LES and you don't need to add any routing rule manually, just use the installer and specify the public IP when asked. Nothing more.

    Thanked by (1)Ympker

    OpenVPN installer | WireGuard installer

  • berkayberkay OG

    Are you sure that the ip(6)tables rules are applied succesfully? On a fairly small number of my installations, the nat table requires the ip(6)tables-legacy instead of ip(6)tables and by the default PATH those executables couldn’t be found. Could you post the output of the ip(6)tables -L and ip(6)tables -t nat -L commands? Don’t forget to remove your IP addresses.

  • berkayberkay OG
    edited May 2020

    On a side note, I’d recommend @Nyr ’s script too. IMHO, having a systemd service for OpenVPN’s iptables rules make much more sense compared to a bash script, with the former at least you get some kind of observation chance about the application of the rules.

    Thanked by (2)Ympker mikho
  • tonytony
    edited May 2020

    Just made a clean reinstall and use Nyr script, still no luck :(

    Openvpn client log :

    # openvpn --config torrent.ovpn
Mon May  4 12:56:18 2020 Unrecognized option or missing or extra parameter(s) in torrent.ovpn:13: block-outside-dns (2.4.4)
Mon May  4 12:56:18 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Mon May  4 12:56:18 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
Mon May  4 12:56:18 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May  4 12:56:18 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon May  4 12:56:18 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May  4 12:56:18 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon May  4 12:56:18 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]213.239.XXX.YYY:19001
Mon May  4 12:56:18 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon May  4 12:56:18 2020 UDP link local: (not bound)
Mon May  4 12:56:18 2020 UDP link remote: [AF_INET]213.239.XXX.YYY:19001
Mon May  4 12:56:18 2020 TLS: Initial packet from [AF_INET]213.239.XXX.YYY:19001, sid=8201e616 b76b8651
Mon May  4 12:56:18 2020 VERIFY OK: depth=1, CN=ChangeMe
Mon May  4 12:56:18 2020 VERIFY KU OK
Mon May  4 12:56:18 2020 Validating certificate extended key usage
Mon May  4 12:56:18 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon May  4 12:56:18 2020 VERIFY EKU OK
Mon May  4 12:56:18 2020 VERIFY OK: depth=0, CN=server
Mon May  4 12:56:18 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Mon May  4 12:56:18 2020 [server] Peer Connection Initiated with [AF_INET]213.239.XXX.YYY:19001
Mon May  4 12:56:19 2020 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon May  4 12:56:19 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 ipv6 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 fddd:1194:1194:1194::1000/64 fddd:1194:1194:1194::1,ifconfig 10.8.0.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Mon May  4 12:56:19 2020 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Mon May  4 12:56:19 2020 OPTIONS IMPORT: timers and/or timeouts modified
Mon May  4 12:56:19 2020 OPTIONS IMPORT: --ifconfig/up options modified
Mon May  4 12:56:19 2020 OPTIONS IMPORT: route options modified
Mon May  4 12:56:19 2020 OPTIONS IMPORT: route-related options modified
Mon May  4 12:56:19 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon May  4 12:56:19 2020 OPTIONS IMPORT: peer-id set
Mon May  4 12:56:19 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Mon May  4 12:56:19 2020 OPTIONS IMPORT: data channel crypto options modified
Mon May  4 12:56:19 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon May  4 12:56:19 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon May  4 12:56:19 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon May  4 12:56:19 2020 ROUTE_GATEWAY 10.10.125.1/255.255.255.0 IFACE=eth0 HWADDR=00:16:3e:db:5c:65
Mon May  4 12:56:19 2020 GDG6: remote_host_ipv6=n/a
Mon May  4 12:56:19 2020 ROUTE6_GATEWAY fe80::c78:27ff:fe48:1a88 IFACE=eth0
Mon May  4 12:56:19 2020 TUN/TAP device tun0 opened
Mon May  4 12:56:19 2020 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)
Mon May  4 12:56:19 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon May  4 12:56:19 2020 /sbin/ip link set dev tun0 up mtu 1500
Mon May  4 12:56:19 2020 /sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
Mon May  4 12:56:19 2020 /sbin/ip -6 addr add fddd:1194:1194:1194::1000/64 dev tun0
Mon May  4 12:56:20 2020 /sbin/ip route add 213.239.XXX.YYY/32 via 10.10.125.1
Mon May  4 12:56:20 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Mon May  4 12:56:20 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Mon May  4 12:56:20 2020 add_route_ipv6(::/3 -> fddd:1194:1194:1194::1 metric -1) dev tun0
Mon May  4 12:56:20 2020 /sbin/ip -6 route add ::/3 dev tun0
Mon May  4 12:56:20 2020 add_route_ipv6(2000::/4 -> fddd:1194:1194:1194::1 metric -1) dev tun0
Mon May  4 12:56:20 2020 /sbin/ip -6 route add 2000::/4 dev tun0
Mon May  4 12:56:20 2020 add_route_ipv6(3000::/4 -> fddd:1194:1194:1194::1 metric -1) dev tun0
Mon May  4 12:56:20 2020 /sbin/ip -6 route add 3000::/4 dev tun0
Mon May  4 12:56:20 2020 add_route_ipv6(fc00::/7 -> fddd:1194:1194:1194::1 metric -1) dev tun0
Mon May  4 12:56:20 2020 /sbin/ip -6 route add fc00::/7 dev tun0
Mon May  4 12:56:20 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon May  4 12:56:20 2020 Initialization Sequence Completed

    iptables -t nat -L

    Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  10.8.0.0/24         !10.8.0.0/24          to:172.16.1.190

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
# Warning: iptables-legacy tables present, use iptables-legacy to see them

    iptables -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:19001

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  10.8.0.0/24          anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
# Warning: iptables-legacy tables present, use iptables-legacy to see them

    Edit :
    ip6tables -L -t nat

    Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all      fddd:1194:1194:1194::/64 !fddd:1194:1194:1194::/64  to:2a01:4f8:a0:xxxx:yyyy::1

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
# Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them

    ip6tables -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all      anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all      fddd:1194:1194:1194::/64  anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
# Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them
  • mikhomikho AdministratorHosting ProviderOG

    @berkay said:
    Are you sure that the ip(6)tables rules are applied succesfully? On a fairly small number of my installations, the nat table requires the ip(6)tables-legacy instead of ip(6)tables and by the default PATH those executables couldn’t be found. Could you post the output of the ip(6)tables -L and ip(6)tables -t nat -L commands? Don’t forget to remove your IP addresses.

    @tony said: # Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them

    I've seen issues with connectivity on VPS and IP(6)tables-legacy this before.
    I would follow @berkay and check what's wrong with the settings.

    https://clients.mrvm.net

  • berkayberkay OG

    How does the output of systemctl status openvpn-iptables.service look like?

  • tonytony
    edited May 2020

    @berkay said:
    How does the output of systemctl status openvpn-iptables.service look like?

    sounds good :

    openvpn-iptables.service
   Loaded: loaded (/etc/systemd/system/openvpn-iptables.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2020-05-04 15:11:24 BST; 48min ago
  Process: 135 ExecStart=/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to 172.16.1.190 (code=exited, status=0/SUCCESS)
  Process: 146 ExecStart=/usr/sbin/iptables -I INPUT -p udp --dport 19001 -j ACCEPT (code=exited, status=0/SUCCESS)
  Process: 147 ExecStart=/usr/sbin/iptables -I FORWARD -s 10.8.0.0/24 -j ACCEPT (code=exited, status=0/SUCCESS)
  Process: 148 ExecStart=/usr/sbin/iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT (code=exited, status=0/SUCCESS)
  Process: 151 ExecStart=/sbin/ip6tables -t nat -A POSTROUTING -s fddd:1194:1194:1194::/64 ! -d fddd:1194:1194:1194::/64 -j SNAT --to 2a01:4f8:a0:xxxx:yyyy::1 (code=exited, status=0/SUCCESS)
  Process: 160 ExecStart=/usr/sbin/ip6tables -I FORWARD -s fddd:1194:1194:1194::/64 -j ACCEPT (code=exited, status=0/SUCCESS)
  Process: 169 ExecStart=/usr/sbin/ip6tables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT (code=exited, status=0/SUCCESS)
 Main PID: 169 (code=exited, status=0/SUCCESS)

May 04 15:11:23 vpn.tld systemd[1]: Starting openvpn-iptables.service...
May 04 15:11:24 vpn.tld systemd[1]: Started openvpn-iptables.service.
  • tonytony

    @mikho said:

    @berkay said:
    Are you sure that the ip(6)tables rules are applied succesfully? On a fairly small number of my installations, the nat table requires the ip(6)tables-legacy instead of ip(6)tables and by the default PATH those executables couldn’t be found. Could you post the output of the ip(6)tables -L and ip(6)tables -t nat -L commands? Don’t forget to remove your IP addresses.

    @tony said: # Warning: ip6tables-legacy tables present, use ip6tables-legacy to see them

    I've seen issues with connectivity on VPS and IP(6)tables-legacy this before.
    I would follow @berkay and check what's wrong with the settings.

    The output of ip6tables (see above) makes me pretty confident that they are applied.

  • berkayberkay OG

    Well, they really look okay; I'm kind of clueless now. Did you check ip(6)tables-legacy tables too, as the output points out that they do have tables too?

  • tonytony

    @berkay said:
    Well, they really look okay; I'm kind of clueless now. Did you check ip(6)tables-legacy tables too, as the output points out that they do have tables too?

    All legacy tables look empy :

    iptables-legacy -t nat -L

    Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

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

    iptables-legacy -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

    ip6tables-legacy -t nat -L

    Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

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

    ip6tables-legacy -L

    Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
  • berkayberkay OG

    I would try adding the same rules with ip(6)tables-legacy too, you can find them on /etc/systemd/system/openvpn-iptables.service.

    Thanked by (1)tony
  • mikhomikho AdministratorHosting ProviderOG

    Not sure if this will help:
    https://wiki.debian.org/nftables

    reverting back to iptables instead of nftables.

    Thanked by (1)tony

    https://clients.mrvm.net

  • InceptionHostingInceptionHosting Hosting ProviderOG 
    apt install iptables
update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

    If that fails, please try using a different distro (just as an environment test) such as CentOS.

    Thanked by (1)tony

    https://inceptionhosting.com
    Please do not use the PM system here for Inception Hosting support issues.

  • tonytony

    @AnthonySmith said:
    apt install iptables
    update-alternatives --set iptables /usr/sbin/iptables-legacy
    update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

    If that fails, please try using a different distro (just as an environment test) such as CentOS.

    This is what I wanted to test, I will test this this evening.

  • tonytony
    edited May 2020

    @AnthonySmith said:
    apt install iptables
    update-alternatives --set iptables /usr/sbin/iptables-legacy
    update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

    OMG that was the problem since the beginning :astonished: it finally works. Thank you all folks for the valuable help !

    There is probably an incompatibility between container iptables implementation and the host kernel version or something like that. Again, thanks a lot !

    Thanked by (1)InceptionHosting
  • mikhomikho AdministratorHosting ProviderOG

    @tony said:

    @AnthonySmith said:
    apt install iptables
    update-alternatives --set iptables /usr/sbin/iptables-legacy
    update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

    OMG that was the problem since the beginning :astonished: it finally works. Thank you all folks for the valuable help !

    There is probably an incompatibility between container iptables implementation and the host kernel version or something like that. Again, thanks a lot !

    Debian breaks it with nftables
    Centos or RHEL on the node doesn’t know how to handle it properly.

    https://clients.mrvm.net

  • NyrNyr OG

    Thanks everyone for the information, I had no idea of the existence of this issue with OpenVZ.

    I'm going to order an OVZ from @mikho to see exactly what distros and configurations are having this issue and add a check in the script to address it.

    OpenVPN installer | WireGuard installer

  • InceptionHostingInceptionHosting Hosting ProviderOG
    edited May 2020

    @Nyr said: Thanks everyone for the information, I had no idea of the existence of this issue with OpenVZ.

    I'm going to order an OVZ from @mikho to see exactly what distros and configurations are having this issue and add a check in the script to address it.

    It is simply that the 3.x VZ kernel does not support nf_tables, while I did experiment early on when debian 10 was released to load the modules it caused significant instability.

    So you really need to add an if deb=10 then:

    apt install iptables
update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
    Thanked by (2)Nyr mikho

    https://inceptionhosting.com
    Please do not use the PM system here for Inception Hosting support issues.

  • NyrNyr OG

    @AnthonySmith said: It is simply that the 3.x VZ kernel does not support nf_tables, while I did experiment early on when debian 10 was released to load the modules it caused significant instability.

    I see, will commit it tomorrow. I'm surprised that this issue has persisted for so long without a report reaching me.

    OpenVPN installer | WireGuard installer

  • InceptionHostingInceptionHosting Hosting ProviderOG
    edited May 2020

    @Nyr said: I see, will commit it tomorrow. I'm surprised that this issue has persisted for so long without a report reaching me.

    To be honest for all I know the nf_tables issues has been resolved in a later vz7/virtuozzo kernel, as I was a fairly early adopter of VZ7 in the LE* world and the fixes soon got fairly well documented so maybe a lot of people have just found that.

    I don't fancy putting that theory to the test just for funzies though :)

    Maybe it is just that hosts have later kernel versions and no nf_tables issues and enabled it in advance or no one is using Debian 10 in containers or ... and I suspect this to be a big part of it, the majority of hosts still use VZ6 :)

    Since from what I can tell most hosts are using my VZ7 templates anyway, the virtualizor templates were ones that I made i believe so i guess I could just make a new one with that already taken care of.

    Thanked by (1)bdl

    https://inceptionhosting.com
    Please do not use the PM system here for Inception Hosting support issues.

  • NyrNyr OG

    Thanks for the detailed information, this has been addressed in the script.

    Thanked by (2)InceptionHosting mikho

    OpenVPN installer | WireGuard installer

  • InceptionHostingInceptionHosting Hosting ProviderOG

    @Nyr said:
    Thanks for the detailed information, this has been addressed in the script.

    The only think worth mentioning just for a correctness stand point is that "nf_tables is not available in old OpenVZ kernels" should probably read "nf_tables is not available as standard in current OpenVZ kernels" as there are not really any old ones not in production VZ6 is 6 months+ EOL now. and current VZ7 follows the el7 kernel version pretty closely.

    Thanked by (1)mikho

    https://inceptionhosting.com
    Please do not use the PM system here for Inception Hosting support issues.

  • NyrNyr OG

    @AnthonySmith said: The only think worth mentioning just for a correctness stand point is that "nf_tables is not available in old OpenVZ kernels" should probably read "nf_tables is not available as standard in current OpenVZ kernels" as there are not really any old ones not in production VZ6 is 6 months+ EOL now. and current VZ7 follows the el7 kernel version pretty closely.

    I see, I mixed things up with you talking about the issues in previous kernels.

    It's an important distinction as this means that it's possible that I'll need to keep addressing this with new distributions if they use iptables-nft by default.

    Thanked by (1)mikho

    OpenVPN installer | WireGuard installer

  • mikhomikho AdministratorHosting ProviderOG

    Great added value to the installation script @Nyr

    Easy and understandble explanation @AnthonySmith

    https://clients.mrvm.net

Sign In or Register to comment.

© LowEndSpirit 2024

ipv6 ready

This Site is currently in maintenance mode.
Please check back here later.

→ Site Settings