site to site vpn with internal NAT

Hello.

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?

Thanks.

Reply to
Meni
Loading thread data ...

Hello.

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?

Thanks.

Reply to
Meni

In article , Meni 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.
Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.