[c-nsp] Overlapping NAT subnets and PPTP

up at 3.am up at 3.am
Fri May 30 22:05:12 EDT 2008


On Fri, 30 May 2008, Andrew Gristina wrote:

> One: most people use a real name on the list.

One:  thank you for your response
Two:  my real name is in my .sig below, as it was on my initial post. 
up at 3.am is my real email address.  really!

> Two: PPTP and PAT don't really mix.  Read up on the PPTP protocol.  If
> not just try a whole bunch of PPTP clients behind a PAT.  I don't
> really value the PPTP protocol very highly.

I wasn't looking to do PAT, I was looking to fake out an overlapping NAT 
subnet conflict by using static maps from a non-conflicting subnet to the 
conflicting one.

> Three: IPSec can do double NAT or double PAT (disguise the same
> network at both ends)

That's great, but the client wants users to be able to log in to the VPN 
from any MS client.  There already is an IPSec GRE tunnel set up to 
another network on it, but that's not what they want here.

> Four: VPN for B2B implementations are better off if everyone insists
> on publics for the interesting traffic networks, then each network
> owner can NAT at their "demarc".

Perhaps I'm just not following you, but what we're talking about here 
(with these PPTP clients) are various users from all over the 
place...usually their home broadband network or from a hotel or whatever, 
where the LAN invariably is on 192.168.1.0/24.  The client didn't consider 
this when numbering their 100+ node internal LAN on that same subnet, 
which is why I'm attempting this kludge.  If this kludge is a waste of 
time, I'd just like to know that ASAP so I cna tell them they have to just 
do it.  If it's doable, I'd like to know what I'm doing wrong.

> These are all things that are probably in the list archive.

I gave the archives a search, but didn't see anything on 'overlapping 
subnets'.

> I hope you got more replies than this, and in a kinder gentler tone,
> but I'm in a hurry and didn't see anyone reply to you.

I appreciate the gesture.  Thanks!

> On Thu, May 29, 2008 at 8:50 AM,  <up at 3.am> wrote:
>>
>> I have a customer that has a 2811 with a fairly complex NAT VPN
>> configuration (an existing GRE tunnel, a bunch of static NAT mappings to it,
>> etc).
>>
>> We just added a PPTP to it and ran into an overlapping subnet issue with it.
>>  They have over a hundred internal hosts on 192.168.1.0/24 and of course,
>> many people who PPTP into it are using that same RFC1918 space on their LAN
>> (it's hard coded into my Verizon router, for example).  Since the incoming
>> PPTP connections need to talk to those hosts, there is obviously a conflict.
>>
>> Cisco TAC's position was that they need to renumber to eliminate the
>> conflict.  That may be true, but we came up with an idea that seems like it
>> should work as an alternative.  That is to use something like:
>>
>> ip nat source static 192.168.1.20 10.3.3.20
>> or
>> ip nat outside source static 192.168.1.20 10.3.3.20
>>
>> to "fool" the incoming PPTP connected hosts.  To some extent, it works. The
>> incoming connections can now ping 10.3.3.20 and get responses (they could
>> not ping 192.168.1.20).  However, any attempt to connect to any TCP port on
>> that host results in a "connection refused".
>>
>> Is this just a dead-end for this kludge, or is something else needed?  Has
>> anyone else succeeded with it?  The customer just wants to avoid renumbering
>> if possible (for now), so I just want to make sure that if this kludge
>> doesn't work, I can explain why, or make it work if possible.
>>
>> Thanks in Advance!
>>
>> James Smallacombe                     PlantageNet, Inc. CEO and Janitor
>> up at 3.am                                                     http://3.am
>> =========================================================================
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>

James Smallacombe		      PlantageNet, Inc. CEO and Janitor
up at 3.am							    http://3.am
=========================================================================


More information about the cisco-nsp mailing list