OpenVPN - TUN external connectivity

Janusz

Janusz

Hi Everyone,

I'm running OpenVPN 2.4.3 on FreeBSD 10.3 and routing all traffic via a TUN/tunnel. I can access internal services but cannot reach anything outside of the network. I did my best to try to find an answer to where the problem lies, but I keep going round in circles now. I would greatly appreciate some advice! Setup details:

192.168.1.1/24 - network gateway
192.168.1.2/24 - FreeBSD server with OpenVPN
192.168.10.0/24 - OpenVPN client network

VPN clients: mostly Android 5+ devices, very occasional Windows client
Network services needed: internal websites, Samba shares, DLNA server

Clients can ping 192.168.1.2 (BSD) and 192.168.1.1 (gateway). Pinging any external IP address fails. DNS resolution also fails. Traceroute for external IPs shows no progress making me think this is a BSD routing table issue but this is where I get lost - default route is to the gateway, why wouldn't packets make their way there?

Some guides suggest running NAT on the server. This shouldn't be needed as the gateway handles NAT and I can access the gateway.

I've been experimenting with different config options to resolve this and some of them might've been left around. A sanity check would be most useful!

OpenVPN server config:
Code: 
local 192.168.1.2
port 9902
proto udp
dev tun
persist-tun
tls-version-min 1.2
tls-server
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
remote-cert-eku "TLS Web Client Authentication"
cipher AES-256-CBC
auth SHA256
remote-cert-tls client
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/xx.crt
key /usr/local/etc/openvpn/keys/yy.key
dh /usr/local/etc/openvpn/keys/dh.pem
tls-auth /usr/local/etc/openvpn/keys/ta.key 0
topology subnet
server 192.168.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "route 192.168.10.0 255.255.255.0"
push "redirect-gateway autolocal"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 192.168.1.2"
duplicate-cn
keepalive 10 120
max-clients 10
persist-key
status openvpn-status.log
verb 3
sndbuf 0
rcvbuf 0
mssfix 1300

OpenVPN client config:
Code: 
dev tun
persist-tun
auth-nocache
<connection>
remote xx.yy.zz 1000
</connection>
resolv-retry infinite
mute-replay-warnings
verb 3
client
remote-cert-tls server
tls-version-min 1.2
tls-client
remote-cert-eku "TLS Web Server Authentication"
cipher AES-256-CBC
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
key-direction 1
<tls-auth>
...
</tls-auth>

Netstat -r
Code: 
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.1.1        UGS        bge0
localhost          link#3             UH          lo0
192.168.1.0        link#2             U          bge1
dc                 link#2             UHS         lo0
192.168.1.220      link#1             UHS         lo0
192.168.1.220/32   link#1             U          bge0
192.168.10.0       192.168.10.1       UGS        tun0
192.168.10.1       link#4             UHS         lo0
192.168.10.2       link#4             UH         tun0

Internet6:
Destination        Gateway            Flags      Netif Expire
::                 localhost          UGRS        lo0
localhost          link#3             UH          lo0
::ffff:0.0.0.0     localhost          UGRS        lo0
fe80::             localhost          UGRS        lo0
fe80::%lo0         link#3             U           lo0
fe80::1%lo0        link#3             UHS         lo0
fe80::%tun0        link#4             U          tun0
fe80::1e98:ecff:fe link#4             UHS         lo0
ff01::%lo0         localhost          U           lo0
ff01::%tun0        fe80::1e98:ecff:fe U          tun0
ff02::             localhost          UGRS        lo0
ff02::%lo0         localhost          U           lo0
ff02::%tun0        fe80::1e98:ecff:fe U          tun0

Ifconfig
Code: 
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 1c:98:ec:0f:4d:74
        inet 192.168.1.220 netmask 0xffffffff broadcast 192.168.1.220
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 1c:98:ec:0f:4d:75
        inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::1e98:ecff:fe0f:4d74%tun0 prefixlen 64 scopeid 0x4
        inet 192.168.10.1 --> 192.168.10.2 netmask 0xffffff00
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 40139
 
Last edited by a moderator:
Did you enable routing? Add to /etc/rc.conf:
Code: 
gateway_enable="YES"
 
Yes I did. I also noticed now that I'm dropping ICMP redirects - don't think this would impact my setup though as it deals with established connections rather than initial routing? Just putting it out there. :)
 
If your server is not doing NAT to hide the 192.168.10.0/24 behind the 192.168.1.2 address, when your default gateway (router) needs to know the route back to 192.168.10.0/24.
e.g. static route on the router 192.168.1.1: static 192.168.10.0/24 -> 192.168.1.2 (BSD)
 
Janusz said:
I also noticed now that I'm dropping ICMP redirects
Click to expand...
If you get ICMP redirects it means your routing isn't set up correctly. If you send traffic to the wrong gateway that gateway will respond with ICMP redirects pointing to the correct one. Just the fact that you get ICMP redirects means there's something not correctly being routed.
 
  • Thanks
Reactions: Oko
scorpizz - yes, the gateway is configured with a static route as per your note. Ping works so packets are certainly finding their way back to the *.10.0 network.

SirDice - what I meant is that I've got icmp_drop_redirect="YES" in rc.conf. I've mentioned this because DNS resolution is handled by the gateway and the BSD box. Gateway routes to external destinations, BSD performs internal domain routing. In theory this shouldn't impact traffic externally bound - the gateway isn't dropping anything.

I've been wondering whether changing TUN to TAP wouldn't completely eradicate the problem... Non-VPN traffic on the network works perfectly well. I could also receive broadcasts which would be useful. The reason why I haven't gone for that setup is because Android previously did not support TAP. Apparently, this is now changing but I haven't investigated this adequately yet.
 
Janusz said:
scorpizz - yes, the gateway is configured with a static route as per your note. Ping works so packets are certainly finding their way back to the *.10.0 network.
Click to expand...


Did you check that the router (default gateway) is doing NAT for both nets (192.168.1.0/24 + 192.168.10.0/24) and not only for the 192.168.1.0/24 ?
I can't remember if the router needs to be connected to the network that it will do the NAT on, but I actually think so...
If that's the case, you need to do 1st part of the NAT on the BSD for the vpnclient net (192.168.10.0/24 -> 192.168.1.x) as the router has no connected interface to the vpnclient network (192.168.10.0/24).
The 2nd NAT is on the router as today (192.168.1.0/24 -> internet)
 
Janusz said:
what I meant is that I've got icmp_drop_redirect="YES" in rc.conf. I've mentioned this because DNS resolution is handled by the gateway and the BSD box. Gateway routes to external destinations, BSD performs internal domain routing. In theory this shouldn't impact traffic externally bound - the gateway isn't dropping anything.
Click to expand...
Ok, that's good. I got the impression you where seeing ICMP redirect packets on your network. It's good to drop ICMP redirects, as I said, if you see ICMP redirects on your network you have some routing issues that would need to be sorted out first.
 
You must log in or register to reply here.
Back
Top