Hi,
On 10/02/20 12:00, Reto Schneider wrote:
Hello,
I am observing the behavior of OpenVPN 2.4.7 trying to connect to IP
addresses it never should. The devices it is running on are Yocto based,
embedded, 32bit MIPS and deployed in remote networks which are not under
my control.
1) OpenVPN connects successfully to server (example.com, TCP, Port 443)
TCP/UDP: Preserving recently used remote address: [AF_INET]a.b.c.d:443
Attempting to establish TCP connection with [AF_INET]a.b.c.d:443 [nonblock]
TCP connection established with [AF_INET]a.b.c.d:443
TCP_CLIENT link local: (not bound)
TCP_CLIENT link remote: [AF_INET]a.b.c.d:443
[server] Peer Connection Initiated with [AF_INET]a.b.c.d:443
Options error: option 'route' cannot be used in this context
([PUSH-OPTIONS])
Options error: option 'redirect-gateway' cannot be used in this context
([PUSH-OPTIONS])
Options error: option 'dhcp-option' cannot be used in this context
([PUSH-OPTIONS])
Options error: option 'dhcp-option' cannot be used in this context
([PUSH-OPTIONS])
Options error: option 'route' cannot be used in this context
([PUSH-OPTIONS])
TUN/TAP device vpn0 opened
/sbin/ip link set dev vpn0 up mtu 1500
/sbin/ip addr add dev vpn0 local 10.176.x.y peer 10.176.x.z
Initialization Sequence Completed
Hint:
- example.com is put in place if the real domain of the servers
- a.b.c.d refers to one out of multiple IPv4 addresses assigned to
example.com
2) Internet connectivity lost because wifi/ethernet/upstream
connectivity got bad/lost:
[server] Inactivity timeout (--ping-restart), restarting
/sbin/ip addr del dev vpn0 local 10.176.x.y peer 10.176.x.z
SIGUSR1[soft,ping-restart] received, process restarting
3) OpenVPN tries to reconnect:
TCP/UDP: Preserving recently used remote address: [AF_INET]a.b.c.d:443
Attempting to establish TCP connection with [AF_INET]a.b.c.d:443 [nonblock]
TCP: connect to [AF_INET]a.b.c.d:443 failed: Network is unreachable
SIGUSR1[connection failed(soft),init_instance] received, process restarting
4) After a while, tries to resolve the domain again (and fails):
RESOLVE: Cannot resolve host address: example.com:443 (Temporary failure
in name resolution)
RESOLVE: Cannot resolve host address: example.com:443 (Temporary failure
in name resolution)
Could not determine IPv4/IPv6 protocol
SIGUSR1[soft,init_instance] received, process restarting
5) Optional: Wifi comes up again, interface gets IP address and route
assigned (dhcpcd logs):
wlan0: offered 192.168.0.2 from 192.168.0.1
wlan0: probing address 192.168.0.2/24
wlan0: leased 192.168.0.2 for 120 seconds
wlan0: adding route to 192.168.0.0/24
wlan0: changing default route via 192.168.0.1
wlan0: deleting route to 169.254.0.0/16
6) OpenVPN suddenly tries to connect to a faulty IP:
TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.0.1:443
Attempting to establish TCP connection with [AF_INET]192.168.0.1:443
[nonblock]
TCP: connect to [AF_INET]192.168.0.1:443 failed: Connection refused
SIGUSR1[connection failed(soft),init_instance] received, process restarting
In this case there seems to be a correlation to the router IP address in
5), but I have many more examples of unexplicable IP addresses (e.g.
1.1.1.11, 212.27.38.252, 192.168.246.123, ...), all of which are
definitely not assigned to example.com.
A log where I have absolutely now indication why a strange IP addres
(not the routers one) suddenly shows up:
TCP/UDP: Preserving recently used remote address: [AF_INET]a.b.c.d:443
Attempting to establish TCP connection with [AF_INET]a.b.c.d:443 [nonblock]
TCP: connect to [AF_INET]a.b.c.d:443 failed: Network is unreachable
SIGUSR1[connection failed(soft),init_instance] received, process restarting
TCP/UDP: Preserving recently used remote address:
[AF_INET]192.168.246.123:443
Attempting to establish TCP connection with [AF_INET]192.168.246.123:443
[nonblock]
TCP: connect to [AF_INET]192.168.246.123:443 failed: Network is unreachable
SIGUSR1[connection failed(soft),init_instance] received, process restarting
Use client (2.4.7) configuration:
client
dev vpn0
dev-type tun
remote example.com 443 tcp
nobind
persist-key
ca /path/to/ca
cert /path/to/client-cert
key /path/to/client-key
remote-cert-tls server
comp-lzo
ping-restart 0
route-nopull
route 10.x.y.z
route 10.a.b.c
connect-retry 5 30
Server configuration (Running 2.4.6):
port 443
proto tcp
dev tun
ca /path/to/ca
cert /path/to/server-cert
key /path/to/server-key
crl-verify /path/to/crl.pem
dh /path/to/dh2048.pem
server 10.x.0.0 255.255.0.0
push "route 10.x.x.x 255.255.255.0"
push "redirect-gateway"
push "dhcp-option DNS 10.176.0.1"
push "dhcp-option WINS 10.176.0.1"
keepalive 10 120
comp-lzo
max-clients 16380
persist-key
persist-tun
status /path/to/openvpn-status.log 5
status-version 2
log-append /path/to/openvpn.log
verb 0
tun-mtu 1500
script-security 2
client-connect "/path/to/script.sh"
management 0.0.0.0 2194 /path/to/management-password
the line
push "dhcp-option DNS 10.176.0.1"
is the main suspect here... my guess as to what happens is this:
1) VPN is started
2) that line causes the local /etc/resolv.conf file to be overwritten
with the new DNS setting
3) VPN line wobbles and the VPN needs to reconnect; the /etc/resolv.conf
file is still pointing to the VPN-supplied DNS server
4) openvpn tries to resolve the IP address of the VPN server and queries DNS
5) Lord knows which server at that time respond to 10.176.0.1 and lord
knows what answer it sends back
How to debug/find out if this is what is happening:
- stop the VPN on the client
- on the client, check if the IP address 10.176.0.1 is reachable and
whether it replies to DNS queries
- then, see what answer it gives back
A quick&dirty solution is to simply NOT use a DNS name for the Openvpn
server but to use an IP address instead - if the problem then "vanishes"
then at least you know you've found the root cause. Whether you can live
with
Remote a.b.c.d
instead of
Remote server.example.com
is something to think about *AFTER* that.
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users