WRT54GL with DD-WRT VPN firmware - where's the beef?

It's likely I'm missing something. But certain posts regarding vpn features of the dd-wrt firmware indicated that this firmware allowed box-to-box vpn. However, the firmware I installed on my 54GL (dd-wrt R23 vpn) seems to only provide for vpn pass-through, not a box-to-box hardware vpn.

Again, I'm probably missing something or misunderstand the firmware's features, but where are the vpn settings that allow my to connect my Linksys to something like a Sonicwall using pre-shared keys, for example?

thank you,

jm \\

Reply to
JM
Loading thread data ...

"JM" hath wroth:

The router to router VPN is PPTP, not IPSEC. I think that there are some Sonicwall models that support PPTP terminations, but I can't tell due to the lack of a model number. Find the model number and read the specifications to see if it can terminate a PPTP tunnel.

formatting link
With DD-WRT STD, you don't need the VPN version to do router to router via PPTP. My home WRT54GS is currently connected to my office WRT54G (both running DD-WRT STD v23 SP2) using PPTP. See the setup for PPTP under: Administration -> Services -> PPTP

You'll also need to enable and configure the PPTP Client. Note that you can have the PPTP client configured on BOTH sides of the tunnel to log into the PPTP server on the other side. The trick is to NOT re-use any IP addresses for the LAN, VPN, or IP address pool. Allegedly, it's more reliable this way, but that has not been my experience. I have mine connecting only one direction, from home to office. However, I do have the PPTP servers enabled on both ends so that I can login remotely when on the road from my laptops.

Be sure to use a different Class C IP block for each network LAN. For example, if your home network is 192.168.1.xxx, then your office network can be 192.168.2.xxx. Just make sure they're NOT the same IP block. If you use a netmask of 255.255.0.0 on the LAN, switch to

10.xxx.xxx.xxx instead of 192.168.xxx.xxx.

In addition, the IP address pool, assigned by the PPTP server, should be different from both LAN IP blocks.

Also, the docs for the Chap Secrets setting for PPTP in DD-WRT absolutely suck. The examples don't work. The correct format is:

user1 * password1 * user2 * password2 * user3 * password3 *

It's the spaces on both sides of the asteriks that are important.

The best I can do for IPSec support is OpenSwan. See:

Not very encouraging or organized, but if you feel like porting it to DD-WRT, I could certainly use it.

Reply to
Jeff Liebermann

Jeff Liebermann hath wroth:

Also OpenVPN which builds an SSL VPN. Looks messy but workable.

Reply to
Jeff Liebermann

Thank you for your reply.

What I'm trying to accomplish is access to a shared file in the main office. The remote office has two PCs that need access to an inventory spreadsheet on a workgroup PC in the main office. The home office has 12 channels of T1 for internet, and the remote office has business DSL from Bell.

The Sonicwall model in the main office is TZ 170, not sure of the hardware or firmware release (will get that later).

Given this relatively modest need (?), what solution would you recommend? I even have access to another Sonicwall (SOHO3), for a couple hundred bucks. It's just that they already have the Linksys in the remote office.

thank you again,

jm

Reply to
JM

On Fri, 13 Apr 2007 08:50:53 -0500, "JM" wrote in :

How about running the software client for SonicWALL VPN?

Reply to
John Navas

"JM" hath wroth:

Secure file sharing does not require that the VPN be terminated at the wireless access point. It can also be terminated by whatever you're using for a server. If you're concerned about someone sniffing the

*WIRED* part of your network, then end to end VPN is the right solution. If only the wireless part is a problem, methinks you have everything you need. Unfortunately, the TZ170 is a series of models with various fallback, VPN, wireless, "enhanced" SonicOS, etc features added (or missing). I think one of these versions supports router to router VPN (2 nodes or 10 clients) without additional software upgrades. However, that's for IPSec and not for PPTP.

Where does the wireless come into the picture? This sounds like a wired solution?

