[SOLVED] VPN to join two VPCs (Amazon virtual private clouds

murrayk

Hi all,

I've setup an OpenVPN p2p tunnel between two hosts in separate Amazon VPCs (UK - 10.24.0.0 and US - 10.24.1.0). The VPN itself works well and I can ping hosts on the remote network from each end of the VPN tunnel. However, other hosts on the network are unable to access the remote network via the VPN.

I've told the VPC router to send traffic for 10.24.0.0/27 via 10.24.1.25, and traffic for 10.24.1.0/27 via 10.24.0.11

#10.24.1.25

cat server.openvpn.conf
port 1194
proto udp
dev tun0
ifconfig 172.16.0.1 172.16.0.2
secret ovpn.key
push "route 10.24.0.0 255.255.255.224"
route 10.24.1.0 255.255.255.224
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user nobody
group nobody
daemon

#10.24.0.11

cat client.openvpn.conf
remote 46.51.193.80 1194
dev tun0
proto udp
#ifconfig 10.24.1.15 10.24.0.15
ifconfig 172.16.0.2 172.16.0.1
secret ovpn.key
route 10.24.0.0 255.255.255.224
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user nobody
group nobody
daemon

It doesn't seem to work with static routes either. TCPdump shows no traffic on the listening interface of the VPN router. IP forwarding is enabled, as is postrouting, and firewalls have been disabled. Are there any specific Amazon quirks to be aware of?

Thanks,

janjust

your setup looks OK (although you don't need the "push" statement) .
this should work even in an Amazon setup, and as you can reach the VPN endpoints the VPN itself seems to be in order.
The rest is down to routing (as always). From the VPN endpoint at one end, can you
* ping the remote endpoint (just checking 😉)
* ping the LAN IP of the remote endpoint
* ping the LAN IP of a host on the other side

remember that you now have not olnly the 10.24 networks, but also the 172.16.0.1 network: this IP is used as the source address when pinging from either remote endpoint.

Are you masqueradering at all on either end?

murrayk

Thanks for your reply Jan,

Yes I can do all of those things

[root@fvirl4-01]# ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=0.038 ms

--- 172.16.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.035/0.036/0.038/0.006 ms
[root@fvirl4-01]# ping 10.24.0.11
PING 10.24.0.11 (10.24.0.11) 56(84) bytes of data.
64 bytes from 10.24.0.11: icmp_seq=1 ttl=64 time=97.6 ms
64 bytes from 10.24.0.11: icmp_seq=2 ttl=64 time=97.6 ms

--- 10.24.0.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 97.647/97.663/97.679/0.016 ms
[root@fvirl4-01]# ping 10.24.0.10
PING 10.24.0.10 (10.24.0.10) 56(84) bytes of data.
64 bytes from 10.24.0.10: icmp_seq=1 ttl=63 time=98.0 ms
64 bytes from 10.24.0.10: icmp_seq=2 ttl=63 time=98.3 ms

--- 10.24.0.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 98.099/98.232/98.365/0.133 ms
[root@fvirl4-01 glusterfs]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 02:6D:90:F8:58:F0
          inet addr:10.24.1.25  Bcast:10.24.1.31  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:359907 errors:0 dropped:0 overruns:0 frame:0
          TX packets:272466 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44890158 (42.8 MiB)  TX bytes:52328813 (49.9 MiB)

[root@fvirl4-01]# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.16.0.2  P-t-P:172.16.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:180 errors:0 dropped:0 overruns:0 frame:0
          TX packets:209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:15148 (14.7 KiB)  TX bytes:16096 (15.7 KiB)

[root@fvirl4-01]#

I did setup masquerading on both ends with the below line, perhaps is this where the trouble is?

iptables -t nat -A POSTROUTING -s 172.16.0.1/16 -o eth0 -j MASQUERADE

Thanks again 🙂

murrayk

OK, so I've done a bit more testing.

It seems that Amazon VPCs drop cross subnet traffic. (at least, how ours is setup).

We created a second openVPN tunnel between 1.26 and 1.25.

Then I was able to ping hosts 0.10 and 0.11 from 1.26 (via two openVPN tunnels!).

[root@new-server openvpn]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 02:6D:90:EA:FB:82
          inet addr:10.24.1.26  Bcast:10.24.1.31  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5398 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2309 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4843286 (4.6 MiB)  TX bytes:331779 (324.0 KiB)

[root@new-server openvpn]# traceroute 10.24.0.10
traceroute to 10.24.0.10 (10.24.0.10), 30 hops max, 40 byte packets
 1  172.17.0.1 (172.17.0.1)  3.100 ms  3.059 ms  3.051 ms
 2  172.16.0.1 (172.16.0.1)  105.488 ms  105.507 ms  105.498 ms
 3  10.24.0.10 (10.24.0.10)  105.649 ms  106.299 ms  106.295 ms

janjust

this masquerading rule

iptables -t nat -A POSTROUTING -s 172.16.0.1/16 -o eth0 -j MASQUERADE

only matches the host 172.16.0.1, not the entire subnet

the fact that you can ping a host on the LAN on the other side:

[root@fvirl4-01]# ping 10.24.0.10
PING 10.24.0.10 (10.24.0.10) 56(84) bytes of data.
64 bytes from 10.24.0.10: icmp_seq=1 ttl=63 time=98.0 ms
64 bytes from 10.24.0.10: icmp_seq=2 ttl=63 time=98.3 ms

proves that routing is working to some extent. is ip forwarding enabled on both vpn endpoints (cat /proc/sys/net/ipv4/ip_forward) ?

murrayk

Yes, IP forwarding is enabled on both VPN endpoints.

10.24.1.25 has the following masquerading rules:

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.16.0.0/16        anywhere

and 10.24.0.11

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.16.0.0/16        anywhere

If I understand correctly, the masquerading is only required so that packets bound for the foreign 10.24/1-0.0/27 network can traverse the openVPN endpoint IPs on the 172.16.0.0/16 network.

The thing is, this works when we create a VPN tunnel from 10.24.1.0/27 IPs to 10.24.1.25. Then they successfully hop through 2 VPNs to access the opposite network. Which makes me think Amazon is doing something funny with our packets destined for a foreign network (and yes, we have configured the VPC router to route 10.24.1-0.0/27 to the correct VPN endpoint.

I guess we'll approach Amazon next.

Thanks again for your help.

murrayk

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

janjust

Excellent! thanks for posting the solution. Closing topic.