Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VPN suggestions? 1

Status
Not open for further replies.

davidmulcair

Programmer
Jun 26, 2001
35
0
0
CA
Hi there,

Our company is looking into setting up a VPN to connect branch offices. I've been looking into several products, and wanted to know what everyone thought was a superior (mainstream) hardware or software product. The branch offices are very small (<10 systems).

Thanks.

David
 
You read my post in the NT forums?
For other posters...I've already suggested Checkpoint for software, and PIX for hardware.
On another note,
The PIX will probably fit your needs especially with the small offices. They have all type of models from big to small. Checkpoint can get rather expensive too, not to mention the fact that you'd need to buy a new server just to run it.
Checkpoint does have other hardware appliances to run it, but if you're going hardware, might as well go with PIX. ________________________________________
Check out
 
I'd say go with PIX if you want something good or NetScreen if you want something cheap

I've done both for customers & they both work well in the appropriate environment. ------------
Bill
Consultant / Network Engineer
CNE, CCNA
 
We have been using SonicWall's SOHO3 for over a year now and it works great. We have over 30 machines behind the firewall, and have connected with several outside VPN tunnels at once. We are going to get a second device for one of our remotes to establish a WAN.

As I am a relative neophyte to Routers and VPN, I couldn't tell you the differences between this and the PIX, nor recomend one over the other. Just my experience with the SonicWall is all I can offer. The cost is less than half of the PIX. We just upgraded to the 50 Node license and all updates and configurations have been simple and straightforward with a really easy to understand GUI.
 
I have 6 field offices that we use a Cisco IOS based VPN solution. Driving force behind this solution for us was the money that we were dropping on a point-to-point T1 from DFW to Miami. We dropped that and setup an IOS based VPN solution using 3DES. We are routing IP/IPX over the tunnel, it's a little slow at times but it gets the job for us. david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*
 
Our company used Sonicwall to set up a firewall-to-firewall VPN. It was relatively inexpensive and very easy to install. The interface is browser-based and you can monitor and maintain your remote firewalls from the central office.
 
What do you guys think of using GNAT-Box Pro for this type of application... Effectively a software only application...
 
If you're looking for a firewall on a floppy solution, there's tons of free ones out there.

leaf.sourceforge.net
(on a CD)

Or my favorite...
(hardened linux os that boots off CD; its configurable via browser)
Its free for the home version, and I've set up VPNs with this with no problem at all. The home version allows for 10 internal IP's, but the purchase product does a lot more, and is pretty cheap. ________________________________________
Check out
 
We only tried a few software firewalls, and they sucked. I can't vouch for the above software, just stick with freeware, shareware or trial versions before you purchase something - to make sure it works for your applications before dumping $300+ dollars into software - like we did - and coming up with no working solutions.
 
Nortel?
You mean they haven't filed chapter 11 yet?



Sorry. I couldn't resist it. Flame away ------------
Bill
Consultant / Network Engineer
CNE, CCNA
 
Okay, I've looked a little deeper, checking out the Netgear, Sonicwall applications, looked at Symantec, but it had some very disfavorable reviews...

In terms of tunnel requirements for a branch office situation, am I only going to need one VPN tunnel? In essence a tunnel shared by ~10 users?

David
 
Someone (everyone) feel free to correct me if I am wrong....

It's not really a &quot;tunnel&quot; per se or even shared, but more like point-to-point data encapsulation. Each user would generate their own &quot;tunnel&quot;. What is shared is the internet connection point. I know Sonicwall has multi-tier licensing as to how many concurrent VPN tunnels can be active.
 