Well, there are many options depending on how much money you want to spend. I was going to suggest that you simply purchase another $600 Sonicwall TZ170 and build a VPN network, but that might be a bit pricy. It would follow your original plan of router to router VPN essentially creating one big network out of the two offices.

However, for just two clients and perhaps a few printers, this is overkill. The easiest way is to setup the TZ170 for IPSec VPN termination, and use a Windoze (or 3rd party) IPSec client on the two computahs. Sonicwall VPN client:

You can also use open source VPN clients or get the Sonicwall client from other sources (SafeNet). I also use the Checkpoint and Cisco VPN client without much difficulty. (Note: Neither currently works with Vista). Also, PoPToP for PPTP under Linux.

I should warn you that the Sonicwall client is a bit feature infested and will take some documentation reading or trial an error to untangle. Also, if security is the prime concern, then try setting up Sonicwall "Zones" to isolate casual users from the main server.

If this VPN arrangement is going over DSL, you may have a performance problem, especially if your DSL upload speed is slothish. Basically, the VPN runs at the speed of the slowest connection. I'm not sure what you mean by "12 channels of T1". Is that 12ea 128Kbit/sec bonded DS0 channels, a PRI (primary rate inteface), or 12 individual T1 lines? At 128Kbits/sec, it's gonna be really slow. At T1 speeds, no problem.

Another possibility is to terminate the VPN in a Windoze or Linux server. That could be the unspecified machine that is doing the serving. PPTP server comes with W2K Server. IPSec, L2TP, and IPSec servers come with Windoze Server 2003. The big advantage to terminating at the server is additional security on the wired part of the network, and the ability to use the very simple PPTP client supplied on every Windoze client installation.

Anyway, you have several options depending on how you want to organize this system. However, before you proclaim anything to be a solution, I suggest you try running a VPN through your DSL/T1 connection, and evaluate the performance issues. Many applications just don't like to run this way and many data connections just aren't fast enough to be useful. You may find that a remote desktop solution (PC Anywhere, VNC, Windoze remote Desktop) to be faster or better. Once you determine if the datacomm part of the puzzle is suitable, then continue with the project.

Reply to
Jeff Liebermann

I'm top-posting this because your reply has revealed to me just how little I know about this stuff, and I found out things today at the customer site that might take all this into a different direction.

First, the reason I was thinking "wireless" in the first place (and thus posted here) was because there is a WRT54GL wireless router in the remote office. I thought with the right firmware I could use that box to establish a connection to the Sonicwall in the home office. So, you're right, this isn't a "wireless" issue, at all. It's a VPN/connectivity/networking issue. The box in question just happens to be wireless. The DD-WRT firmware came to mind because I've used it many times for non-vpn applications - and, of course, because it's free.

And I'm not really concerned about security (within reason, of course) across the link. In truth, the file to be shared is not all that sensitive anyway. I don't mean to sound careless; it's just that the document isn't of a critical nature. It's a list of inventory. A hacker would have very little use for it. Having said that, I want to take steps to be reasonably secure.

Prior to my trip up there today, my goal was fairly straightfoward: The two people in the remote office need to access an Excel spreadsheet that is on a computer in the main office. The main office has about 12 computers in a workgroup. The spreadsheet is updated daily by an admin person, and personnel use it to check stock levels. There is no "server" of any real kind in the organization. It's peer-to-peer all the way.

