Score:0

Openvpn from Debian 10 to 11, stop to routing all my packets

pe flag

I had upgraded to Debian 11 from 10. With Debian 10 openvpn works fine, now I had this problem, i can reach my vpn server, but I cannot ping or access my lan remote, except for vpn server. This is the firewall configuration on remote side

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             multiport dports 2991
ACCEPT     udp  --  anywhere             anywhere             multiport dports 2991
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http-alt
ACCEPT     tcp  --  192.168.0.0/24       anywhere             tcp dpt:cisco-sccp
ACCEPT     tcp  --  192.168.0.0/24       anywhere             tcp dpt:2004
ACCEPT     tcp  --  192.168.0.0/24       anywhere             tcp dpt:3000
ACCEPT     tcp  --  192.168.0.0/24       anywhere             tcp dpt:37890
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:2124
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5861
ACCEPT     tcp  --  192.168.0.0/24       anywhere             tcp dpt:telnet
ACCEPT     tcp  --  anywhere             anywhere             tcp dpts:5900:5910
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere            
LOGGING    all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
NFLOG      all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request

Chain LOGGING (1 references)
target     prot opt source               destination         
NFLOG      all  --  anywhere             anywhere             nflog-prefix  "[iptables-drop]:" nflog-group 11
DROP       all  --  anywhere             anywhere            
root@vpn:/etc/openvpn# 

This is the configuration on remote side of Openvpn

port 2991
proto tcp
dev tun
ca /etc/openvpn/certs/keys/ca.crt
cert /etc/openvpn/certs/keys/vpn.******.priv.crt
key /etc/openvpn/certs/keys/vpn.******.priv.key
dh /etc/openvpn/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
push "route 192.168.0.0 255.255.255.0"
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/certs/keys/ta.key 0
data-ciphers-fallback AES-256-CBC
user openvpn
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 7
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
auth-nocache

This is the configuration of openvpn in client side(the firewall is identical of remote so I avoid to post)

client
dev tun
proto tcp
remote ****** 2991
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
cert /etc/openvpn/certs/keys/vpn.******.priv.crt
key /etc/openvpn/certs/keys/vpn.******.priv.key
dh /etc/openvpn/dh2048.pem
remote-cert-tls server
tls-auth /etc/openvpn/certs/ta.key 1
data-ciphers-fallback AES-256-CBC
auth SHA512
auth-nocache
topology subnet
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
verb 7

The only error i found on server is this..

ago 21 00:56:23 vpn ovpn-server[3791]: ******/*****:24545 GET INST BY VIRT: 192.168.0.12 [failed]

192.168.0.12 is the openvpn server ip, and I can reach it, but every ip in lan 192.168.0.02/24 is blocked(no ping, no ssh, nothing).

for example..

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
^C
--- 192.168.0.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5133ms

$ ping 192.168.0.12
PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=166 ms
64 bytes from 192.168.0.12: icmp_seq=2 ttl=64 time=164 ms
64 bytes from 192.168.0.12: icmp_seq=3 ttl=64 time=84.9 ms
^C
--- 192.168.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 84.924/138.389/166.113/37.814 ms
Score:1
pe flag

Solution found. On Debian 11 they had a bad(imho) idea to rename the classical eth0 to a long name of 16 char! This make impossible the use of interface in iptables or bridgge-utils(the maximum network interface lenght allowed is 15) otherwise will get this error "interface name is longer than 15 characters" So my nat goes to a non existent device(the eth0 disappeared). But fortunately there is an easy solution:

vim /etc/udev/rules.d/70-persistent-net.rules

#/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="YO:UR:MA:CA:DD:RES", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Of course replace "YO:UR:MA:CA:DD:RES"

After a reboot, i see the old good eth0 name and all return to work

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.