Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Rare scenario with VPN and NAT

Reply
Thread Tools

Rare scenario with VPN and NAT

 
 
ae
Guest
Posts: n/a
 
      10-21-2004
Hi all

I can't find this information on Cisco.com. Here is the scenario. Hope
someone can shed some light.

Companies A & B want to establish a VPN tunnel (using Routers A & B).

Router A has the IP address of 100.1.1.1 (external). Its internal network
has a host (Host A) with a private address of 192.168.1.2.

Router B has the IP address of 200.1.1.1 (external). Its internal network
also has a host (Host B) with a private address of 192.168.1.2 (same address
as Host A).

Obviously, Companies A & B have identical IP address space. Good thing is
that only Host A can initiate requests to Host B (application server). Host
B are not allowed to initiate request to Host A.

The requirements are these:
1. Traffic between Host A & B must be in VPN tunnel.
2. Host A can use Router A's overloaded external address. This way Host B
sees Host A as having an address of 100.1.1.1 (Router A's address).

Do Cisco routers support this kind of configuration?

Thanks.

Al


 
Reply With Quote
 
 
 
 
PES
Guest
Posts: n/a
 
      10-21-2004
I don't think that will be a problem if the private ranges weren't
overlapping. On packets from inside to outside, nat happens before crypto.
Therefore, you would simply specify the overloaded address as source in the
crypto acl and the private range is the destination.

There is, however, more than one problem. First of all, before nat host a
is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave the
pc and certainly not be directed to the default gateway. If it were to make
it to the router, the router would see 192.168.1.x as a directed connected
and therefore route back out the same interface thus missing the crypto map.

What you could do is overload on the external interface on router a and do a
static nat on router b to a different subnet. Fore example on router b
statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
public you could use that. If you build your crypto acl to reflect the
packets after the nat, all should be fine. The only thing I would caution
is to watch for a situation where nat would only occur in one direction.
There are frequently posts about this.

"ae" <(E-Mail Removed)> wrote in message
news:B7Vdd.8590$(E-Mail Removed) m...
> Hi all
>
> I can't find this information on Cisco.com. Here is the scenario. Hope
> someone can shed some light.
>
> Companies A & B want to establish a VPN tunnel (using Routers A & B).
>
> Router A has the IP address of 100.1.1.1 (external). Its internal network
> has a host (Host A) with a private address of 192.168.1.2.
>
> Router B has the IP address of 200.1.1.1 (external). Its internal network
> also has a host (Host B) with a private address of 192.168.1.2 (same
> address
> as Host A).
>
> Obviously, Companies A & B have identical IP address space. Good thing is
> that only Host A can initiate requests to Host B (application server).
> Host
> B are not allowed to initiate request to Host A.
>
> The requirements are these:
> 1. Traffic between Host A & B must be in VPN tunnel.
> 2. Host A can use Router A's overloaded external address. This way Host B
> sees Host A as having an address of 100.1.1.1 (Router A's address).
>
> Do Cisco routers support this kind of configuration?
>
> Thanks.
>
> Al
>
>



 
Reply With Quote
 
 
 
 
Scooby
Guest
Posts: n/a
 
      10-22-2004
"PES" <NO*SPAMpestewartREMOVE*(E-Mail Removed)*SUCK S> wrote in message
news:41783052$(E-Mail Removed)...
> I don't think that will be a problem if the private ranges weren't
> overlapping. On packets from inside to outside, nat happens before

crypto.
> Therefore, you would simply specify the overloaded address as source in

the
> crypto acl and the private range is the destination.
>
> There is, however, more than one problem. First of all, before nat host a
> is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave

the
> pc and certainly not be directed to the default gateway. If it were to

make
> it to the router, the router would see 192.168.1.x as a directed connected
> and therefore route back out the same interface thus missing the crypto

map.
>
> What you could do is overload on the external interface on router a and do

a
> static nat on router b to a different subnet. Fore example on router b
> statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
> public you could use that. If you build your crypto acl to reflect the
> packets after the nat, all should be fine. The only thing I would caution
> is to watch for a situation where nat would only occur in one direction.
> There are frequently posts about this.
>
> "ae" <(E-Mail Removed)> wrote in message
> news:B7Vdd.8590$(E-Mail Removed) m...
> > Hi all
> >
> > I can't find this information on Cisco.com. Here is the scenario. Hope
> > someone can shed some light.
> >
> > Companies A & B want to establish a VPN tunnel (using Routers A & B).
> >
> > Router A has the IP address of 100.1.1.1 (external). Its internal

network
> > has a host (Host A) with a private address of 192.168.1.2.
> >
> > Router B has the IP address of 200.1.1.1 (external). Its internal

network
> > also has a host (Host B) with a private address of 192.168.1.2 (same
> > address
> > as Host A).
> >
> > Obviously, Companies A & B have identical IP address space. Good thing

is
> > that only Host A can initiate requests to Host B (application server).
> > Host
> > B are not allowed to initiate request to Host A.
> >
> > The requirements are these:
> > 1. Traffic between Host A & B must be in VPN tunnel.
> > 2. Host A can use Router A's overloaded external address. This way Host

B
> > sees Host A as having an address of 100.1.1.1 (Router A's address).
> >
> > Do Cisco routers support this kind of configuration?
> >
> > Thanks.
> >
> > Al
> >
> >

>
>


Personally, I think you could accomplish your goal with a much better
solution...

Create tunnel interfaces on both routers and use an ipsec tunnel between
them. At that point, this is just another interface. You can create
individual nat addresses, use a pool or overload the tunnel interface. With
the tunnel interfaces, you are free to use any addresses you like (recommend
sticking with private address space) which will give you as many addresses
as you need.

My guess is that if the vpn is needed in the first place, then overloading
won't work. Simply because you need to get a particular host on the other
end. So, create static nat items for the ones you need to get to and either
pool or overload the rest - both sides of course.

This can become a difficult solution on the pix, but the IOS routers handle
this solution very well.

Hope that helps,

Jim



 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      10-22-2004
In article <2DYdd.5164$(E-Mail Removed) et>,
Scooby <(E-Mail Removed)> wrote:
|> "ae" <(E-Mail Removed)> wrote in message
|> news:B7Vdd.8590$(E-Mail Removed) m...

|> > Obviously, Companies A & B have identical IP address space.

|> > The requirements are these:
|> > 1. Traffic between Host A & B must be in VPN tunnel.
|> > 2. Host A can use Router A's overloaded external address. This way Host B
|> > sees Host A as having an address of 100.1.1.1 (Router A's address).

|This can become a difficult solution on the pix

The PIX handles the situation relatively cleanly.

The old solution on the PIX was to use the 'alias' command.
The 'alias' command had two different meanings, though, and
has been functionally replaced by new options on static and nat
commands, allowing a finer control.

The new solution on the PIX would be to use "reverse nat" (also called
"bidirectional nat"). On A, one would configure something like,

static (outside, inside) 192.168.2.0 192.168.1.0 netmask 255.255.255.0 dns

Then, to send to B's 192.168.1.N, the user would addres the packet
to 192.168.2.N. As the packet was preparing to cross the outside
interface, the destination IP would be mapped to the corresponding
192.168.1.N IP before being sent over the tunnel to B. The host on
B replies, the response comes through the tunnel, and A then
maps the source address of the reply packet from 192.168.1.N to the
corresponding 192.168.2.N IP before passing the packet on to the
original inside computer. This completes the circuit.

The 'dns' option on the end specifies that if A requests DNS
resolution from a host beyond the outside interface (could be
somewhere on the internet, could be somewhere on B's site),
then if the DNS response contains any IPs in the 192.168.1.N range,
then the PIX will alter the response to be 192.168.2.N instead.

Thus, if there is a DNS server at B that returns 192.168.1
IP addresses for B's hosts, the response will be altered so that
the host at A is handed the right IP to use to get to the resource
on B. If A has a DNS server for its own internal resources
and that DNS server is in the 'inside' or is on any DMZ interface,
and A isn't trying to resolve it's own IP addreses from something
beyond the 'outside' interface, then the 192.168.1.* IP returned
internally or from a DMZ will -not- be changed, and so will
refer to A's resource with that IP.

However, if the DNS servers for A and B are -both- behind
the outside interface relative to A, then you must *not* use the
'dns' option, or else the PIX will know whether any
particular 192.168.1.* address was at A or B, and the PIX will just
go ahead and translate them all as if they were at B. If you are
trying to use overlapping IP ranges with DNS servers that return
the internal 192.168.1.* IP addresses, then you can't do it with
straight-forward DNS configuration and the 'dns' option if the
DNS servers are both outside of 'A' and outside of 'B' as well.
[If the DNS server for A is on the internet and the DNS server
for B is inside B, then you should do the reverse-NAT trick at B instead
of at A.]

If the DNS servers for A and B are both outside relative to A and B
then do not use the 'dns' option: instead, use DNS servers that can
do "split views" (such as bind9), and have it return different
answers depending on whether it sees that A or B are asking the
question.

(IOS runs into the same issues about placement of DNS servers.)

So... on PIX you can often get the desired behaviour by simply
adding a single 'static' to one of the two ends. That's a lot easier
than creating pools and loopback interfaces and whatever else.
--
Caution: A subset of the statements in this message may be
tautologically true.
 
Reply With Quote
 
PES
Guest
Posts: n/a
 
      10-22-2004

"Scooby" <(E-Mail Removed)> wrote in message
news:2DYdd.5164$(E-Mail Removed) nk.net...
> "PES" <NO*SPAMpestewartREMOVE*(E-Mail Removed)*SUCK S> wrote in
> message
> news:41783052$(E-Mail Removed)...
>> I don't think that will be a problem if the private ranges weren't
>> overlapping. On packets from inside to outside, nat happens before

> crypto.
>> Therefore, you would simply specify the overloaded address as source in

> the
>> crypto acl and the private range is the destination.
>>
>> There is, however, more than one problem. First of all, before nat host
>> a
>> is sending from 192.168.1.2 to 192.168.1.2, the packet will never leave

> the
>> pc and certainly not be directed to the default gateway. If it were to

> make
>> it to the router, the router would see 192.168.1.x as a directed
>> connected
>> and therefore route back out the same interface thus missing the crypto

> map.
>>
>> What you could do is overload on the external interface on router a and
>> do

> a
>> static nat on router b to a different subnet. Fore example on router b
>> statically nat 192.168.1.2 to 192.168.2.2. If it is already natted to a
>> public you could use that. If you build your crypto acl to reflect the
>> packets after the nat, all should be fine. The only thing I would
>> caution
>> is to watch for a situation where nat would only occur in one direction.
>> There are frequently posts about this.
>>
>> "ae" <(E-Mail Removed)> wrote in message
>> news:B7Vdd.8590$(E-Mail Removed) m...
>> > Hi all
>> >
>> > I can't find this information on Cisco.com. Here is the scenario. Hope
>> > someone can shed some light.
>> >
>> > Companies A & B want to establish a VPN tunnel (using Routers A & B).
>> >
>> > Router A has the IP address of 100.1.1.1 (external). Its internal

> network
>> > has a host (Host A) with a private address of 192.168.1.2.
>> >
>> > Router B has the IP address of 200.1.1.1 (external). Its internal

> network
>> > also has a host (Host B) with a private address of 192.168.1.2 (same
>> > address
>> > as Host A).
>> >
>> > Obviously, Companies A & B have identical IP address space. Good thing

> is
>> > that only Host A can initiate requests to Host B (application server).
>> > Host
>> > B are not allowed to initiate request to Host A.
>> >
>> > The requirements are these:
>> > 1. Traffic between Host A & B must be in VPN tunnel.
>> > 2. Host A can use Router A's overloaded external address. This way Host

> B
>> > sees Host A as having an address of 100.1.1.1 (Router A's address).
>> >
>> > Do Cisco routers support this kind of configuration?
>> >
>> > Thanks.
>> >
>> > Al
>> >
>> >

>>
>>

>
> Personally, I think you could accomplish your goal with a much better
> solution...
>
> Create tunnel interfaces on both routers and use an ipsec tunnel between
> them. At that point, this is just another interface. You can create
> individual nat addresses, use a pool or overload the tunnel interface.
> With
> the tunnel interfaces, you are free to use any addresses you like
> (recommend
> sticking with private address space) which will give you as many addresses
> as you need.
>
> My guess is that if the vpn is needed in the first place, then overloading
> won't work. Simply because you need to get a particular host on the other
> end. So, create static nat items for the ones you need to get to and
> either
> pool or overload the rest - both sides of course.
>
> This can become a difficult solution on the pix, but the IOS routers
> handle
> this solution very well.
>
> Hope that helps,
>
> Jim
>


I agree, it is cleaner and easier to configure. I was just looking for an
easy out on having to do source and destination nat or having to do source
nat on both ends. My complaint with this is when you start getting complex
with nat and ipsec, you have to be careful to make sure that the statics
apply where you mean for them to or you break communication from the
statically nat'd host to the internet or the vpn depending on the approach.

The difficulty can go as far as actually getting the packet to the router on
each end (with nat disabled). To overcome this, one could do source nat on
both ends, or source and destination nat on one end. However, it must be
said that if there are other static's that nat to public for the hosts in
question, there will be unexpected results. If there are only dynamic
translations on the hosts in questions, they will be over wrote by statics.
This is important when implementing this so there can be a bypass method
using a route-map to a non-nat'd interface or using port translation only on
the static. Therefore, I wanted to use publicly nat'able addresses with the
required translations. Packet filtering can be implemented to make this
only availble from the ipsec encrypted traffic (and hide it from the world).


 
Reply With Quote
 
ae
Guest
Posts: n/a
 
      10-25-2004
Thanks, guys, for the help.

Do you know if Cisco.com has configuration samples with what we just
discussed? I have not found any.

Al


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RARE FILMS ++ RARE MUSIC -- GIALLO , JAPANESE HORROR .... sagooj2002 DVD Video 0 04-25-2005 06:39 PM
VPN, from nat without VPN to nat with it Allan Wilson Cisco 1 07-05-2004 10:51 PM
NAT on DVB based scenario Afshin Cisco 0 10-22-2003 11:09 AM
Configuring VPN through Cisco PIX and ISA Server in Back-to-back scenario Dejan Gambin Cisco 0 10-16-2003 01:53 PM
Re: How to use PIX with NAT in a DMZ Scenario Trond Hindenes Cisco 0 07-22-2003 08:55 AM



Advertisments