Within the last few months, I've set up firewalls for different locations using LinkSys firewall + VPN products. The reason I went with LinkSys was cost; buying upgrades for our current SonicWalls + adding a remote SonicWall w/VPN would have cost over a thousand dollars. In contrast, LinkSys BEFSX41's are $80 per device. I've worked with SonicWalls, and while I agree that they are a superior vendor with a very good product, keep in mind that in a couple of years, we're going to see VPN over SSL (SonicWall's on that bandwagon). It's something to think about.

So I'm going to make an assumption, and just in case it's wrong, I'm going to try to discuss how you'd do it briefly. My assumption is that you have a &quot;main office&quot; with a &quot;main network&quot;, and each branch office will &quot;log in&quot; or &quot;participate&quot; in the &quot;main network&quot;, as if they were onsite, and each branch has an Internet connection running on 10/100BT (Ethernet). Furthermore, collections of machines at each location are in the same &quot;subnet&quot; (Remote Office 1: 192.168.x.x, Office2: 192.168.x.x, 10.x.x.x, etc). It's not necessary for every subnet to be the same, just every machine behind a particular tunnel endpoint, if it's going to communicate through the tunnel. I'm ignoring server / domain / OS for now.

BEFSX41 (2 tunnels PER device - $80)

BEFVP41 (70 tunnels PER device - $97-$125)

-- A real plug for hardware vs. software VPNs is that the performance hit for multiple highly encrypted tunnels just doesn't seem to be a factor here.

If you have more than two external offices (or will in the near future), you'd get a BEFVP41 at the main office. You probably wouldn't need VP41's remotely, but you could do this if you wanted setup consistency (device setup is slightly different).

Assuming you get two, you'll need two machines, some cables, and a hub (if you want to look at WAN traffic). Connect a machine each to one LAN port on each router. Consider one on the &quot;main&quot; network, and the other on the &quot;remote&quot; network. Strap the router WAN ports together (through a hub if you want to clip a third machine in to monitor WAN traffic -- Ethereal (.com) is a freeware protocol analyzer), then configure each machine's IP address as you would normally do. On both machines, set up a repeating PING (PING -t OtherMachineIP) - they'll timeout at first, but they'll help you see that your tunnel is alive. You'll have to assign addresses to the routers (use fake ones, and the router as its own gateway, e.g., 10.0.0.1 and 10.0.0.2 since there isn't a real Internet connection) and set up your tunnel. If you read the setup screens carefully, you won't have any trouble getting a tunnel working. Once set up, you'll have to apply everything as it will be for production.

