Connecting two Sites/Subnets, I'm halfway done

LeoSum

Hi there,
I am trying to achieve a pretty common task, but maybe with not so common hardware. There are several similar topics around here but none could help me fully achieve my goal.

I would like to connect two networks via OpenVPN, so that all clients on both sides can reach each other.

Network 1 is subnet 192.168.178.0, where the OpenVPN Server is installed on a synology diskstation with the local IP 192.168.178.64.

At the second location the subnet is 192.168.179.0, where an OpenVPN client is running on a FreeNAS device with the local IP 192.168.179.48.

The OpenVPN Subnet is 10.8.176.0, the OpenVPN Server has the IP 10.8.176.1, the client is 10.8.176.10.

So far the Server and the client can ping each other via the OpenVPN IPs and I also managed to configure the client in a way that all members of the client's subnet (192.168.179.0) can reach any clients on the Server's subnet.

The last open task is now to enable members of the servers subnet to reach members of the client's subnet. I think there is something wrong with my configured routes and/or iptables on the server. I would be glad if someone could look over my configs:

Server Side
OpenVPN Config:

dev tun

management 127.0.0.1 1195

server 10.8.176.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh1024.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5
persist-tun
persist-key
verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
client-config-dir ccd
client-to-client
route 192.168.179.0 255.255.255.0 10.8.176.10
topology subnet

ccd file for client:

ifconfig-push 10.8.176.10 255.255.255.0
iroute 192.168.179.0 255.255.255.0

Server routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.176.10     *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
10.8.176.0      *               255.255.255.0   U     0      0        0 tun0
192.168.179.0   10.8.176.10     255.255.255.0   UG    0      0        0 tun0
192.168.179.0   *               255.255.255.0   U     0      0        0 tun0
default         fritz.box       0.0.0.0         UG    0      0        0 eth0

Iptables:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Client Side
OpenVPN Config:

dev tun
tls-client
remote some.dyndns.address 1194
pull
proto udp
port 1194
script-security 2
route-up /usr/home/attic/vpn/up.sh
ca /location/of/certificate
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
resolv-retry infinite
reneg-sec 0
auth-user-pass /location/of/pwfile

up.sh script to set firewall rules correctly:

#!/bin/sh
sleep 2
TUN=$(/sbin/ifconfig -l | tr " " "\n" | /usr/bin/grep tun)
/sbin/ipfw -q -f flush
/sbin/ipfw -q nat 1 config if ${TUN}
/sbin/ipfw -q add nat 1 all from 192.168.179.0/24 to 192.168.178.0/24 out via ${TUN}
/sbin/ipfw -q add nat 1 all from any to any in via ${TUN}

Does anybody have clue what I am missing here?

Traffic

Please see the HOWTO:
HOWTO: Expanding the scope of the VPN to include additional machines

A quick review points to this:

LeoSum wroteIptables:
Code:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

This is probably wrong .. try this:

iptables -t nat -A POSTROUTING -s 10.8.176.0/24 -o eth0 -j MASQUERADE

both ends .. (where eth0 is your LAN device)

Pippin

If you keep your DS the way it is now then it could be done this way:
On LAN-clients at the server side you could set a route on every machine, for Windows looks like this:

route -n add -net 10.8.176.0 255.255.255.0 192.168.178.x

Where 192.168.178.x is LAN-IP of your Windows machine.

Pippin

Ah, above is for OSX, :roll:

LeoSum

Traffic wroteA quick review points to this:
LeoSum wroteIptables:
Code:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
This is probably wrong .. try this:
iptables -t nat -A POSTROUTING -s 10.8.176.0/24 -o eth0 -j MASQUERADE
both ends .. (where eth0 is your LAN device)

Thank you for your answer. I tried your suggestion last night but it didn't work out either.
Am I correctly assuming that the setting

iptables -t nat -A POSTROUTING -j MASQUERADE

would include both the two settings

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.176.0/24 -o eth0 -j MASQUERADE

