Connect two networks with OpenVPN

Question

I am trying to connect two networks together via OpenVPN.

Gateways can ping each other, however they cannot access other computers on the network they're joining. Logs don't show any errors, and the connection is established.

What am I missing here? Seems like many are having this issue for various reasons, but after 50+ tries I gave up and decided to ask :)

Network 1:

dev tun port 1194 ifconfig 10.8.222.40 10.8.222.41 route 10.2.1.0 255.255.255.0 vpn_gateway comp-lzo keepalive 10 60 persist-key persist-tun user nobody group nobody secret /etc/openvpn/static.key

ip route default via 10.0.1.1 dev eth0 10.0.1.0/27 dev eth0 proto kernel scope link src 10.0.1.9 10.2.1.0/24 via 10.8.222.41 dev tun0 10.3.0.0/24 via 10.3.0.2 dev tun2 10.3.0.2 dev tun2 proto kernel scope link src 10.3.0.1 10.8.222.41 dev tun0 proto kernel scope link src 10.8.222.40 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1

Network 2

dev tun port 1194 remote my_ext_ip 1194 ifconfig 10.8.222.41 10.8.222.40 route 10.0.0.0 255.254.0.0 vpn_gateway comp-lzo keepalive 10 60 persist-key persist-tun user nobody group nobody secret /etc/openvpn/static.key

ip route default via 10.2.1.1 dev eth0 10.0.0.0/15 via 10.8.222.40 dev tun0 10.2.1.0/24 dev eth0 proto kernel scope link src 10.2.1.9 10.8.222.40 dev tun0 proto kernel scope link src 10.8.222.41 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1 172.27.224.0/22 dev as0t0 proto kernel scope link src 172.27.224.1 172.27.228.0/22 dev as0t1 proto kernel scope link src 172.27.228.1 172.27.232.0/22 dev as0t2 proto kernel scope link src 172.27.232.1 172.27.236.0/22 dev as0t3 proto kernel scope link src 172.27.236.1

Update:

Here's what I have iptables-wise:

Both networks: iptables -I FORWARD -i eth0 -o tun0 -m conntrack --ctstate NEW -j ACCEPT iptables -I FORWARD -i tun0 -o eth0 -m conntrack --ctstate NEW -j ACCEPT

Network 1: iptables -t nat -A POSTROUTING -s "10.0.0.0/15" -o "eth0" -j MASQUERADE iptables -A FORWARD -p tcp -s 10.0.0.0/15 -d 0.0.0.0/0 -j ACCEPT

Network 2: iptables -t nat -A POSTROUTING -s "10.2.1.0/24" -o "eth0" -j MASQUERADE iptables -A FORWARD -p tcp -s 10.2.1.0/24 -d 0.0.0.0/0 -j ACCEPT

\

Update 2:

Entering tunnel: # tcpdump -i tun0 listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 01:01:15.181262 IP ip-10-8-222-41.ec2.internal > ip-10-0-1-5.ec2.internal: ICMP echo request, id 28767, seq 1, length 64

Exiting tunnel: # tcpdump -i tun0 listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 01:03:44.304930 IP 10.8.222.41 > 10.0.1.5: ICMP echo request, id 28784, seq 1, length 64

Switching interfaces # tcpdump -i eth0 01:08:56.093291 IP 10.8.222.41 > 10.0.1.5: ICMP echo request, id 28785, seq 3, length 64

Solution

Solved!

tcpdump allowed me to see that the source of packets for iptables forwarding was 10.8.222.41/32

So adding

iptables -t nat -A POSTROUTING -s "10.8.222.41/32" -o "eth0" -j MASQUERADE iptables -A FORWARD -p tcp -s 10.8.222.41/32 -d 0.0.0.0/0 -j ACCEPT

solved the problem!

Now both gateways can ping servers in each other's network. Now I need to figure out how to permit that to all of the computers in both networks, but that's a different question...

Comments

[c4f4t0r]

ip forward in every opevpn server and iptable masquerade

[user3521621]

I have used route 10.0.0.0 255.254.0.0 vpn_gateway because one of my machines spans another network and has an IP of 10.1.0.5 (there is another VPN connection on one side of the tunnel). I have tried your suggestion, but I still can't ping local IPs of each net, and traceroute to them gives nothing either :(

[Ricardo]

then you are going to have to troubleshoot the issue with network captures. I would start with # tcpdump -i tun0 and do your pings. That will tell you if the ping is even going out the tunnel.

[user3521621]

Updated the question with tcpdump output

[Ricardo]

Your tcpdump looks good. The ping is traversing the tunnel and exiting the eth0 interface on the other end. Now it would seem as if device with IP 10.0.1.5 is not responding back via the same path. You must check and see if the routing table on 10.0.1.5 points to the eth0 for packets destined to 10.8.222.41. If they were, then you would see the return packet on your third tcpdump (eth0).

[ipeacocks]

Have you found a solution for "Now I need to figure out how to permit that to all of the computers in both networks, but that's a different question..."?