OpenVPN Open Beta

[Guest]

I'm excited about the new VPN! Would this version of the OpenVPN AS server support Chromebooks?

I've looked online a bit but can't find anything that says Chromebooks support OpenVPN AS.

[pmbell]

(in response to Joss)

1) Was I correct in my assumption that once the VPN was turned on, the router would not allow any traffic that did not use the VPN tunnels? My original thought was that the router would take that unencrypted, incoming traffic and pass it on as is. Apparently not.

I have not seen your configuration, so I can't be sure, but my guess is that once you connected to the Sonic VPN, you accepted their VPN as a default route. The fact that you were able to keep the dyndns pointer accurate even after routing had (probably) gotten jacked up is interesting, though. Usually, if dyndns is able to work from a host, both the inbound and outbound routes are working correctly.

That's going to break a lot of things if you need to access a server on that network.

I don't know your router, but is there an option to write a rule that says
"if a packet comes from 192.168.100.4, assign it ATT as its default gateway" and another that says "if a packet reaches ATT headed for my.dyndns.address, always pass it on to 192.168.100.4"

If so, you should not need a second router.

You can confirm by, wth the Sonic VPN connected, firing off the dyndns client from your server and seeing if it picks up your ATT address or the Sonic vpn address.

2) Why could I access the server through its external address, even though I had the VPN turned on? One of my friends posited that my router saw the IP address I was requesting, recognized the address as its own address and just kept the whole transaction internal.

A lot of things have various ways of doing just that automatically. A default route will almost always lose to a connected route, so the traffic is unlikely to be passed to the VPN tunnel if your setup knows everything is on the LAN. I'm not sure how much delay is built into the dyndns update system. I know that I needed to go find all the hosts dyndns uses and write rules to send their traffic out over ATT and not the VPN in order to have my lookup for local machines get sent in over ATT.

3) Did I handle this the best way?

You used a beta service on a production network that includes an element of income security for you on it.
Also, you tested firewall functionality from inside a firewall and trusted the results.

I am willing to bet that you learned a lot from this, though, and are unlikely to make either mistake again without being keenly aware that you are doing so, and probably enlisting someone to test for you, or going to another site to test for yourself.

Were it me, I'd ditch the second router and try seeing if it is possible to do all the routing all on your main gateway. It's much simpler not to have to chase routing problems across multiple routers.

I don't know if either of these will work with your gear, but they were helpful to me to figure out:

The default gateway does not have to have a default route tied to it.

The ATT-facing interface does not have to be the default gateway. On my network, the "WAN" interface has nothing at all crossconnected to it. This gives me much better control over my routes.

My default gateway is the VPN handoff - when it is up.

When it goes down, I have static routes to a work network and to Google's DNS that always run over ATT. The internet breaks as far as web browsing goes, though, and I'm OK with that.

[joss]

(in response to Joss)
...
The fact that you were able to keep the dyndns pointer accurate even after routing had (probably) gotten jacked up is interesting, though. Usually, if dyndns is able to work from a host, both the inbound and outbound routes are working correctly.
...

Thanks for the reply and sticking with my rambling narration. About the above in your reply: The router opens the VPN but keeps the AT&T address as its gateway to the internet, over which it layers the VPN tunnel. The router is the entity updating DYNDNS with any address changes, so it reports its gateway address to DYNDNS. That is why I didn't lose the address.

However, you are correct. Once I removed the pinhole (on subnet '2') on the router, it had an internal address. So I had to move the pinhole to the other router. During my interim testing of the two routers the one controlling subnet '2' updated the DYNDNS address to 192.168.2.195. Not very useful.

[Guest]

The Edgerouter's Cavium chip does IPSEC in hardware, so we're working on an IPSEC VPN solution which will be more appropriate than OpenVPN for that equipment. FYI!

This is great! Thank you for considering those whose routers/firewalls only support IPsec.

[Guest]

That's great. the ERLite is so cheap that it'd be something you could distribute for customers who want the device and they shouldn't be as unhappy about paying for it and some maintenance as they would a lot of other platforms.

Would you recommend someone use an ERLite in addition to another device that supports IPsec? I was just thinking of setting up my SSG and be done with it.

[pmbell]

The router opens the VPN but keeps the AT&T address as its gateway to the internet, over which it layers the VPN tunnel.

This relates to the point I was making about the separating the in actual fact WAN and/or default routes from the port your router thinks is the WAN. Many routers will apply default routing rules to the WAN interface come hell or high water, which they won't apply to an arbitrary interface which you've designated as the one that is your best route to a few hosts of your choice.

That leaves your openVPN tunnel able to very reliably spin back up and be the default route - since there was no default route before it came up again.

My goal is that my "fun" internet connection fails closed if the tunnel goes down - parts of the connection don't depend on VPN, and I can still ping Google's nameserver and get replies from it over the ATT link, but most things stop working outright.

Fail closed is not a design goal for many folks, though, and is a pain at times. Me, I dislike Dish/ATT enough that I'd rather fail closed than let them watch.

[pmbell]

That's great. the ERLite is so cheap that it'd be something you could distribute for customers who want the device and they shouldn't be as unhappy about paying for it and some maintenance as they would a lot of other platforms.

Would you recommend someone use an ERLite in addition to another device that supports IPsec? I was just thinking of setting up my SSG and be done with it.

It does not have the visibility or easy to configure outbound granularity that a firewall has, and definitely doesn't have the support level that Cisco or Juniper provide.

You could drop the ERLite in line in front of a competent firewall and then use the ERLite solely to run very fast IPSEC calculations.

Assuming you already own that SSG, it's a way of avoiding rewriting a lot of rules. It seems like one extra device to me in a lot of ways, though - I would much rather have firewalling with visibility and 1/4 speed than have full speed and poor firewalling and visibility into what was happening.

[rtrinh]

I wrote the above for anyone who hasn't installed openvpn yet.

Cool thanks. Comparing your settings to mine, I had nsCertType verification unchecked and was using blowfish cipher before kgc changed it on the 23rd. I'll turn give it another test later tonight with the cipher change to AES 128 and test on another Netgear router to see if I am hardware limited.

[kgc]

I just ordered a SG-2220 to test.

[elmatador]

Just wondering. Does the sonic vpn have a 24 hour lease time? Seems like I have to reboot the router ever 24 hours otherwise I lose connection.