as masquerading is done for all traffic in the first example?

Pippin wroteIf you keep your DS the way it is now then it could be done this way:
On LAN-clients at the server side you could set a route on every machine, for Windows looks like this:
route -n add -net 10.8.176.0 255.255.255.0 192.168.178.x
Where 192.168.178.x is LAN-IP of your Windows machine.

This is not an option, as I can't freely configure all clients. But I think this is already taken care of by a default route on the default gateway (fritz.box) pointing for the affected subnets to the local OpenVPN gateway.

Traffic

Try:

 -t nat -A POSTROUTING -s 192.168.17[x].0/24  -o tun0 -j MASQUERADE
 -t nat -A POSTROUTING -s 10.8.176.0/24       -o eth0 -j MASQUERADE

on the appropriate gateways.

LeoSum

Thank you for your continuing support and sorry for my infrequent feedback.

I have tried to set the masquerading settings like you proposed, but it is still not working.

When I set masquerading on the eth device of the client machine, I even locked myself out of it.
On the server it just didn't have any effect. I could still ping the client via 10.8.176.x but not 192.168.179.x.

If i run tcpdump on the client while it is pinged from the server, I don't see any inbound traffic when it is pinged via 192.168.179.x.
Can I assume that the settings on the client are ok and that the problem is with the server? How can I further narrow down the scope here?

LeoSum

I have done some further investigating with tcpdump.

Pinging the clients VPN IP from the Server:

#Server# ping 10.8.176.10
PING 10.8.176.10 (10.8.176.10): 56 data bytes
64 bytes from 10.8.176.10: seq=0 ttl=64 time=40.479 ms
64 bytes from 10.8.176.10: seq=1 ttl=64 time=36.639 ms
64 bytes from 10.8.176.10: seq=2 ttl=64 time=38.457 ms
64 bytes from 10.8.176.10: seq=3 ttl=64 time=36.942 ms
64 bytes from 10.8.176.10: seq=4 ttl=64 time=35.444 ms
^C
--- 10.8.176.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 35.444/37.592/40.479 ms

#Server# tcpdump -i tun0 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:59:19.854100 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 0, length 64
19:59:19.894164 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 0, length 64
19:59:20.857988 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 1, length 64
19:59:20.894369 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 1, length 64
19:59:21.868013 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 2, length 64
19:59:21.906226 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 2, length 64
19:59:22.877969 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 3, length 64
19:59:22.914671 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 3, length 64
19:59:23.888117 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 4, length 64
19:59:23.923322 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 4, length 64
^C
10 packets captured
11 packets received by filter
0 packets dropped by kernel

#Client# tcpdump -i tun2 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun2, link-type NULL (BSD loopback), capture size 65535 bytes
19:59:19.873469 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 0, length 64
19:59:19.873490 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 0, length 64
19:59:20.873142 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 1, length 64
19:59:20.873161 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 1, length 64
19:59:21.883108 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 2, length 64
19:59:21.883127 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 2, length 64
19:59:22.893108 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 3, length 64
19:59:22.893128 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 3, length 64
19:59:23.903204 IP 10.8.176.1 > 10.8.176.10: ICMP echo request, id 11887, seq 4, length 64
19:59:23.903224 IP 10.8.176.10 > 10.8.176.1: ICMP echo reply, id 11887, seq 4, length 64
^C
10 packets captured
49 packets received by filter
0 packets dropped by kernel

Pinging the clients local IP from the Server:

#Server# ping 192.168.179.49
PING 192.168.179.49 (192.168.179.49): 56 data bytes
^C
--- 192.168.179.49 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

#Server# tcpdump -i tun0 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
20:02:27.754639 IP 10.8.176.1 > 192.168.179.49: ICMP echo request, id 41071, seq 0, length 64
20:02:28.758535 IP 10.8.176.1 > 192.168.179.49: ICMP echo request, id 41071, seq 1, length 64
20:02:29.768442 IP 10.8.176.1 > 192.168.179.49: ICMP echo request, id 41071, seq 2, length 64
20:02:30.778558 IP 10.8.176.1 > 192.168.179.49: ICMP echo request, id 41071, seq 3, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