Finally, I have experience with this and am happy to help if you go this route. Some parting notes: If you have to put a LinkSys behind another firewall, you'll need to open port 500 (forwarding/masquerading) from the external firewall to the LinkSys. If you are authenticating with servers over the tunnel, and are using Windows 2000 or greater, you'll have to force Kerberos to use TCP instead of UDP, or allow fragmented UDP. You'll have to enable WAN requests for debugging. I suggest using Perfect Forward Secrecy, and setting up &quot;out of band&quot; (i.e., dialup) remote control software somewhere so you can configure the router remotely. You'll also need to ensure that during final setup, you have a ROUTE BACK from the main office - if you monitor the WAN traffic, you'll see that the ping goes out, and all the way into the LAN, but it never comes back; you'll have to configure a route back to the remote network, on the default gateway for all machines, via the LinkSys gateway. Additionally, depending on the way IP addresses are obtained, you may have to get assistance from your ISP to get your new routers an IP address the first time (not complicated, but everyone's hardware has difference requirements). Enable the firewall logs. If you only see VPN traffic going one way

(&quot; main >> remote&quot;)

and not both

(&quot; main >> remote&quot;
&quot; main << remote&quot;)

you've likely got a routing problem. If you see &quot;Set up ESP tunnel SUCCESS&quot; in blue, well, record how it worked the first time, then fiddle with tightening it up and see how it goes. Some changes will tear the tunnel down (it does a warm restart), and occasionally, you just might want to power-cycle the router yourself.

I've tried to keep it simple, but touch the main points. I hope your head isn't spinning. Good luck.
 
Wow, that is excellent. Thanks Fyrewyre.

I think we will be going down the Linksys path. I'll post again once we're into setup.

Really appretiate all the contributions.



 
Just a small addendum to Fyrewyre's very comprehensive post.

The Linksys BEFVP41, although it will allow you to configure 70 different VPN &quot;tunnels&quot; will only allow one tunnel to access resources behind the router at a time. So if you have the following scenario:

User1 -> BEFVP41 -> 192.168.0.10 (Computer on lan behind router)

and at the same time you need

User2 -> BEFVP41 -> 192.168.0.11 (Different machine behind router)

You're outta luck. The BEFVP41 won't do this.

However, I'm not sure but the following scenario might work:

User1 -> BEFVP41 -> 192.168.0.10
User2 -> BEFVP41 -> 192.168.0.10

As long as all the tunnels connect to the same machine behind the router I think it will work, but again, not sure, haven't tried it.

the first scenario definitly won't work.

Good Luck
Joe
 
Okay,

Got the two routers set up and working. A few things I ran into though...

1. I'm trying to log into a NT 4 domain (at remote location), when I type in the password it tells me the domain is not available, and continues to boot. However, once i'm in windows, I can access the server and the file shares on it. The curious thing is that I can't access the folders that my user name is locked out of, but I can access the ones I'm allowed in. So whats going on? Any way to fix?

2. We want to run the Linksys box into a GNAT box firewall, which then runs to the internet. FyreWyre mentioned that I would have to open port 500 (on an outbound filter?), but how do i set up the linksys so that it connects to the GNAT box, and tunnels through there, all the while getting access to the internet for its (linksys') users? Do i need to have two separate gateways?

eg Linksys (192.12.20.202) -> GNAT (192.12.20.201) -> Internet

Thanks in advance,

David
 
Great! One comment before we look at your issue; Antidote (Joe) said that there was trouble with multiple tunnels accessing different machines - this sounds like a sore state of affairs, indeed, and would really put into question why this device provides multiple tunnels at all. Before I replied though, I wanted to check. In discussions with my contact, we felt Antidote's event wasn't happening, BUT, he was going out of town so it's still pending a closer look.

#1: Maybe someone can speculate and help me with this. On first look, I'm concerned that you're defaulting to cached credentials to log in to your station, and that they'll expire soon. It is curious that you seem to be part of the domain later (assuming you don't reauthenticate). There's a way to check what you used, but I forget how, and I think it's Win2K+. Have you used a protocol analyzer (Ethereal, above) to compare normal login traffic with what you're getting? Are there messages in the logs (NT Events, LinkSys logs, GNAT)? By no means am I leaving this one behind, but I'll have to think about it. I don't use NT4 any more.

#2: I don't have experience with a GNAT box, so I'll digress for a moment. My last client, rather than worry about drilling through his *nix firewall, put the LinkSys at the same level as the switch that brought in the leased line, i.e., in parallel - so it got its own IP. This created two connections to the Internet, where the LAN only knows about the *nix gateway. The remote users needed access to a few Terminal Services machines - and a print server on the LAN, but nothing else. So, we added static routes only to the machines that needed to communicate back to the remote network through the LinkSys. While this isn't necessarily what I would have advised, or what you want to do, it was what my client did because it was simplist (word?).

So here's where I try to tackle your question a little better. Not knowing a lot about GNAT, I'm going to reference it for simplicity.

I assume all the local LAN machines behind your GNAT point to it for their Default Gateway, or get their configuration via DHCP (and the GNAT, not the LinkSys, issues DHCP). That's all well and fine, except you're asking for the LinkSys to provide Internet access - and it's not the default gateway. Even if you got that going, my brain says it doesn't (or shouldn't) work that way. So let's ignore Internet via the LinkSys for now. Let's leave Internet on the GNAT, and look at the tunnel. Returning to my original assumptions, if a local asks for an address on the other side of the tunnel, the LAN side of the GNAT has to say &quot;I don't handle that address, but wait, I know someone who does&quot; - and hand over the LinkSys LAN IP. The LinkSys then, because it knows the remote address is handled by a remote router, is going to send your request through its WAN port - which, cringe, turns out to be exposed on the LAN side of your GNAT again (but at port 500, and encrypted). The GNAT would see the request for the remote LinkSys's WAN IP on its LAN interface and forward it through its WAN port. In other words, if I make a request to your GNAT on port 500, it should take the encrypted packet, replace the GNAT WAN IP in the header with the local LinkSys WAN IP, and present it to the LinkSys WAN. The LinkSys never knows its traffic is being fiddled with, decrypts the packet arriving on its WAN port, and pushes it out its LAN port and onto your network. Same goes for outbound traffic - the LinkSys presents local traffic out the WAN, to the GNAT on port 500, and the GNAT replaces the LinkSys WAN IP with its own WAN IP before forwarding it on to the remote VPN endpoint.

To say it another way, the remote LinkSys's &quot;remote gateway&quot; will specify the GNAT, but the local LinkSys's &quot;remote gateway&quot; will be the other LinkSys (assuming there isn't another firewall there too). The GNAT does NAT, and no one's the wiser.

And guess what? Requests for IP's that the GNAT doesn't know about (Internet) should never route to the LinkSys - they should go out the GNAT WAN to the Internet Gateway already obtained by the GNAT. It should just happen this way by default. The questions that remain, then, are: Are the machines at the remote location using a DIFFERENT SUBNET/MASK? - and, does anyone think I'm way off base here?

If it gets to be too much trouble, let me know - I'll draw the concept graphically and post it on my domain.
 
Wow. Thanks Fyrewyre.

Working on the gnat->linksys thing (opening up a NAT inbound tunnel on port 500). As for the subnet, they are different at both offices. We would like to keep them the same, but the way i understand it, these linksys boxes can't have the same subnet on both ends.

As for the NT server, I'm getting your typical &quot;no domain server could be found to authenticate&quot;. So that's still up in the air.

Any other comments?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top