The suggestion of a software VPN client (by you and another poster) is a good one. I've done that several times with good results. [by the way, the Netgear Prosafe VPN client works well with Sonicwalls in a GroupVPN SA using a preshared secret]. The only reason I wanted to attempt a hardware-to-hardware arrangement is that the customer has expressed a desire to put one IP phone in the remote office, connected to the main office using an MCK gateway and branch product. I've done these several times, with varying success. DSL upload speeds are not ideal, to say the least, but with compression and some amount of QoS on the LAN side (can't do anything about it after that point, of course), I've managed to get 1-2 IP phones to behave enough for inter-office communications.

Anyway, I found out today that they want 2 IP phones. That concerns me over DSL, but with the right wording in the contract I'm willing to give it a go. So what I really need is not so much a "vpn," but, rather, a nailed-up connection over internet (is that the same thing : )).

So, I ask the knowledgeable folks here: What do I do?

thank you,

jm

Reply to
JM

"JM" hath wroth:

Groan. Typical customer. I show up to do one simple thing, and they hit me with what I call "Oh, by the way..." type of changes, additions, complications, and restrictions. Life in the slow lane I guess. My usual defense is to demand that they document what they want (i.e. make a things to do list). That usually slows them down a little... very little.

As for realizing how little you know, that's not a problem. Most of the stuff I mentioned will be reduced in both scope and complexity once the customer and you negotiate what they are trying to accomplish. VPN's are NOT that complicated. It's just that there are plenty of options, software, methods, tricks, and restrictions. In this case, if you had the same model router at both ends of the link, I suspect things would be MUCH simpler.

Yeah, that's what I was thinking. However, don't ignore the wireless security part of the puzzle, especially if you're going to be using VPN client software on the wireless clients.

Well, that's the basic problem. WRT54GL DD-WRT prefers a PPTP VPN. Sonicwall prefers an IPSec VPN. Note that there are some boxes (i.e. Netscreen) that will do both. If you want to make things easy, use the same model box at both ends and they'll talk just fine. Otherwise, you can add IPSec to the WRT54GL DD-WRT, or add IPSec to each client computer. Both will work.

Yep. However, that's just getting the initial connection. The real problem is that you have two different model routers terminating the connection. You've got potential incompatibility issue. In the distant past, I've had compatibility issues with IPSec between two routers that resulted in a finger pointing exercise between vendors. Both blamed the other, but neither would even investigate, much less do anything to fix the problem. Some of the problems were subtle and did not show up until well after I declared things to be working. Since then, I've been rather paranoid about building VPN's with different manufacturers hardware. However, I have not had any difficulties with software to hardware router compatibility issues as the software vendors are often quite good about testing and certifying to work with a variety of hardware routers.

Well, with a VPN, you get security for free. It is possible to create a VPN without the encryption and authentication, but you really have to try hard to make it work. If you leave the VPN security in place, and use WPA or WPA2 encryption on the wireless, you'll do fine.

Lovely. From the user standpoint, the easist way to make the whole mess transparent (i.e. user friendly) is to build the VPN, even if the function could probably be done via email. The entire network, including the two machiens at the remote office, will appear as one big network. Doing it between routers means the user doesn't need to do anything special to access machines across the VPN.

I'm marginally sure that the Netgear and Sonicwall VPN clients are both licensed from the same company. If you don't mind, I don't want to research it now to be sure.

I've also done this with miserable success. The problem is that the VPN decryption and de-encapsulation is done BEFORE the packets can be inspected for content at the receive end. That means that QoS and packet prioritization does not normally work because the destination router has no clue what's inside the packet before it's decrypted. That puts everything on a level playing field and results in miserable VoIP quality.

It's not too horrible if the bulk of the VoIP traffic goes directily to the internet and not through the VPN. For example, if you were to inititate a VoIP call through the VPN, it would probably sound awful. However, the same call, sent directly through the gateway, to the internet, and into the other end, resulted in decent quality (even without QoS). Instead of dialing an IP address on the LAN side of the network, I dialed the WAN IP address of the other end, and through the miracle of SIP port forwarding (i.e. it's a miracle if it works), the call bypasses the whole VPN mess. It's tricky to setup, but guess I can login to my customer and try to reconstruct how I did it (later). The nice part of this scheme is that QoS now works because the VoIP traffic is NOT encapsulated.

I have a pair of loaner IP Phones and a demo account that I let customers use before they take the plunge. There are always a few that absolutely will not tolerate any garble or dropouts. Some go nuts (including me) when they don't hear any background noises or hiss as I suspect the connection has disappeared. Despite user training by the cellular providers to tolerate crappy connections and unintelligible speech, land line users have different expectations. I suggest you let them fly before they buy.