#Client# tcpdump -i tun2 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun2, link-type NULL (BSD loopback), capture size 65535 bytes
^C
0 packets captured
19 packets received by filter
0 packets dropped by kernel

I noticed that if i remove the following route on the server, I don't even see any packets on the servers tun0 device:

route del -net 192.168.179.0 netmask 255.255.255.0 gw 10.8.176.10 dev tun0

However I see the packets as shown above if I set either one of the following routes:

route add -net 192.168.179.0 netmask 255.255.255.0 gw 10.8.176.1 dev tun0
route add -net 192.168.179.0 netmask 255.255.255.0 gw 10.8.176.10 dev tun0

Hence I am not sure, which one is correct. Does it need to point to the client or the server?

A sucessful ping from the clients network looks like this:

#PConClientNet# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=62 time=46.8 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=62 time=37.7 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=62 time=38.0 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=62 time=37.1 ms
^C
--- 192.168.178.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 37.143/39.923/46.816/3.994 ms

#Client# tcpdump -i tun2 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun2, link-type NULL (BSD loopback), capture size 65535 bytes
21:12:19.614323 IP 10.8.176.10 > 192.168.178.1: ICMP echo request, id 65495, seq 1, length 64
21:12:19.660698 IP 192.168.178.1 > 10.8.176.10: ICMP echo reply, id 65495, seq 1, length 64
21:12:20.616381 IP 10.8.176.10 > 192.168.178.1: ICMP echo request, id 65495, seq 2, length 64
21:12:20.653595 IP 192.168.178.1 > 10.8.176.10: ICMP echo reply, id 65495, seq 2, length 64
21:12:21.618289 IP 10.8.176.10 > 192.168.178.1: ICMP echo request, id 65495, seq 3, length 64
21:12:21.655815 IP 192.168.178.1 > 10.8.176.10: ICMP echo reply, id 65495, seq 3, length 64
21:12:22.619498 IP 10.8.176.10 > 192.168.178.1: ICMP echo request, id 65495, seq 4, length 64
21:12:22.656127 IP 192.168.178.1 > 10.8.176.10: ICMP echo reply, id 65495, seq 4, length 64
^C
8 packets captured
35 packets received by filter
0 packets dropped by kernel

#Server# tcpdump -i tun0 port not 42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
21:12:19.637454 IP 10.8.176.10 > fritz.box: ICMP echo request, id 65495, seq 1, length 64
21:12:19.637797 IP fritz.box > 10.8.176.10: ICMP echo reply, id 65495, seq 1, length 64
21:12:20.639194 IP 10.8.176.10 > fritz.box: ICMP echo request, id 65495, seq 2, length 64
21:12:20.639530 IP fritz.box > 10.8.176.10: ICMP echo reply, id 65495, seq 2, length 64
21:12:21.641769 IP 10.8.176.10 > fritz.box: ICMP echo request, id 65495, seq 3, length 64
21:12:21.642122 IP fritz.box > 10.8.176.10: ICMP echo reply, id 65495, seq 3, length 64
21:12:22.641092 IP 10.8.176.10 > fritz.box: ICMP echo request, id 65495, seq 4, length 64
21:12:22.641430 IP fritz.box > 10.8.176.10: ICMP echo reply, id 65495, seq 4, length 64
^C
8 packets captured
9 packets received by filter
0 packets dropped by kernel

LeoSum

I finally figured out the problem.

It is in the second to last line of my server's config file. "route" only takes two arguments and should therefore read:

route 192.168.179.0 255.255.255.0

The gateway's does not go there but is implicitly read from the client file in the ccd folder.

I'm relieved that it's all logical in the end, I was beginning to loose faith 🙂

Thank you for your help!

Traffic

Well done and thanks for letting us know your solution 8-)