Remote worker to access remote tunneled network

[Dissidente]

I am a couple of months from migrating our IPSec VPN infraestructure to Untangle, however I have a question that can be a deal breaker.

Often I have developers that access our infraestructure through VPN (IPSec client-2-site) and need to access a remote tunneled network (ie. production network or partner network, connected to our internal network through a site-2-site VPN tunnel).

Will Untangle's IPSec VPN be able to implement this?

Currently there are several profiles, given the type of worker connecting to the VPN (ie. developer, finance, marketing, etc), which determines which internal resources they can access (each profile have it's own network address pool, hence I can control access through their ip address). Can this be acomplished with Untangle also? (not seeing how...)

Thanks!

[sky-knight]

Yes, issues only pop up when there is another network beyond the tunneled network. When you setup a tunnel you specify the IP range of the remote network, that IP range is used as a route to push traffic. As long as the IP ranges you need are in the VPN module things are easy. When you have more, you have to get into the routes and get things lined up manually.

But, both Untangle's IPSec module, and OpenVPN module can do what you ask. You can additionally go the extra step of handing out VPN clients that connect directly to the remote network if you want. So you can avoid having that traffic going over the site-to-site tunnel entirely.

With IPSec / L2TP in one module, and OpenVPN in another and having both available on all my Untangle servers I have yet to run into a situation I can't resolve with a little creativity. I can't say the same for any other VPN solution on the shelf.

[Dissidente]

Thanks for your feedback sky-knight.

I mainly discarded OpenVPN for production use because of the absence of user authentication, other than the certificate. With IPSec you can at least use RADIUS and the AD connector to authenticate the user. =\

[sky-knight]

That's just discarding a nearly impossible to hack machine based certificate, which is then followed up by username / password authentication to get at a resource with a far weaker dual username / password authentication engine.

The site-to-site tunnels made by the IPSec module are more flexible too.

They are two different tools, which one to use depends on the situation and I have a handful of networks that use both. I'm not trying to steer you one way vs the other, but if you walk away from this post with anything it should be forgetting the idea that the pass-wordless authentication OpenVPN provides is "insecure" in some magic way.

[Dissidente]

For me the best remote worker access solution with would be to add AD integration with OpenVPN. However sadly Untangle doesn't support that. It's way easier to maintain the remote access of 50+ users with some user rotation (in's and out's) relying on AD for accounting (enable/disable, brute force protection, expiration dates) than to keep a local user directory in Untangle. If there was a second authentication step in OpenVPN it would be my solution of choice.

There's still something I don't really know how I will implement in Untangle's IPSec module. Currently I have several VPN profiles, according to user's department, to only allow access to needed resources (ie. marketeers don't need (usually) to access internal dev environments or databases). This is currently implemented by assigning different IP pools to remote workers using the different VPN profiles, and configuring the firewall accordingly. But in Untangle there isn't the concept of different departments, so the only way I see this working is by implementing username and group-based firewall rules to control VPN to LAN access. Am I correct?

[sky-knight]

What are you talking about? AD Integration? If you operate AD, the authentication against AD happens naturally as soon as you access a resource over the VPN tunnel. What difference does it make that Windows does that automatically in the background separately? AD provides your second factor of authentication, this is true of regardless of which VPN technology you choose to use on Untangle.

If that isn't good enough you need to be using GPO deployed SSTP anyway.

Untangle used to allow you to configure separate address pools, sadly that functionality was taken away. However, the VPN connection's "name" is a "username" in terms of the firewall rules, so you can make rules based on that.