Openvpn: Subnets for different groups - Destination host unreachable

Question

I would like to configure an Openvpn instance which is able to restrict access depending on the subnet of a client. As an example with two client groups/subnets A and B, users of net A can connect to clients of net B but clients of B cannot see the A clients.

There is an example on the Openvpn-HowTo-Site, which is partially similar to my goal (https://openvpn.net/community-resources/how-to/#policy). I followed the explanations there and my final server.conf looks like this (I removed some parts like paths to the ca.crt/key and cipher, as they are not important for this issue):

port 1194
proto udp
dev tun

topology subnet
server 10.9.0.0 255.255.255.0

client-config-dir ccd
route 10.9.1.0 255.255.255.0
route 10.9.2.0 255.255.255.0
client-to-client

verb 3

With this config I can use three subnets: - 10.9.0.0/24 - 10.9.1.0/24 - 10.9.2.0/24

So a client which connects and which CN has no file in the ccd directory, will get an IP of the 10.9.0.0/24 net. This is working and clients inside of this net can ping each other and the server 10.9.0.1.

If I now create a file for a CN in the ccd directory with the content

ifconfig-push 10.9.2.2 255.255.255.0

The client can connect with the server and gets the IP 10.9.2.2. There are no errors or warnings in my log and I think the most interesting line might be this one:

Mon Nov 12 15:06:40 2018 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.9.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.9.2.2 255.255.255.0'

But: I am not able to communicate with the server:

PING 10.9.0.1 (10.9.0.1) 56(84) bytes of data.
From 62.155.YYY.XXX icmp_seq=1 Destination Host Unreachable
From 62.155.YYY.XXX icmp_seq=2 Destination Host Unreachable

A ping to 10.9.2.1 results in 100% packet loss. What am I missing in my VPN configuration to be able to communicate with the server?

What I tried was to add an iptables-rule (ipv4-forwarding is enabled on server)

iptables -I FORWARD -i tun0 -s 10.9.2.0/24 -d 10.9.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

but it had no effect. I also tried:

iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.66.4.4 -j ACCEPT

but also with no effect. As I unfortunately am a beginner regarding iptables, I hope someone out there might see the problem. But also I am not sure if this is really an iptables-issue, as maybe my server-config needs to push a route to the clients? I found no good explanations on this issue and everything I tried with push route resulted in errors.

Edit: What I also tried was to push routes in my server.conf:

push "route 10.9.0.0 255.255.255.0"
push "route 10.9.1.0 255.255.255.0"
push "route 10.9.2.0 255.255.255.0"

But this resulted in

Tue Nov 13 09:40:25 2018 /sbin/ip route add 10.9.0.0/24 via 10.9.0.1
RTNETLINK answers: Network is unreachable
Tue Nov 13 09:40:25 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Nov 13 09:40:25 2018 /sbin/ip route add 10.9.1.0/24 via 10.9.0.1
RTNETLINK answers: Network is unreachable
Tue Nov 13 09:40:25 2018 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Nov 13 09:40:25 2018 /sbin/ip route add 10.9.2.0/24 via 10.9.0.1
RTNETLINK answers: Network is unreachable
Tue Nov 13 09:40:25 2018 ERROR: Linux route add command failed: external program exited with error status: 2

Edit 2:: I read an openvpn-Forum post pointing out, that the above mentioned HOWTO-policy-example (https://openvpn.net/community-resources/how-to/#policy) is using three server instances not one. This is a point that was unclear for me before, as it was not mentioned in the HOWTO. I can't find the URL to this post anymore, but I am interested, if it still might be possible to configure one openvpn-server with multiple subnets

Answer 1

I managed to get this working by making the server /16 instead of /24 and setting client-to-client to false, since the traffic will be forwarded before it reaches the IP layer of the OpenVPN Server, iptables won't be able to limit the traffic(see this post)

server.conf

...
server 10.9.0.0 255.255.0.0 # Subnet mask /16 instead of /24
;route 10.9.1.0 255.255.255.0 # These were not needed when the subnet mask is /16
;route 10.9.2.0 255.255.255.0 # These were not needed when the subnet mask is /16
;client-to-client
...

For a client config in the ccd directory we also need to update the subnet mask. From 255.255.255.0 to 255.255.0.0

ifconfig-push 10.9.2.2 255.255.0.0

Now you only need to add the appropriate iptable rules. Depending on your setup these might need more configuration. I follwed this example to get started since I'm also quiet new to iptables. Below are some examples which might be useful.

# Make sure established packets are allowed
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Allow traffic from one subnet to the other
iptables -A FORWARD -i tun0 -s 10.9.0.0/24 -d 10.9.2.0/24 -j ACCEPT
# Drop all traffic
iptables -A FORWARD -i tun0 -s 10.8.0.0/16 -d 10.8.0.0/16 -j DROP

Answer 2

I noticed in your server.conf file, it has dev tun, but in you iptables rules it's tun0. Change it to tun0 in server.conf.

It might be a good idea to work with the bare minimum itpables rules. You can back them up, reset them and add them in one by one.

You'll need to backup the current rules in case you want to apply them back in later

iptables-save > /path/to/backup.txt

You can restore it later with

iptables-restore < /path/to/backup.txt

I run the following to flush all iptables rules:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

NOTE: I found the flush commands in (another post)[https://superuser.com/questions/634469/need-iptables-rule-to-accept-all-incoming-traffic]

Now add the rules back in one by one.

Answer 3

Use iptables ... -i tun+ so the rules work for both tun0, tun1, etc..

The sysctl net.ipv4.ip_forward = 1 should be set.

This works for me:

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -d 1.2.3.4/32 -i tun+ -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT

# also allow output
iptables -A OUTPUT -p tcp -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m state --state NEW -j ACCEPT

Add a logging target afterwards:

iptables -A FORWARD -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[IPTABLES] Block forward: "
iptables -A FORWARD -j DROP

This allows you to see the errors in dmesg and journalctl -f or tail -f /var/log/...