Very different and ambigious. In the bad old days of dialup, "nailed up" meant that the connection was full time and never required reconnections, dialing, or on/off hook exercises. Well, that's most DSL lines. Despite the PPPoE login requirements of some vendors (i.e. at&t), the connection stays up and on the same dynamic IP long enough to be considered full time or "nailed up".

Methinks you might be thinking of static IP versus dynamic IP. This is not a problem as various dynamic DNS vendors can provide the connection via DNS. I use dyndns.com service for all my dynamic IP customers, mostly so I can get remote access to do necessary service, but also for some VoIP applications. The only reason I can think of that would require a static IP address is if you're running your own mail server and need a static IP for the MX record.

Dunno. It really depends on how important the two machines at the remote office are going to be. If this is the extent of their expansion, then I would use software VPN clients, dynamic DNS, and setup the IP phones as just some kind of intercom. That's the cheapest and easiest. However, if this remote office is going to grow in function and people, I would seriously consider replacing the Linksys WRT54GL with another Sonicwall TZ-150 and build a symmetrical IPSec VPN. This is probably the most expensive solution, but the easiest to deal with in terms of features, expansion, support and administration.

Reply to
Jeff Liebermann

Okay, we're really starting to get somewhere here. Let me say again how much I appreciate your assitance.

Couldn't agree more. I've been in network/desktop support for 7 years. This issue never changes; only the way I handle it does.

You're right. My primary confusion lies in the different types of connections, various implementation methods, etc, as well as what to do after the connection is established. Specifically, I'm struggling with the relationship between VPN and [Windows] networking and resource sharing, when I do not have like boxes at each end. For example, this morning I was messing around with the built-in vpn "server" in Windows XP. I created an incoming connection and forwarded port

1723 to my desktop. I then had one of my techs (who is running Vista Home, btw) set up a connection from his home computer. After a bit of tweaking he connected fine. However, I wasn't sure how to give him access to a test file I created in a test folder on my C drive. Since his computer isn't part of my workgroup, I thought I could (and would have to) force the share with a Run command. But either my syntax was incorrect or I was missing something entirely. I know WINS relationships can be created by editing the hosts/lmhosts file(s), but this didn't seem to be an issue. He could ping my computer by host name.

At any rate, as is the case with anything, improvising and troubleshooting requires a much deeper understanding of a topic than does setting something up by following a process.

Exactly what I've been thinking overnight. I can provide them a Sonicwall SOHO3 for a couple hundred dollars. I have 3 other clients' networks connected via SOHOs and TELEs, and as long as I enable netbios broadcast and set up the LANs on different subnets, I can get the Windows networking to do pretty much what I want. Until my exchange with you, I didn't understand the signficance of having both ends speaking the same vpn language (IPSec, PPTP, etc)

Ok.

I may be missing where you've said so, but how is IPSec "added" to the Linksys?

I also considered this solution. Why not just have the admin person email the updated spreadsheet as needed?

That's right. And it gives the boss the warm and fuzzy that he's all inter-connected and one big happy family.

I don't mind at all, and after some brief reading this appears to be the case.

Excellent point - and one I'm very, very glad you brought up. I posed that very question recently in another forum, but I did not receive a confident answer. It seems reasonable to me that subjecting a voice packet to the the encryption/decryption process can only create further opportunities for delay - the death knell for voice traffic.

I've been thinking a lot about this. I definitely want the voice outside the vpn.

Are there any disadvantages to using a dynamic dns service?

Okay, so how about this:

Put the VPN client s/w on the two remote PCs. Configure SA on the Sonicwall. Enable IPSec passthrough on the Linksys. Data part done.

For the voice, point my MCK IP gateway at a public IP address at the remote site. Put the MCK branch unit behind the Linksys and create a one-to-one NAT translation to it.

