Access a subnet behind an openvpn server

I have an Ubuntu OpenVPN server set up. Everything works just fine, VPN clients can successfully connect to the VPN server. Challenge is that I cannot connect to the computers behind the VPN server

tcp dump on tun0 root@gtway-sr-s:~# tcpdump -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
15:10:45.785732 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48841, length 40
15:10:50.469529 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48850, length 40

And this is for em2 [192.168.33.2]

root@gtway-sr-s:~# tcpdump -i em2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
15:15:15.460870 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:15.461025 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:15.464351 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49287, length 40
15:15:15.464544 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49287, length 40
15:15:16.187506 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:20.448006 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49296, length 40
15:15:20.448207 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49296, length 40
15:15:21.491924 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:25.450927 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49304, length 40
15:15:25.451132 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49304, length 40
15:15:26.823644 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:30.459822 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49315, length 40
15:15:30.460016 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49315, length 40
15:15:32.148672 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:35.143425 ARP, Request who-has 192.168.33.1 (b0:83:fe:e3:2e:1a (oui Unknown)) tell 192.168.33.2, length 46
15:15:35.143431 ARP, Reply 192.168.33.1 is-at b0:83:fe:e3:2e:1a (oui Unknown), length 28
15:15:35.453679 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49324, length 40
15:15:35.453861 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49324, length 40
15:15:37.485259 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:40.455035 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49333, length 40
15:15:40.455220 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49333, length 40
15:15:40.468865 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:40.469000 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:42.827137 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:45.461731 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49343, length 40
15:15:45.461919 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49343, length 40

Solution 1:

Modify the server configuration file to include a line like the following:

  push "route 192.168.73.0 255.255.255.0"

where 192.168.73.0/24 is the LAN behind the server. Replace with whatever you use. Double quotes must be kept, not discarded.

NOTICE:

The above will fail if the LAN behind the server and the LAN to which the client belongs overlap to some extent, and especially if they use the same subnet: in the example above, it would fail if both client LAN and server LAN were 192.168.73.0/255. This is a problem because most automatically-setup LANs are either 192.168.1.0/24 or 192.168.0.0/24, so that there are many chances of finding a collision.

This is the reason why I setup my home's LAN as 192.168.73.0/24. Switching LAN to an unusual subnet is the only remedy possible for such a collision.

EDIT:

In reply to your comment:

1. the collision is not between the LAN behind the server and the IP numbers dished out to the openvpn clients, but between the two LANs: your client must have, on its ethernet/wifi interface, an IP number which must not collide with the remote LAN. Forget about the subnet for the openvpn clients.

2. Once the above has been configured, one thing that remains to check is whether the server can transfer packets from the virtual interface (I am ready to bet it is tun0 in your case, not tap0, am I right) to the server's normal interface (I bet it is eth0, not br0). This may happen for two reasons:

   a. you did not allow IPv4 forwarding. As sudo,

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

   will take care of this.

   b. You have a firewall which blocks packet forwarding.

   sudo iptables -F 
   

   will clear your firewall rules.

3. Lastly, you should remember to use MASQUERADE, as follows:

      iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.33.0/24 -j MASQUERADE