On Thursday evening we finally were able to get connected to Tonse. We needed a public IP address so that people at the site in Area 18 an connect to our OpenVPN server. It was a long, tiring, journey to get that to work. At first, their modem / customer premise equipment (which is made by Greenpacket) was using NAT and acting as a router.image

This complicated things, because our Cisco router also does NAT for our internal addresses, 10.10.13.10. We were originally attempting to use a DMZ setup, where the Tonse modem did NAT, but the outside IP of our Cisco router was in a DMZ so all traffic would go to it. This didn’t seem to actually work. To try to see where the problem was, we put a switch in between our Cisco router and the Tonse modem. When we opened the ports for OpenVPN on our Cisco router we were able to access it from the switch in between the modem and the router. However, even when putting the Cisco router in the DMZ for the Tonse modem, we weren’t able to access the VPN from outside of the Tonse modem.

Eventually we were able to enabled bridging mode on Tonse’s modem, so our Cisco router directly had a public 41.x.y.z IP address. This would make it much easier for the users at Area 18 to access our VPN server. NAT is only being done once.

image

There was still one caveat though. The router wasn’t routing the VPN traffic back out the interface to Tonse. I connected my laptop to the Tonse connection, and strangely enough, the default gateway my laptop received was not on the same subnet as the laptop itself. My laptop received an IP address on a 41.x.y.z subnet, however, the default gateway was a private 10.a.b.c IP. That still does not make much sense to me, but apparently it works. The router wasn’t able to get to ping that IP address. So I ended up adding a static route on the Cisco router, telling it to send traffic to the 10.a.b.c IP address through the Tonse interface. This allowed everything to work.

I also moved the OpenVPN service from our primary mail server to the backup mail server. At first it didn’t work, which was frustrating, as the configuration was identical. Then I realized that that I forgot to enable IP forwarding on the Linux server. After fixing that, it worked fine.

Michael went to Area 18 the next day, and they were able to connect to the VPN. It seemed to be a fair amount faster than it was when the connection was going through the Ariave satellite link. The latency from Michael’s house (also on Tonse, but on a different tower) seems to be greater than it is from Area 18.