Re: site to site vpn with internal NAT
- From: roberson@xxxxxxxxxxxxxxxxxx (Walter Roberson)
- Date: Thu, 10 Nov 2005 21:43:02 +0000 (UTC)
In article <1131656242.987765.16140@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Meni <meni.milstein@xxxxxxxxx> wrote:
:I have a PIX 501.
:inside network = 192.168.1.0 255.255.255.0.
:I need to create a site to site IPSEC VPN through the external
:interface.
:on the remote side, there's already a LAN with 192.168.1.0, so they
:asked me to configure an internal NAT in my system so that when my
:192.168.1.101 tries to contact a peer on the remote side, he will be
:identified as 192.168.48.49.
:Is this possible? if so - how?
It is possible, but usually it's better to simply renumber yourself
and avoid the problem.
name 192.168.1.0 Our_Shared_Net
name 192.168.1.101 Our_host_allowed_out
name 192.168.48.49 Our_VPN_external_IP
name 192.168.49.0 Stand_in_Net
access-list VPN_acl permit ip host Our_VPN_external_IP Our_Shared_Net 255.255.255.0
access-list VPN_nat_acl permit ip host Our_host_allowed_out Stand_in_Net 255.255.255.0
crypto map TheMap 100 match address VPN_acl
nat (inside) 2 access-list VPN_nat_acl
global (outside) 2 Our_VPN_external_IP
: note reversed interfaces!!
static (outside,inside) Stand_in_Net Our_Shared_Net netmask 255.255.255.0 dns
In order for this to work, when you want to send to *their* 192.168.1.x
you instead send to 192.168.49.x . When you do that from 192.168.1.101
then the source and destination will match VPN_nat_map, so nat 2
will take effect on the *source* address (192.168.1.101) translating
the *source* into 192.168.48.49.
Meanwhile on the outgoing packets, the reversed static will be seen
so the *destination* IP 192.168.49.x will be changed to the destination
192.168.1.x .
It is this altered packet, now source 192.168.48.49 and
destination 192.168.1.x that will be matched against the VPN_acl
and since there is a match, the packet will go out over the VPN.
When a reply packet arrives, the -source- on it will be
192.168.1.x and the destination will be 192.168.48.49. This packet
will see the reversed static, so it will map the -source-
from 192.168.1.x to 192.168.49.x. The normal PAT process will
see the destination 192.168.48.49 in its tables, so it will back-map
it to the original 192.168.1.101 source IP. The revised packet will
have source 192.168.49.x and destination 192.168.1.101 and will
be delivered through. And when the inside host goes to reply to that,
it is all set up for the other half of the cycle.
It is important to understand here that you cannot just map your
outgoing IP into the IP they ask for, because when they send replies
back to you, unless they are changing the IP addresses on them as
they go out, the source IP received by you is going to be the
192.168.1.x IP that is meaningful in -their- network. You can't just
let that through because if you were to try to reply to that, you'd
be trying to deliver locally instead of back to the originator.
Also, this particular configuration is constructed so that your
host 192.168.1.101 can start connections to any host in their
192.168.1.x, but that they cannot start any connection back to you.
If you need them to be able to start connections back to you
(including because you might have UDP flows with pauses long enough
for the PIX to think the flow has expired... 2 minutes by default),
then you need to use a "policy static" instead of a nat/global pair.
--
Chocolate is "more than a food but less than a drug" -- RJ Huxtable
.
- References:
- site to site vpn with internal NAT
- From: Meni
- site to site vpn with internal NAT
- Prev by Date: Re: ( don't ) use CiscoVMS to configure PIX firewalls.
- Next by Date: Re: Newbie ACL Help on Cisco Switch
- Previous by thread: site to site vpn with internal NAT
- Index(es):
Relevant Pages
|
|
