Posted: Sat Jul 23, 2022 14:55 Post subject: [SOLVED]Routeur can ping openvpn server but PC cant
Hi, after few hours didn't find any solutions on the forum to my problem.
I have an openvpn server on a remote address: 5.39.x.x
At home i have a router R7000 with dd-wrt which replace my ISP provider Box (bouygues telecom, france) with an openvpn client connection.
My router is connected to openvpn server with success.
With an SSH connection to the router i can ping my openvpn server:
Code:
PING 10.8.0.1 (10.8.0.1): 56 data bytes
64 bytes from 10.8.0.1: seq=0 ttl=64 time=8.452 ms
64 bytes from 10.8.0.1: seq=1 ttl=64 time=10.133 ms
64 bytes from 10.8.0.1: seq=2 ttl=64 time=7.147 ms
However on my PC which is directly connected to the router, a PING request to 10.8.0.1 fail
If i do a traceroute to 8.8.8.8 it works and goes through my router:
Code:
Détermination de l’itinéraire vers dns.google [8.8.8.8]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms DD-WRT [10.0.0.1]
2 1 ms 3 ms 3 ms 176-163-160-3.abo.bbox.fr [176.163.160.3]
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 2 ms 2 ms 2 ms 212.194.171.69
6 * * * Délai d’attente de la demande dépassé.
7 4 ms 3 ms 2 ms 72.14.204.68
8 5 ms 3 ms 5 ms 108.170.244.193
9 3 ms 3 ms 3 ms 66.249.94.33
10 4 ms 3 ms 3 ms dns.google [8.8.8.8]
If i do a traceroute to 10.8.0.1 it doesn't even reach DD-WRT:
Code:
tracert 10.8.0.1
Détermination de l’itinéraire vers 10.8.0.1 avec un maximum de 30 sauts.
1 * * * Délai d’attente de la demande dépassé.
2 * * * Délai d’attente de la demande dépassé.
Before the firmware upgrade and the fact that my router was "only" a router and didn't replace the ISP box it worked on the PC so it's not a wrong setup on PC.
My guess is that something on the router block the request on 10.8.0.1 coming from LAN but even with all logs activated i don't find a way to see which request are blocked and why
Is there a way to do that?
Might as well be a firewall but if i look on openvpn.conf route-up.sh is called with firewall setup inside it:
Code:
cat /tmp/openvpncl/route-up.sh
#!/bin/sh
[[ ! -z "$ifconfig_netmask" ]] && vpn_netmask="/$ifconfig_netmask"
cat << EOF > /tmp/openvpncl_fw.sh
#!/bin/sh
iptables -D POSTROUTING -t nat -o $dev -j MASQUERADE 2> /dev/null
iptables -I POSTROUTING -t nat -o $dev -j MASQUERADE
iptables -t raw -D PREROUTING ! -i $dev -d $ifconfig_local$vpn_netmask -j DROP 2> /dev/null
iptables -t raw -I PREROUTING ! -i $dev -d $ifconfig_local$vpn_netmask -j DROP
EOF
chmod +x /tmp/openvpncl_fw.sh
alldns="$(env | grep 'dhcp-option DNS' | awk '{ printf "%s ",$3 }')"
if [[ ! -z "$alldns" ]]; then
spbr="$(nvram get openvpncl_spbr)"
splitdns="$(nvram get openvpncl_splitdns)"
cat /tmp/resolv.dnsmasq > /tmp/resolv.dnsmasq_isp
[[ $spbr != "1" || $splitdns = "0" ]] && { rm -f /tmp/resolv.dnsmasq; nvram set openvpn_get_dns="$alldns"; }
set=0
for dns in $alldns;do
[[ $spbr != "1" || $splitdns = "0" ]] && echo "nameserver $dns" >> /tmp/resolv.dnsmasq
grep -q "^dhcp-option DNS $dns" /tmp/openvpncl/openvpn.conf || ip route add $dns via $route_vpn_gateway dev $dev 2> /dev/null
done
else
logger -p user.warning "OpenVPN No VPN DNS servers available"
fi
/tmp/openvpncl_fw.sh
exit 0
Do you have an idea on what blocks the request?
There is no Access Restrictions
My Network setup is:
Code:
Local IP Address: 192.168.1.1/24
Gateway: 0.0.0.0
Local DNS: 0.0.0.0
DHCP Server is enabled
Static DNS 1: 8.8.8.8
Static DNS 2: Bouygues telecom DNS 1
Static DNS 3: Bouygues telecom DNS 2
Routing table Entry List:
Code:
default y.y.128.1 default 0 WAN
10.8.0.0/24 default link 0 tun1 10.8.0.5
y.y.128.0/17 default link 0 WAN y.y.x.x
127.0.0.0/8 default link 0 lo
192.168.1.0/24 default link 0 LAN & WLAN 192.168.1.1
fddd:1194:1194:1194::/64 default 256 tun1
default default 2048 WAN
Policy Rules Entry List seems empty:
Code:
Priority 0, from all, table local
Priority 32766, from all, table main
Priority 32767, from all, table default
Clientlog:
20220724 13:24:27 W WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
20220724 13:24:27 W WARNING: file '/tmp/openvpncl/ta.key' is group or others accessible
20220724 13:24:27 Current Parameter Settings:
20220724 13:24:27 config = '/tmp/openvpncl/openvpn.conf'
20220724 13:24:27 mode = 0
20220724 13:24:27 NOTE: --mute triggered...
20220724 13:24:27 239 variation(s) on previous 3 message(s) suppressed by --mute
20220724 13:24:27 I OpenVPN 2.5.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 22 2022
20220724 13:24:27 I library versions: OpenSSL 1.1.1q 5 Jul 2022 LZO 2.10
20220724 13:24:27 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
20220724 13:24:27 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20220724 13:24:27 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20220724 13:24:27 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
20220724 13:24:27 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20220724 13:24:27 NOTE: --mute triggered...
20220724 13:24:27 1 variation(s) on previous 3 message(s) suppressed by --mute
20220724 13:24:27 Control Channel MTU parms [ L:1621 D:1156 EF:94 EB:0 ET:0 EL:3 ]
20220724 13:24:27 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
20220724 13:24:27 Local Options String (VER=V4): 'V4 dev-type tun link-mtu 1601 tun-mtu 1500 proto UDPv4 cipher AES-256-CBC auth SHA512 keysize 256 key-method 2 tls-client'
20220724 13:24:27 Expected Remote Options String (VER=V4): 'V4 dev-type tun link-mtu 1601 tun-mtu 1500 proto UDPv4 cipher AES-256-CBC auth SHA512 keysize 256 key-method 2 tls-server'
20220724 13:24:27 I TCP/UDP: Preserving recently used remote address: [AF_INET]5.39.x.x:1194
20220724 13:24:27 Socket Buffers: R=[262144->262144] S=[262144->262144]
20220724 13:24:27 W --mtu-disc is not supported on this OS
20220724 13:24:27 I UDP link local: (not bound)
20220724 13:24:27 I UDP link remote: [AF_INET]5.39.x.x:1194
20220724 13:24:27 TLS: Initial packet from [AF_INET]5.39.x.x:1194 sid=5514a09a 6e56fa8e
20220724 13:24:27 VERIFY OK: depth=1 CN=ChangeMe
20220724 13:24:27 VERIFY KU OK
20220724 13:24:27 NOTE: --mute triggered...
20220724 13:24:27 5 variation(s) on previous 3 message(s) suppressed by --mute
20220724 13:24:27 I [server] Peer Connection Initiated with [AF_INET]5.39.x.x:1194
20220724 13:24:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:27 D MANAGEMENT: CMD 'state'
20220724 13:24:27 MANAGEMENT: Client disconnected
20220724 13:24:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:27 D MANAGEMENT: CMD 'state'
20220724 13:24:27 MANAGEMENT: Client disconnected
20220724 13:24:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:27 D MANAGEMENT: CMD 'state'
20220724 13:24:27 MANAGEMENT: Client disconnected
20220724 13:24:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:27 D MANAGEMENT: CMD 'status 2'
20220724 13:24:27 MANAGEMENT: Client disconnected
20220724 13:24:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:27 D MANAGEMENT: CMD 'log 500'
20220724 13:24:27 MANAGEMENT: Client disconnected
20220724 13:24:28 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
20220724 13:24:28 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 ipv6 bypass-dhcp dhcp-option DNS 10.8.0.1 dhcp-option DNS 213.186.33.99 tun-ipv6 route-gateway 10.8.0.1 topology subnet ping 10 ping-restart 120 ifconfig-ipv6 fddd:1194:1194:1194::1003/64 fddd:1194:1194:1194::1 ifconfig 10.8.0.5 255.255.255.0 peer-id 0 cipher AES-256-GCM'
20220724 13:24:28 Pushed option removed by filter: 'redirect-gateway def1 ipv6 bypass-dhcp'
20220724 13:24:28 NOTE: --mute triggered...
20220724 13:24:28 7 variation(s) on previous 3 message(s) suppressed by --mute
20220724 13:24:28 Data Channel: using negotiated cipher 'AES-256-GCM'
20220724 13:24:28 Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ]
20220724 13:24:28 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20220724 13:24:28 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20220724 13:24:28 I TUN/TAP device tun1 opened
20220724 13:24:28 do_ifconfig ipv4=1 ipv6=1
20220724 13:24:28 I net_iface_mtu_set: mtu 1500 for tun1
20220724 13:24:28 I net_iface_up: set tun1 up
20220724 13:24:28 I net_addr_v4_add: 10.8.0.5/24 dev tun1
20220724 13:24:28 I net_iface_mtu_set: mtu 1500 for tun1
20220724 13:24:28 I net_iface_up: set tun1 up
20220724 13:24:28 I net_addr_v6_add: fddd:1194:1194:1194::1003/64 dev tun1
20220724 13:24:28 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
20220724 13:24:28 I Initialization Sequence Completed
20220724 13:24:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:34 D MANAGEMENT: CMD 'state'
20220724 13:24:34 MANAGEMENT: Client disconnected
20220724 13:24:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:34 D MANAGEMENT: CMD 'state'
20220724 13:24:34 MANAGEMENT: Client disconnected
20220724 13:24:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:34 D MANAGEMENT: CMD 'state'
20220724 13:24:34 MANAGEMENT: Client disconnected
20220724 13:24:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:34 D MANAGEMENT: CMD 'status 2'
20220724 13:24:34 MANAGEMENT: Client disconnected
20220724 13:24:34 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220724 13:24:34 D MANAGEMENT: CMD 'log 500'
19700101 01:00:00
The OpenVPN conf is in the attachment
There is some Additional Configuration:
Code:
remote-cert-tls server
verb 5
--pull-filter ignore redirect-gateway
The ping on 8.8.8.8 does not go through the VPN and it should not, i use the VPN only to access my remote server i do not want to go through the VPN for all requests.
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Sun Jul 24, 2022 12:14 Post subject:
A few not related things first.
You did not reset in a while as your MTU value is high, default is 1400 so consider using 1400 (advised on server and client)
From the additional config you can remove:
remote-cert-tls server
Instead use the GUI setting:
Verify Server Certificate
In the additonal config you added:
--pull-filter ignore redirect-gateway
Meaning there are no routes to the VPN server, i would remove it and test again.
However as topology subnet is used and the interface is setup with /24 Linux should have automatically set a route to the server but it is worth checking (ip route show)
So the problem could lie elsewhere maybe it is IPv6 which causes trouble, I would not use IPv6 to begin with, by default the latest OpenVPN (and we are using the latest) will use IPv6 if it is enabled to make a connection.
So use UDP4 as protocol and add to the additional config:
pull-filter ignore "route-ipv6"
pull-filter ignore "ifconfig-ipv6"
If you do not want to route all traffic through the VPN you can also use the GUI using PBR
Based on everything I've seen so far, there's no obvious reason the PC should NOT be able to ping 10.8.0.1. What is odd is that the tracert should AT LEAST indicate it got to the router's IP address, but it doesn't. It's as if the PC doesn't know to route to the router for that IP address.
Is it possible the PC is running its own OpenVPN client or server w/ the same IP network on its own tunnel?
Have you tried other LAN devices besides the PC to verify the problem applies to all of them and NOT just the PC?
While all the information provided so far is helpful, at the end of the day, we need to see the actual results of those settings as it affects the underlying routing tables, firewall, etc.
P.S. I know you've provided some of this already, but I want the FULL picture.
Code:
ifconfig
ip route
ip rule
iptables -t nat -vnL
iptables -vnL
Many times the configuration can look ok, but you won't notice the problem until you see the actual effects.
default via 94.239.128.1 dev eth0.100
10.8.0.0/24 dev tun1 scope link src 10.8.0.5
94.239.128.0/17 dev eth0.100 scope link src 94.239.x.x
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev br0 scope link src 192.168.1.1
ip rule
Code:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Chain trigger_out (6 references)
pkts bytes target prot opt in out source destination
Chain upnp (1 references)
pkts bytes target prot opt in out source destination
With the logs we see there is a rule ACCEPT for :
0 0 ACCEPT tcp -- * eth0.100 192.168.1.0/24 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT 47 -- * eth0.100 192.168.1.0/24 0.0.0.0/0
but no rule for 10.8.0.* might be the problem? If so how can i add a rule which will be saved for futur reboot ?
If it can help, i followed those steps to get rid of the ISP box:
1 In Setup/Networking add a VLAN tagging VLAN 2 Interface eth0 Tag Number 100 Prio 0 and reboot router
2 In Setup/Networking Port Setup chose value eth0.100 for WAN Port Assignment
3 In Administration/Commands add to startup script
Code:
swconfig dev eth0 vlan 100 set ports "0t 5t"
swconfig dev eth0 set apply
4 Clone ISP box mac address in Clone WAN MAC
5 In Services/Services, DHCP Vendorclass use value "BYGTELIAD" with Request IP equals to the static IP from ISP
6 Add ISP DNS in Static DNS 1 / Static DNS 2
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Sun Jul 24, 2022 14:04 Post subject:
The solution might be in the raw table:
iptables -vnL -t raw
If you see a DROP rule hit then read on about the CVE mitigation page 11 of the OpenVPN Server Setup guide or if you are lazy just disable CVE mitigation