The Goal
We've got one OpenVPN Server that's up and running (10.8.0.0/16). And some clients. Clients can be separated into two specific groups: humans and non-humans. The non-humans shall only have access to the VPN server and a couple of external IP addresses through the VPN. The humans on the other hand shall have access to everything - especially to the non-humans (non-human clients have a web interface the humans shall reach).
What works
Humans and non-humans can connect to the VPN. Non-human access is successfully restricted.
The Problem
When connected with a human client, I cannot ping the non-human client nor can I reach the web interface of the non-human client.
~ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
From 10.8.0.1 icmp_seq=2 Redirect Host(New nexthop: 2.0.8.10)
From 10.8.0.1 icmp_seq=3 Redirect Host(New nexthop: 2.0.8.10)
From 10.8.0.1 icmp_seq=4 Redirect Host(New nexthop: 2.0.8.10)Configs
server.conf
local 192.168.12.152
port 1194
proto udp
dev tun0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.0.0
client-config-dir /etc/openvpn/ccd
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify
management 127.0.0.1 5555sample_client.ovpn (The Difference between humans and non-humans is made by ccd where clients get a static IP-address. Humans get a IP address from 10.8.255.0/24 and non-humans from 10.8.x.y [x != 255] - so in the ccd there is just 'ifconfig-push 10.8.y.y 255.255.0.0').
client
dev tun
proto udp
remote some-vpn-dyndns.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>[...]</ca>
<cert>[...]</cert>
<key>[...]</key>
<tls-crypt>[...]</tls-crypt>Iptable changes:
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 ! -d 10.8.0.0/16 -j SNAT --to 192.168.12.152
iptables -I INPUT -p udp --dport 1194 -j ACCEPT
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -s 10.8.0.0/16 -j DROP
iptables -I FORWARD -s 10.8.0.0/16 -d 1.1.1.1 -j ACCEPT <---for DNS
iptables -I FORWARD -s 10.8.0.0/16 -d 8.8.8.8 -j ACCEPT <---for DNS
iptables -I FORWARD -s 10.8.0.0/16 -d 213.187.93.146 -j ACCEPT <--- special (dummy) server that non-humans have to reach
iptables -I FORWARD -s 10.8.255.0/24 -j ACCEPTThis adds to this iptables -L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.8.255.0/24 0.0.0.0/0
ACCEPT all -- 10.8.0.0/16 213.187.93.146
ACCEPT all -- 10.8.0.0/16 8.8.8.8
ACCEPT all -- 10.8.0.0/16 1.1.1.1
DROP all -- 10.8.0.0/16 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 tl;dr If somebody could tell me why I'm not able to ping from a human client (10.8.255.1) a non-human client (10.8.0.2) - that would be really nice. (Everything else is working as it should)
Thanks in advance!
1 Answer
So I found a solution that kinda works.
What did I do? I changed some FORWARD rules.
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- 10.8.255.0/24 anywhere
ACCEPT all -- 10.8.0.0/16 some-dummy-server
ACCEPT all -- 10.8.0.0/16 dns.google
ACCEPT all -- 10.8.0.0/16 one.one.one.one
ACCEPT all -- one.one.one.one 10.8.0.0/16
ACCEPT all -- dns.google 10.8.0.0/16
ACCEPT all -- some-dummy-server 10.8.0.0/16
ACCEPT all -- anywhere 10.8.255.0/24 First: the default policy for FORWARD is set to DROP. Second: allowed communication to default DNS-Servers for all of my VPN-Range, allowed communication to my special dummy server. Third: I allowed communication with everything and from everything with the IP range of my human clients.
Why do I say it kinda works? Because if I ping from a human client a non human client I still get this:
~ ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=63 time=120 ms
From 10.8.0.1 icmp_seq=2 Redirect Host(New nexthop: 2.0.8.10)
64 bytes from 10.8.0.2: icmp_seq=2 ttl=63 time=132 ms
From 10.8.0.1 icmp_seq=3 Redirect Host(New nexthop: 2.0.8.10)
64 bytes from 10.8.0.2: icmp_seq=3 ttl=63 time=108 ms
From 10.8.0.1 icmp_seq=4 Redirect Host(New nexthop: 2.0.8.10)
64 bytes from 10.8.0.2: icmp_seq=4 ttl=63 time=102 msI would guess that is because of the routing table on my (human) client side:
~ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 50 0 0 tun0
default _gateway 0.0.0.0 UG 600 0 0 wlp0s20f3
10.8.0.0 0.0.0.0 255.255.0.0 U 50 0 0 tun0
ip5b426419.dyna _gateway 255.255.255.255 UGH 600 0 0 wlp0s20f3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp0s20f3
192.168.42.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp0s20f3
_gateway 0.0.0.0 255.255.255.255 UH 600 0 0 wlp0s20f3So if someone got a better idea, I'm happy to mark their answer as correct.
Ty for reading.