Networking – How to enable LAN access to OpenVPN clients

networkingopenvpn

I have a server with 2 real NIC and 1 virtual NIC (tun0) created by OpenVPN.

eth0 is LAN - IP 192.168.2.1
eth1 is Internet - IP is public internet IP
tun0 is created by openvpn

What I need is that clients that connect to VPN server over eth1 will also get access to eth0 network, eg. will be able to connect to 192.168.2.21

This used to work in past until I rebooted the server and routing info got reset :/ I configured this couple years ago and forgot how I did that.

Routing table now looks like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         public gw       0.0.0.0         UG    0      0        0 eth1
public ip       *               255.255.255.0   U     0      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
192.168.8.0     192.168.8.2     255.255.255.0   UG    0      0        0 tun0
192.168.8.2     *               255.255.255.255 UH    0      0        0 tun0

When I launch OpenVPN it tries to add route

Tue Oct 11 19:29:58 2016 /sbin/ip route add 192.168.2.0/24 via 192.168.8.2
RTNETLINK answers: File exists
Tue Oct 11 19:29:58 2016 ERROR: Linux route add command failed: external program exited with error status: 2

It however doesn't seem to be possible because it already exists. When I remove this route openVPN succeeds in adding but it's no longer possible for server to reach 192.168.2.0/24 network.

How can I make it work?

EDIT: yes, I have both IPv4 and IPv6 forwarding enabled

Best Answer

you'll need ip_forward set in the sysctl, and an accept line in the FORWARD table in iptables (which often defaults to ACCEPT anyhow)

http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/

Part 1. Output of locally-generated (outbound connection) packages.

Mark outgoing locally generated packages with connection-specific mark for future rerouting with different rt_table.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp --dport Y -m owner --uid-owner 100Z -j CONNMARK --set-mark 2
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp --dport Y -m owner --uid-owner 100Z -j CONNMARK --set-mark 2

Translate connection-specific markers to package-specific markers.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j MARK --set-mark 2
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j MARK --set-mark 2

Save marker for further restoring it for all tracked connections. This can be implemented in NAT POSTROUTING table only - it's just a precaution to not loose markers after connection traverse the routing table.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp -m owner --uid-owner 100Z -m tcp --dport Y -m connmark ! --mark 0 -j CONNMARK --save-mark
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp -m owner --uid-owner 100Z -m udp --dport Y -m connmark ! --mark 0 -j CONNMARK --save-mark

Normally connection-specific markers should be saved after packages rerouted and reached NAT POSTROUTING table

/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j CONNMARK --save-mark
/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j CONNMARK --save-mark

Replace source with proper VPN-related local address for tun0 interface.

/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j SNAT --to-source 10.???.???.???
/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j SNAT --to-source 10.???.???.???

Part 2. Input of connections related to locally-generated (outbound connection) packages.

Restore connection-related markers for input packets before they go to the routing table.

/sbin/iptables -t mangle -A PREROUTING -i tun0 -p tcp -j CONNMARK --restore-mark
/sbin/iptables -t mangle -A PREROUTING -i tun0 -p udp -j CONNMARK --restore-mark

Part 3. Optional optimization

Other than above rules there is a strong desire in optimizing marking process to prevent or minimize redundant and repeated checks with marking. The most general approach for this task is to distinguish rules between NEW and RELATED,ESTABLISHED connection and use below template for optimal remarking already marked connections: * Restore old markers (you probably won't do this for NEW connections because they are obviously wasn't marked earlier):

/sbin/iptables -A OUTPUT -t mangle -j CONNMARK --restore-mark

Skip already marked connections:

/sbin/iptables -A OUTPUT -t mangle -m mark ! --mark 0 -j ACCEPT

Mark new (usually marking only NEW connection should be enough) connections:

/sbin/iptables -A OUTPUT -m mark --mark 0 -p tcp --dport 21 -t mangle -j MARK --set-mark 1
/sbin/iptables -A OUTPUT -m mark --mark 0 -p tcp --dport 80 -t mangle -j MARK --set-mark 2

Mark other packages with a "dummy" marker (that is not used anywhere else at all):

/sbin/iptables -A OUTPUT -m mark --mark 0 -t mangle -p tcp -j MARK --set-mark 3

Finally save markers:

