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

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.




"JM" <jake@xxxxxxxxx> wrote in message
news:i9Cdnczlapk8sLzbnZ2dnUVZ_vqpnZ2d@xxxxxxxxxxxxxx
Okay, we're really starting to get somewhere here. Let me say again how
much I appreciate your assitance.


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.

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.


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.

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.


In this case, if you had the same model router at both ends of the link,
I suspect things would be MUCH simpler.

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)

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.

Ok.


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.

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


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.

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


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.

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


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.

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


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.

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.


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.

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


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.

Are there any disadvantages to using a dynamic dns service?


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.

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














.