Understanding the OpenVPN network setup

My OpenVPN setup broke a few weeks ago and I’m trying to understand how it all goes together. The actual OpenVPN negotiation works and I can watch ping packets arriving from the remote machine into “tun_turris” however no replies are ever sent. I think this is down to bad routing on the TO side. As I was trying to figure out what’s going on I found there was a br-vpn-turris bridge but it didn’t have the tun_turris device attached.

I’ve deleted everything and want to re-build the config again but I’m confused as to if I need a bridge just for the VPN? Surely I just need the VPN end point and the appropriate routing/forwarding setup? Or should all “zones” be represented by a bridge with one or more interfaces attached to it?

The other option would be to bridge the OpenVPN directly onto my lan but then I think I run into problems of where IP addresses are assigned. Are there any network diagrams of how OpenVPN is meant to integrate with the rest of the system?

Thanks,

This could be a firewall configuration issue. What is the response output on the client side to those ping requests, assuming that the OVPN server ip is being pinged and not an ip from another subnet?

Unless I am mistaken the TUN iface cannot be bridged but only the TAP iface.

The OVPN server (TUN) should be configured with its own subnet, separate from any other existing subnets. TAP is different however.

The OVPN server needs to propagate routed subnets, e.g. the LAN, to the clients in order for the clients to be aware of the routing.

The communication between the OVPN server subnet and other subnets is facilitated with traffic forwarding rules set in the firewall (kernel netfilter.)

This could be a firewall configuration issue. What is the response output on the client side to those ping
requests, assuming that the OVPN server ip is being pinged and not an ip from another subnet?

I regenerated the config and it seems a bit more sane now. I can ping the remote tun_turris end of the connection now and ping the client from the shell on the Turris. However I can’t ping the VPN address from the LAN.

Unless I am mistaken the TUN iface cannot be bridged but only the TAP iface.

Deleting all the VPN bridges and deleting and re-applying the OpenVPN config seems to have sorted it out - there is now a vpn_turris interface associated directly with the tun_turris device.

The OVPN server needs to propagate routed subnets, e.g. the LAN, to the clients in order for the clients to be aware of the routing.
The communication between the OVPN server subnet and other subnets is facilitated with traffic forwarding rules set in the firewall (kernel netfilter.)

I have the vpn_turris set forward to lan with accept, accept, accept and masquerading enabled. But the packets from the lan don’t make it across. I can see them with:

root@turris:~# tcpdump -i br-lan host 10.111.111.6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
16:02:29.739454 IP 192.168.1.1 > 10.111.111.6: ICMP echo request, id 2649, seq 74, length 64

But not on the vpn interface:

root@turris:~# tcpdump -i tun_turris
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun_turris, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured

Aren’t the zone forwarding rules enough? I thought that was automatic and I didn’t need to add explicit traffic rules.

Try whether enabling/disabling MSS clamping in the OVPN firewall zone makes a difference.

I would expect so but cannot really comment since not using the automatic setup/config from the frontend (Foris/LuCI). However, the LAN firewall zone needs also to be connected the OVPN zone

Yep that’s what I have set up - do you know which firewall chains they should be travesing? Maybe I can follow what’s going on by dumping iptables. Following zone_lan_forward I see:

162	36.67 KB	zone_vpn_turris_dest_accept	

But when I look at zone_vpn_turris_dest_accept none of the counters are incrementing:

|0|0.00 B|DROP|all||br-vpn_turris|0.0.0.0/0|0.0.0.0/0|ctstate INVALID / !fw3: Prevent NAT leakage /|
|0|0.00 B|accept|all|
|br-vpn_turris|0.0.0.0/0|0.0.0.0/0|/* !fw3 */|

Although those rules seem to be looking for forwards to br-vpn-turris which is just wrong. I think for some reason the firewall creation script keeps assuming the zone forward has to be a bridge…

root@turris:~# iptables -v -L zone_vpn_turris_dest_accept
Chain zone_vpn_turris_dest_accept (3 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    br-vpn_turris  anywhere             anywhere             ctstate INVALID /* !fw3: Prevent NAT leakage */
    0     0 accept     all  --  any    br-vpn_turris  anywhere             anywhere             /* !fw3 */

Well I guess none of those rules are going to match as the output interface should be pointing at:

tun_turris Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.111.111.1  P-t-P:10.111.111.2  Mask:255.255.255.255

Seems curious/strange indeed, maybe a bug in the script. Did you try rebooting the router or restarting the network?

Yes I tried several reboots as well as restarting the firewall and disable/re-enable of the OpenVPN config.

Are you just trying to enable LAN clients to access the VPN, or are you also trying to make it so the VPN endpoint can access LAN clients?

If it’s the latter, check the routing table on the other end of the VPN to make sure the routes are set up right. If it’s the former, you can do the same, but it would also be sufficient just to enable NAT on the VPN interface.

Mostly LAN to remote host connected to VPN.

In order for this to work, either the remote VPN endpoint needs to know that the LAN IP range should be routed through the VPN (this can be pushed via OpenVPN configs), or the VPN interface on the router needs to have NAT enabled.

Where is this configuration knob for NAT on for the VPN? The router has updated and now the VPN is totally non-functional even with my patch to the firewall.