/sbin/iptables -A OUTPUT -t mangle -j CONNMARK --save-mark

NOTE: the above settings are not a mandatory part of netfilter configuration for split tunnel - it is just a template (i.e. proper suggestion) for the way to minimize redundant filter checks. It also can be POSTROUTING instead of OUTPUT, but only one place is recommended for markings, do not need to implement it twice.

Part 4. Create table aliases in rt_tables.

echo 2 vpn >/etc/iproute2/rt_tables
echo 3 novpn >/etc/iproute2/rt_tables

Part 5. Configuring routing tables for VPN connections.

This is a standard configuration for VPN that allows to redirect all local sources (0.0.0.0/1 and 128.0.0.0/1 subnets include the whole IP range for local addresses) and also provides backward compatibility for returning packages (i.e. the "default" route).

Table with VPN connection

ip route flush table vpn
ip route add 10.???.???.(???+1) dev tun0 src 10.???.???.??? table vpn
ip route add 0.0.0.0/1 dev tun0 via 10.???.???.(???+1) table vpn
ip route add 128.0.0.0/1 dev tun0 via 10.???.???.(???+1) table vpn
ip route add 192.168.0.0/16 src 192.168.XXX.XXX dev eth0 table vpn
ip route add default via 192.168.XXX.1 dev eth0 table vpn

The other table called "novpn". It's goal to provide direct routing bypassing VPN connection.

ip route flush table novpn
ip route add 192.168.0.0/16 src 192.168.XXX.XXX dev eth0 table novpn
ip route add default via 192.168.XXX.1 dev eth0 table novpn

Part 6. Configuring routing rules (it is better to follow rule order below)

ip rule add from all lookup novpn
ip rule add from all fwmark 2 lookup vpn
ip rule add from 10.XXX.XXX.XXX lookup vpn

Part 7. Final steps

Now it is time to flush main routing table (there is no need for it while split tunnel is working):

ip route flush table main

The last step in configuration is to enable IP forwarding and dynamic IP addresses for sockets (client application connections) in Linux kernel:

echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv4/ip_dynaddr

Now we can launch OpenVPN client with "--route-noexec" and/or "--ifconfig-noexec" (whether you already know or still not receive push message from VPN server with your tun0 interface configuration) parameters. If there are troubles with tun0 addresses - it is better to not use "--ifconfig-noexec" and let OpenVPN client set tun0 addresses for you. After that you just need to delete some old rules from "ip route" and "/sbin/iptables" and replace them with similar ones containing proper tun0 addresses (refer to all lines with 10.XXX.XXX.XXX or 10.XXX.XXX.(XXX+1) from above).

openvpn --config ./<your_config>.ovpn --route-noexec --ifconfig-noexec --auth-nocache

Those are only rules for outbound connections. The main difference between inbound and outbound configurations: inbound rules should be implemented mostly in "mangle" table, not "nat", and vice-verse for outbound as shown above. There is an exception - for output of both locally-generated (outbound) and answered (inbound connection) packages rules must be placed in "mangle" table due to netfilter architecture implementation (for some reason "nat" table will intercept packages only after the rerouting procedure - consult Wikipedia netfilter graph or netfilter official documentation).

Linux – AWS OpenVPN Routing

At first glance it looks like you might have forgotten to update the security group of the VPN server to accept traffic from the other instances in the VPC. To test, could you edit the security group that the AWS VPN instance is in and add a rule that allows all traffic from 172.31.10.0/20.

I think this is the problem because security groups act as a stateful firewall. This means that when the AWS VPN instance sends traffic out from home to other AWS instances, the security group will automatically allow the return traffic. But when traffic is initiated by another instance in AWS with a destination of your home network, there will be no rule in the AWS VPN instance's security group to allow the traffic. This is why traffic from home can reach AWS, but the reverse doesn't work.

If the security groups weren't the problem could you...

Please enable VPC flowlogs within your VPC configuration. This will log netflow like information to CloudWatch Logs. We can use this for troubleshooting the AWS side of the traffic.

Could you drill down into which of these situations work / don't work:

Can you ping the home end of the tunnel from the AWS VPN instance?
Can you ping the home end of the tunnel from another AWS instance?
Can you ping another home machine from the AWS VPN instance?
Can you ping another home machine from another AWS instance?

Include a traceroute from another AWS instance to another home machine.