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
\

"JM" <(E-Mail Removed)> hath wroth:

>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?

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.

http://www.dd-wrt.com/wiki/index.php/VPN

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:
<http://www.dd-wrt.com/wiki/index.php/OpenSwan>
Not very encouraging or organized, but if you feel like porting it to
DD-WRT, I could certainly use it.



--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <(E-Mail Removed)> hath wroth:

Also OpenVPN which builds an SSL VPN. Looks messy but workable.
<http://www.dd-wrt.com/wiki/index.php/OpenVPN>


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

"Jeff Liebermann" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "JM" <(E-Mail Removed)> hath wroth:
>
>>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?
>
> 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.
>
> http://www.dd-wrt.com/wiki/index.php/VPN
>
> 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:
> <http://www.dd-wrt.com/wiki/index.php/OpenSwan>
> Not very encouraging or organized, but if you feel like porting it to
> DD-WRT, I could certainly use it.
>
>

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

On Fri, 13 Apr 2007 08:50:53 -0500, "JM" <(E-Mail Removed)> wrote in
<(E-Mail Removed)>:

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

How about running the software client for SonicWALL VPN?

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

"JM" <(E-Mail Removed)> hath wroth:

>What I'm trying to accomplish is access to a shared file in the main office.

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).
<http://www.sonicwall.com/downloads/TZ_170_US.pdf>
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.

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

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

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

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:
<http://help.mysonicwall.com/applications/vpnclient/>
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.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

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














"Jeff Liebermann" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "JM" <(E-Mail Removed)> hath wroth:
>
>>What I'm trying to accomplish is access to a shared file in the main
>>office.
>
> 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).
> <http://www.sonicwall.com/downloads/TZ_170_US.pdf>
> 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.
>
>>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.
>
> Where does the wireless come into the picture? This sounds like a
> wired solution?
>
>>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.
>
> 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:
> <http://help.mysonicwall.com/applications/vpnclient/>
> 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.
>
> --
> Jeff Liebermann (E-Mail Removed)
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558

"JM" <(E-Mail Removed)> 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 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.

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 (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

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

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> 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 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.
>>
>> 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 spreadsheet 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
>
>
>
>
>
>
>
>
>
>
>
>