The Old Joel on Software Forum: Part 4 (of 5)

VPN architecture questions

(Yes, it's maybe OT. If you've got a forum or book to point me to, feel free.)

OK, I have a fair amount of development and network administration experience, but not with VPN's. I'm confused as to the network architecture of site-to-site vs. remote access VPN's. I've been combing lots of sites and books for this info, but nothing I've found seems to address it clearly.

It appears that for site-to-site VPN's, the VPN server on both sides acts as a router, and a new subnet must be set up at the remote site that makes sense given the existing network infrastructure. Is this the case?

For a remote access VPN, then, how does this work as far as routing? Does this solution rely on addresses that are in the same subnet as the VPN server itself? If so, does it proxy ARP for them or something? Something's gotta let the network know that the machines on the VPN aren't quite "there".

And then there's the issue of having both types of networks hosted by the same VPN device. In this case, then, it seems like the addresses given to remote access clients might need to be in a different subnet, but I'm not sure.

...And then there's firewall issues (difficult, but doable), and NAT issues (a big ball of yarn). Our sites all are NATed, but our remote sites will of course not be using NAT within the VPN--they'll just use part of our private address space.

Thanks for any help, and apologies if I've strayed too far off topic. As I mentioned, pointers to other forums, books, or other information sources are welcome. I sometimes wish (for various other stuff too, not just this), that I could just bend someone's ear for just 15 minutes or so--that's all I need to answer my questions!

Rich
Friday, May 28, 2004

Interesting question.

I have three branch office VPNs. Basically one to each of my hosting locations from the central office. Each is on a separate subnet. When one subnet routes to another subnet it does it via the VPN server. The VPN server tunnels the connection between the two sites. This is a logical place to put filtering rules between the VPNs.

Remote user VPNs are a scary security problem that most ignore. They blindly assume they are secure by using the VPN, when in essence they allow computers to route around the corporate firewall. They there is no way around that problem. I sometimes have nightmares about the viruses our marketing folks could introduce on the network via the remote user VPN. The thought of going directly from a free wireless network to our VPN is fairly scary. If it was up to me, I wouldn't allow it.

If you do have a remote user VPN, I would put the remote user VPN connection it's own subnet and filter access via a second firewall that routes incoming VPN connections. Actually we are going through this right now. We are trying to find Cisco admin that could apply per user ACLs when they authenticate on the VPN. As far I can tell the only way to do this is via Radius authentication. But I am a Linux/Windows hack not a Cisco admin.

christopher baus (www.baus.net)
Friday, May 28, 2004

Yes, I share your concerns with the remote user problem. Such an approach requires strict control over the configuration of the machines allowed to connect--but, such control is probably not common as far as I can tell.

re: per-user ACLs: I do a bit of everything, including Cisco, and it seems to me as well that Radius is your best bet there.

Rich
Friday, May 28, 2004

For remote access, you would do well to look at "clientless VPN" (see Aventail, Juniper -- nee Neoteris, Symantec, etc.).

Must more secure than an IPsec VPN because (a) you're supporting a limited set of protocols like HTTP(S) inside the network; and (b) you can enforce destination control down to the server and URI level.

Surf the intranet like you were outside but selectively lock down everything else...

dir at badblue com
Friday, May 28, 2004

You seem to have a pretty good grasp of everything.

"It appears that for site-to-site VPN's, the VPN server on both sides acts as a router, and a new subnet must be set up at the remote site that makes sense given the existing network infrastructure. Is this the case?"

Generally speaking, yes. This is how it's done. If you have 192.168.1.x on one side and 192.168.2.x on the other, then the VPN server on the 1.x side is designed as the router for all 2.x hosts, and the traffic goes over the VPN.

"For a remote access VPN, then, how does this work as far as routing? Does this solution rely on addresses that are in the same subnet as the VPN server itself?"

Again, generally speaking, yes it does, because that's the simplest solution. The VPN server in W2K3's Routing and Remote Access (and farther back, I'm sure) can assign remote access VPN connections an IP address from a pre-determined block, or also from the local DHCP server on the LAN. For all intents and purposes, a remote access VPN machine appears to be part of the physical LAN as far as routing is concerned.

"If so, does it proxy ARP for them or something?"

Exactly right. It uses Proxy ARP.

"And then there's the issue of having both types of networks hosted by the same VPN device."

That's not really all the confusing, because they're two different operations, really. It knows based on "who's calling in" (i.e., what username they use) what type of VPN connection they have (subnet or remote access), and does the right thing based on who it is.

"In this case, then, it seems like the addresses given to remote access clients might need to be in a different subnet, but I'm not sure."

Nope, it can both route and do Proxy ARP at the same time. The two operations are not mutually exclusive.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, May 28, 2004

hello

john
Saturday, May 29, 2004