Arch Linux

kgizdov

Package Maintainer (PM)

From: Edinburgh, UK

Registered: 2015-12-08

Posts: 113

[SOLVED] Remote OpenVPN LAN unreachable from laptop, is from Android.

Hi,

First I should mention that the local and and remote LANs sit on 192.168.1.0. My local/client LAN router is sitting at 192.168.1.1. The remote LAN router is also sitting on 192.168.1.1. Actual VPN server is sitting on 192.168.1.73. What I want is to type 192.168.1.1 in the browser and reach the remote LAN. I have been able to do this on my Android phone, but not on my Linux laptop. I use absolutely identical settings on both devices. The reason behind this effort is that I want to be able to access my remote/VPN LAN regardless of the network I am currently connected at the moment - I travel a lot. Here's the config files:

server.conf

port 1194
proto udp
dev tun

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/crt-openvpn.crt
key /etc/openvpn/easy-rsa/keys/key-openvpn.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

keepalive 10 120

tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0

cipher AES-256-CBC

tls-version-min 1.2

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256

auth SHA256

comp-lzo

user nobody
group nobody

persist-key
persist-tun

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"

status /var/log/openvpn-status.log
verb 3

log-append /var/log/openvpn
status /tmp/vpn.status 10

client.conf

client
remote 'name' 1194 - removed actual address since this is public
dev tun
proto udp

resolv-retry infinite
nobind

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/key.crt
key /etc/openvpn/keys/key.key

ns-cert-type server

keepalive 10 120

tls-auth /etc/openvpn/keys/ta.key 1

cipher AES-256-CBC

tls-version-min 1.2

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256

auth SHA256

comp-lzo

user nobody
group nobody

persist-key
persist-tun

verb 3

I have also set up dnsmasq to make sure DNS queries are dealt with on the VPN server. This works fine. The only issue remaining as I said before is when I try to load 192.168.1.1 from the client. On my Android phone, this redirects to the remote router as I want it to. But on my Linux machine it goes to my local router, which I do not want. I fail to understand how and why the laptop sees the local LAN when I have instructed it to communicate everything through the remote LAN.

What I have discovered is that if I change my local LAN to 192.168.2.0, I am able to reach 192.168.1.1 on the remote LAN. But since I travel a lot and cannot always connect to a network I manage, I cannot ensure the local subnet will not match the remote one. Thus I wish to be able to reach the remote LAN regardless of the local setup. How is this achieved?

Thanks.

Last edited by kgizdov (2016-01-04 21:00:20)

Rob_H

Member

Registered: 2012-06-19

Posts: 72

Re: [SOLVED] Remote OpenVPN LAN unreachable from laptop, is from Android.

When using dev tun, you can't use the same subnet on both sides of the VPN connection because your client can't route traffic to both the local LAN and the remote LAN when the address schemes overlap. I'm not sure how it's working on your Android device. Maybe it's on a different local subnet (e.g. your wireless carrier's).

kgizdov

Package Maintainer (PM)

From: Edinburgh, UK

Registered: 2015-12-08

Posts: 113

Re: [SOLVED] Remote OpenVPN LAN unreachable from laptop, is from Android.

When using dev tun, you can't use the same subnet on both sides of the VPN connection because your client can't route traffic to both the local LAN and the remote LAN when the address schemes overlap. I'm not sure how it's working on your Android device. Maybe it's on a different local subnet (e.g. your wireless carrier's).

The thing is, I don't want any traffic to be routed to the local LAN. That's why I thought if I do redirect-gateway def1 bypass-dhcp it would ignore the local LAN. However, OpenVPN seems to be leaking. Doesn't this give an opportunity to a remote attacker to probe my local LAN just by making the page call common IPs until it hits my subnet. Definitely not an expert, but doesn't this defeats the purpose of the redirect-gateway?

I really hoped this is configuration issue on my side. But I do not agree with the Android point you made. Here's a screenshot. http://i.imgur.com/7StCBYh.png

Could it be the IP v6 address that my router issues? I do have one assigned on my laptop as well, but maybe there's something I'm missing.

--  read the Forum Etiquette and only post thumbnails http://wiki.archlinux.org/index.php/For … s_and_code [jwr] --

Rob_H

Member

Registered: 2012-06-19

Posts: 72

Re: [SOLVED] Remote OpenVPN LAN unreachable from laptop, is from Android.

You can't ignore the local LAN. At a minimum, you need to route VPN traffic over the local gateway. What you're doing is at best misguided (unless you get very creative with your routing table) or at worst just won't work. You need to re-number one of the subnets.

It is not the case that someone on the remote LAN will be able to probe your local LAN. OpenVPN supports such bidirectional network-to-network links, but it requires additional configuration on both sides.

kgizdov

Package Maintainer (PM)

From: Edinburgh, UK

Registered: 2015-12-08

Posts: 113

Re: [SOLVED] Remote OpenVPN LAN unreachable from laptop, is from Android.

You can't ignore the local LAN. At a minimum, you need to route VPN traffic over the local gateway. What you're doing is at best misguided (unless you get very creative with your routing table) or at worst just won't work. You need to re-number one of the subnets.

It is not the case that someone on the remote LAN will be able to probe your local LAN. OpenVPN supports such bidirectional network-to-network links, but it requires additional configuration on both sides.

You are absolutely correct. Apparently, networks don't work the way I thought. I read some more and followed the suggestions in the RFC1918 spec to resolve my issue. Thanks.

But it still could be done according to this

Last edited by kgizdov (2016-01-04 21:26:22)