Workable?

jm

Reply to
JM

i think i just answered one of my own questions regarding connecting to a resource using the Run box. I think my mistake was including the C: drive in my command.

Reply to
JM

"JM" hath wroth:

Well, the easiest way to deal with a VPN is to *FIRST* understand how they work. I can explain in detail but I don't want to burn the time right now. The basic idea is for the terminating VPN server (or router), to deliver an IP address that is in the same IP address block as the NAT LAN connected to the terminating VPN server, to the client. A numerical example is probably easiest.

Destination router: WAN IP = 63.198.98.51 LAN IP = 192.168.25.xxx (The 25 is arbitrary) LAN DHCP IP Pool = 192.168.25.100 -> .149 LAN VPN IP Pool = 192.168.25.150 -> .174

The clients network router: WAN IP = 63.249.15.98 LAN IP = 192.168.3.xxx (The 3 is arbitrary) LAN DHCP IP Pool = 192.168.3.100 -> .129 LAN VPN IP Pool = Not needed or used

Example workstation: Not connected to VPN: IP Address = 192.168.3.111 Gateway IP = 192.168.3.1 (the local router IP) When connected to VPN: IP Address = 192.168.3.111 Gateway IP = 192.168.3.1 (the local router IP) IP Address #2 = 192.168.25.150 (first IP in LAN VPN IP Pool) Gateway IP #2 = 192.168.25.1 (LAN IP of remote VPN router)

All traffic that does *NOT* have a destination IP in the

192.168.25.xxx block goes via the router gateway to the internet directly. All traffic that does have a destination IP in the 192.168.25.xxx block goes to the remote VPN router via the VPN tunnel.

You can see this with the results of the "route print" command in Windoze. I've edit the results so that it will fit on the page and have eliminated my maze of static routes and garbage.

Not connected to VPN:

Connect to remote VPN router:

It may look messy, but it's not. Just compare the results: 63.198.98.51 is the WAN IP of my office VPN router. 192.168.1.xxx is my local LAN (at home) 192.168.1.11 is the IP of my desktop. 192.168.111.xxx is my office LAN on through the VPN. 192.168.111.141 is 2nd IP address the VPN server gave to my desktop.

There is one gotcha here. Note that the default gateway is my home router at 192.168.1.1 in both cases (with and without the VPN). That's not always the case or desirable. The VPN clients all have a choice of whether you want the default gateway for the VPN to be the local router, or the remote router. I prefer local router, but there are situations where the remote router gateway is the preferred setting.

I assume the folder was set to shareable. Have him try: Start -> run -> cmd \\\\machine_netbios_name\\shared_folder_name He should see a directory listing shortly. Don't bother with the Windoze browser mess. It takes forever and frequently fails (due to the inability to send broadcast packets through the VPN). Go the direct route first. Once you can see the shared folder, add it to the shopping list in Network Places or assign it a local drive letter.

It should work as described. I noticed that in your followup, you added the drive letter. Bad idea. The drive letter only has significance on the local machine. Forget drive letters altogether (the Unix way) if you want to remain sane.

Ummm... I'll spare you the lecture, but WINS is a bad replacement for DNS. Hosts and LMhosts are nice for name to static IP conversions. Neither should be necessary in order to see a remote share.

Yep. My simplified version is "Learn By Destroying(tm)". If you haven't trashed and fixed it, you don't really understand it.

I think you had better fire up Ethereal/WireShark and measure your broadcast traffic. I've had networks of this form literally die as a result of passing too much broadcast junk. If you don't want to sniff, just watch the lights on the ethernet switch. If they all flash in unison, it's a broadcast packet.

Anyway, the only thing you really need broadcasts are if you're using the Windoze "network neighborhood" browser and finding printers remotely. If you forget about these, use static links, shortcuts, or assigned drive letters to deal with devices across the VPN, then you can turn off broadcasts and save yourself some bandwidth.

