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?
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
"JM" <jake@yahoo.com> 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.
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:
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.
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
"Jeff Liebermann" <jeffl@comix.santa-cruz.ca.us> wrote in message
news:934u13hchhdec1ig82nc136q2dbasuhagd@4ax.com...
> "JM" <jake@yahoo.com> 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.
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
On Fri, 13 Apr 2007 08:50:53 -0500, "JM" <jake@yahoo.com> wrote in
<wuKdnaWg1d99F4LbnZ2dnUVZ_tijnZ2d@comcast.com>:
>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>
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
"JM" <jake@yahoo.com> 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.
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
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" <jeffl@comix.santa-cruz.ca.us> wrote in message
news:79bv13la9nrj836onlr3etcflbef4didkm@4ax.com...
> "JM" <jake@yahoo.com> 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 jeffl@comix.santa-cruz.ca.us
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 http://802.11junk.com
> Skype: JeffLiebermann AE6KS 831-336-2558
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
"JM" <jake@yahoo.com> 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.
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
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.
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@yahoo.com> wrote in message
news:i9Cdnczlapk8sLzbnZ2dnUVZ_vqpnZ2d@comcast.com. ..
> 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
>
>
>
>
>
>
>
>
>
>
>
>
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
"JM" <jake@yahoo.com> hath wroth:
>> 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.
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.
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.
>However, I wasn't sure how to give him access to a test
>file I created in a test folder on my C drive.
I assume the folder was set to shareable.
Have him try:
Start -> run -> cmd <enter>
\\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.
>Since his computer isn't
>part of my workgroup, I thought I could (and would have to) force the share
>with a Run command.
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.
>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.
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.
>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.
Yep. My simplified version is "Learn By Destroying(tm)". If you
haven't trashed and fixed it, you don't really understand it.
>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.
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.
>Until my exchange with you, I didn't understand
>the signficance of having both ends speaking the same vpn language (IPSec,
>PPTP, etc)
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.
>I may be missing where you've said so, but how is IPSec "added" to the
>Linksys?
With difficulty. However, I screwed up:
<http://www.dd-wrt.com/wiki/index.php/OpenVPN>
I thought this was IPSec. It's and SSL based VPN. Sorry.
OpenSwan is the Linux IPSec software.
<http://www.dd-wrt.com/wiki/index.php/OpenSwan>
<http://www.ipsec-howto.org/t1.html>
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:
<http://www.informatione.gmxhome.de/DDWRT/Standard/V24BetaVPN/index.html>
but can't find anything unique about it and a VPN. More research
(later).
>I also considered this solution. Why not just have the admin person email
>the updated spreadsheet as needed?
Yep. It really depends on their workflow. If it's a undirectional
exchange of spreadsheets, email will work just fine.
>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.
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.
>Are there any disadvantages to using a dynamic dns service?
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:
<https://www.dyndns.com/news/status/>
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):
<http://www.dyndns.com/support/kb/linksys_wrt54g.html>
Various client software:
<https://www.dyndns.com/support/clients/>
>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.
Yep. That's easy enough.
>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?
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.
Re: WRT54GL with DD-WRT VPN firmware - where's the beef?
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
>
>>> 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.
>
> 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:
>>Active Routes:
>>Network Destination Netmask Gateway Interface
>>Metric
>> 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.11
>> 1
>> 192.168.1.0 255.255.255.0 192.168.1.11 192.168.1.11
>> 1
>> 192.168.1.11 255.255.255.255 127.0.0.1 127.0.0.1
>> 1
>> 192.168.1.255 255.255.255.255 192.168.1.11 192.168.1.11
>> 1
>> 255.255.255.255 255.255.255.255 192.168.1.11 1000003
>> 1
>>Default Gateway: 192.168.1.1
>
> Connect to remote VPN router:
>>Active Routes:
>>Network Destination Netmask Gateway Interface
>>Metric
>> 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.11
>> 1
>> 63.198.98.51 255.255.255.255 192.168.1.1 192.168.1.11
>> 1
>> 192.168.1.0 255.255.255.0 192.168.1.11 192.168.1.11
>> 1
>> 192.168.1.11 255.255.255.255 127.0.0.1 127.0.0.1
>> 1
>> 192.168.1.255 255.255.255.255 192.168.1.11 192.168.1.11
>> 1
>> 192.168.111.0 255.255.255.0 192.168.111.141 192.168.111.141
>> 1
>> 192.168.111.141 255.255.255.255 127.0.0.1 127.0.0.1
>> 1
>> 192.168.111.255 255.255.255.255 192.168.111.141 192.168.111.141
>> 1
>> 255.255.255.255 255.255.255.255 192.168.111.141 1000003
>> 1
>>Default Gateway: 192.168.1.1
>
> 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.
>
>>However, I wasn't sure how to give him access to a test
>>file I created in a test folder on my C drive.
>
> I assume the folder was set to shareable.
> Have him try:
> Start -> run -> cmd <enter>
> \\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.
>
>>Since his computer isn't
>>part of my workgroup, I thought I could (and would have to) force the
>>share
>>with a Run command.
>
> 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.
>
>>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.
>
> 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.
>
>>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.
>
> Yep. My simplified version is "Learn By Destroying(tm)". If you
> haven't trashed and fixed it, you don't really understand it.
>
>>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.
>
> 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.
>
>>Until my exchange with you, I didn't understand
>>the signficance of having both ends speaking the same vpn language (IPSec,
>>PPTP, etc)
>
> 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.
>
>>I may be missing where you've said so, but how is IPSec "added" to the
>>Linksys?
>
> With difficulty. However, I screwed up:
> <http://www.dd-wrt.com/wiki/index.php/OpenVPN>
> I thought this was IPSec. It's and SSL based VPN. Sorry.
>
> OpenSwan is the Linux IPSec software.
> <http://www.dd-wrt.com/wiki/index.php/OpenSwan>
> <http://www.ipsec-howto.org/t1.html>
> 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:
> <http://www.informatione.gmxhome.de/DDWRT/Standard/V24BetaVPN/index.html>
> but can't find anything unique about it and a VPN. More research
> (later).
>
>>I also considered this solution. Why not just have the admin person email
>>the updated spreadsheet as needed?
>
> Yep. It really depends on their workflow. If it's a undirectional
> exchange of spreadsheets, email will work just fine.
>
>>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.
>
> 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
WRT54GL with DD-WRT VPN firmware - where's the beef? 