[Seattle-SAGE] VPN connections from possibly overlapping networks

Robin Battey zanfur at zanfur.com
Wed May 4 02:14:43 PDT 2005


Howdy!

I just ran into another problem in Sysadmin-land.  Having conquered the
dragon of Exchange and set myself up as ruler of my new Exim4/Cyrus castle
(yeah, I know, shoulda used postfix -- I'll fix that eventually), I find
myself facing a dragon once again:  How to allow my roadwarrior knights in
shining armor to connect through our VPN from their internet cafes in
Paris, when those internet cafes use the same RFC 1918 private network as
I do.  (That would be the unfortunately common 192.168.0.0/24 private
network.)

So, I don't trust PPTP (MPPE, in particular), and have decided upon L2TP
over IPSec as my VPN lance of choice.  After 8 months of scattered,
interrupted, pockmarked, and otherwise gruelling effort, the VPN finally
works as intended -- it even uses our universal (LDAPv3) usernames and
passwords for authentication (don't ask how unless you REALLY want to
know).  I'm connected to it right now, actually, and everything is dandy,
because for some reason I set my home network to the slightly non-standard
network of 192.168.1.0/24 (I was young and inexperienced ...  and didn't
know that 192.168.0.0/24 was a valid network).

Then I head to Trabant, my favorite internet cafe and chai lounge, and I
can connect to the VPN perfectly (IPSec connection is made, L2TP tunnel
created, and PPP session established) but exactly ZERO traffic passes
through it.  A little investigation reveals that this is because all
traffic destined for my company network is considered to be on the local
network, and just shunted out the local interface ... and not through the
VPN connection.  Of course, this is because Trabant uses the same network
as my company, 192.168.0.0/24.  When connecting from a non-overlapping
network, the default route is used for the remote network, and the default
route goes through the VPN.  When connecting from an overlapping network,
the local subnet route overrides the default route, and the VPN doesn't
get touced.

Now, the owner of Trabant is actually quite rad, and offered to change the
netblock he uses so I wouldn't have this problem while telecommuting from
his store, sipping his merchandise while I should be in the office -- but
this doesn't solve my larger problem:  My users won't have a clue what's
going on, won't WANT a clue what's going on, and will complain at me when
it doesn't work from their particular location, and they'll complain
especially loudly when they have to call me from Romania (to list the
current location of some of our employees) to do this complaining.

My query is this:  Short of renumbering my company's internal network to
something slightly less standard, is there a way to get this to work?

I've considered this for a bit, and I have a solution that will work, but
it has to be implemented on the client side, in the VPN client and OS.  I
don't want split tunneling (when the machine is connected to the VPN, I
want ALL traffic going through that VPN), so if there's a way to make the
VPN connection used for everything *except* the VPN traffic itself, that
would work splendidly.  This would be akin to using a proxy server for all
traffic except proxy traffic itself (*including* local traffic), which I
know can be done.  However, I need a way of telling the routing code of
the OS to do exactly that.  How?  I have no earthly idea.

Cheers!
-robin

P.S. before anyone brings it up, the VPN server is not behind a NAT (it's
the gateway box itself), and WinXP SP2 changed nothing for my setup.

-- 

                              Robin  Battey
                            zanfur at zanfur.com

Messages from this address are signed with key 0x6A57B07D.  Fingerprint:
           3914 F63C A99C 8EC1 785B  8287 1D8B D2F3 6A57 B07D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.sasag.org/pipermail/members/attachments/20050504/54fada4e/attachment.bin>


More information about the Members mailing list