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

"JM" <jake@xxxxxxxxx> hath wroth:

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.

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.

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.

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.

I thought with the right firmware I could use that box to establish
a connection to the Sonicwall in the home office.

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.

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.

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.

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.

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.

Prior to my trip up there today, my goal was fairly straightfoward: The two
people in the remote office need to access an Excel spread*** that is on a
computer in the main office. The main office has about 12 computers in a
workgroup. The spread*** 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.

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.

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].

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.

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.

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.

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.

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.

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.

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.

So what I really need is not so much a "vpn," but, rather, a nailed-up
connection over internet (is that the same thing : )).

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.

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

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.

--
Jeff Liebermann jeffl@xxxxxxxxxxxxxxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.