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


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


.