Also, if you want to run a single DHCP server for both the local and remote LAN's, you would need to enable passing broadcasts. However, I don't recommend doing that.

Oh, it's worse than just the basic protocol. There are a mess of encryption, authentication, and encapsulation protocols available. Fire up the Netgear/SafeNet VPN client and just look at all the available options. Yech.

With difficulty. However, I screwed up:

I thought this was IPSec. It's and SSL based VPN. Sorry.

OpenSwan is the Linux IPSec software.

There may be a successful port of OpenSwan to DD-WRT or OpenWRT, but I couldn't find it.

I'm also now totally confused as to what exactly is in the VPN version of DD-WRT. I managed to find the new V24 beta VPN simulation at:

but can't find anything unique about it and a VPN. More research (later).

Yep. It really depends on their workflow. If it's a undirectional exchange of spreadsheets, email will work just fine.

Well, let's compare ping times with and without the tunnel. 1500/384 kbits/sec DSL lines at both ends of this test. Routers are both WRT54G/GS with DD-WRT v23 SP2.

Without the VPN: Pinging 63.198.98.51 with 32 bytes of data: Reply from 63.198.98.51: bytes=32 time=26ms TTL=56 etc...

Through the PPTP VPN: Pinging 192.168.111.33 with 32 bytes of data: Reply from 192.168.111.33: bytes=32 time=30ms TTL=64 etc...

192.168.111.33 is the LAN side IP address of my office router.

So, the MS PPTP VPN adds 4 msec going through two routers. That's not too horrible. However, I got a surprise when I ran it. The ping times started all over the place with this mess: Reply from 192.168.111.33: bytes=32 time=40ms TTL=64 Reply from 192.168.111.33: bytes=32 time=31ms TTL=64 Reply from 192.168.111.33: bytes=32 time=33ms TTL=64 Reply from 192.168.111.33: bytes=32 time=85ms TTL=64 It didn't stabilize for at least 15 seconds. I thought it might have been some local traffic, so I disconnected, and reconnected and it did exactly the same thing. 15 seconds of wildly variable latency, followed by stable results. Interestingly, it wasn't 15 seconds from the initial connection, but 15 seconds after starting the initial ping. Weird. I'll sniff this mess (later) but I'm guessing that there's some packet loss involved.

Also, I was going to do it using an IPSec client, but it seems that it's not installed on this machine. It's late, I'm tired, and it will have to wait until tomorrow. My assumption is that since the IPSec client is more complex, it will have a longer added delay.

Sure. They sometimes disappear or get DDoS attacked. Dyndns.com disappeared erratically for about a week in December and erratically since then. See history at:

I cover my posterior by having multiple dynamic DNS mechanisms including a really crude piece of junk that I wrote, which just ftp's a file to my server with the current IP address inside. I didn't even notice that there was a problem until I saw it in the mailing lists.

Another problem is support by the router manufacturers. Many of them have implemented broken dynamic DNS clients. I sometimes have to resort to installing the Windoze dyndns.com client as the one in the router sometimes has problems. Sorry, I forgot the model numbers with problems. There's also considerable non-communications between the firmware scribblers and DynDns.com. For example, the WRT54G (with stock firmware):

Various client software:

Yep. That's easy enough.

Yep. The only problem is see is giving priority to the MCK IP gateway for VoIP packets over the rest of the traffic. Since with NAT, the VoIP (SIP???) packets will be going trough the routers at both ends, QoS and traffic shaping should be quite easy.

Incidentally, MCK got bought by Citel in Jan 2005. I don't see the MCK products supported on either the Citel or the Verso web sites.

If they already own the MCK boxes, then you might as well use them. However, methinks you can do as well with an IP phone or FXO/FXS adapters and conventional POTS phones.

Reply to
Jeff Liebermann

Thank you, Jeff. I haven't bailed on the discussion. I'm just digesting this and getting some projects out of the way. I look forward to continuing this great learning experience later. Please check back.

jm

Reply to
JM

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.