Multi Client VPNs with Overlapping Networks

[toddmanger]

I have a need to have several L2L vpns to different clients.  I have built the vpns under a single crypto map, but an issue has come up.

One of my clients requires me to NAT my inside address to my public address as he shares the same LAN subnet as I do.

Another of my clients shares the same subnet and wants me to NAT my internal IP to a specific subnet address within the same network.

How do I accomplish this?  I basically need to NAT my inside 10.10.x.x network for client B to 10.129.x.x.

I assume I will be using NAT ( ip nat inside source static network 10.10.x.x 10.129.x.x /24), but is there anyway to specify this nat statement for only this customer?  I assume any new customers will require similar juggling.

TIA

[Federico Coto Fajardo]

Todd,

You can assign a route-map to the STATIC NAT to specify the rule to take place only when going to an specific customer

ip nat inside source static network 10.10.x.x 10.129.x.x /24 route-map Customer_1

route-map Customer_1

  match ip address 199

  set ip next-hop x.x.x.x

The above STATIC NAT will only happens when ACL 199 matches the traffic (so you can specify the network to the remote VPN).

Federico.

[toddmanger]

Thank you Federico,

I can do this for each unique situation?  So I could conceivably have many NAT statements as indicated above, each pointing to a different Route-map?

Thanks again.

[Federico Coto Fajardo]

Yes, and not necessarily a different route map, but a different ACL to properly identify the

traffic.

Federico.

[toddmanger]

I hate to ask, but could I bother you for a short config example?  I am afraid I am a little out of my

league with this.

Thank you

[Federico Coto Fajardo]

No problem, for example:
Let's say that you have two tunnels with two sites:

Your side:
192.168.1.0/24
Remote side1:
192.168.2.0/24
Remote side2:
192.168.3.0/24

You want to NAT your traffic to 10.1.1.0/24 when going to side1 and to 10.2.2.0/24 when going to side2.

ip access-list extended 198
  permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
ip access-list extended 199
  permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

route-map Customer_1
  match ip address 198
  set ip next-hop x.x.x.x
route-map Customer_2
  match ip address 199
  set ip next-hop x.x.x.x

ip nat inside source static 192.168.1.0/24 10.1.1.0/24 route-map Customer_1
ip nat inside source static 192.168.1.0/24 10.2.2.0/24 route-map Customer_2

Then, the interesting traffic will be from 10.1.x.0/24 to the remote sites.

Federico.

[toddmanger]

OK,

I have tried to get this configured and I cannot get the tunnel to come up.  I am including a scrubbed config if you wouldnt mind taking a look.

Current configuration : 2993 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname RH2811-B
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
logging buffered 52000
enable secret xxxxxxxxxxxxxxxxxx
enable password xxxxxxxxxxxxxxxxxx
!
aaa new-model
!
!
aaa authentication login userauthen local
!
!
aaa session-id common
no network-clock-participate wic 0
!
dot11 syslog
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
ip cef
!
!
no ip domain lookup
!
no ipv6 cef
multilink bundle-name authenticated
!
voice-card 0
no dspfarm
!
archive
log config
  hidekeys
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key 6 XXXXXXXXX address 206.xx.xx.xx
crypto isakmp key XXXXXXXXXX address 12.xx.xx.xx
crypto isakmp keepalive 10
!
crypto ipsec security-association lifetime seconds 86400
!
crypto ipsec transform-set VPN1-VPN esp-3des esp-sha-hmac
crypto ipsec transform-set VPN2-VPN esp-3des esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 206.xx.xx.xx
set transform-set VPN1-VPN
match address 100
crypto map VPN 2 ipsec-isakmp
set peer 12.xxx.xx.xx
set transform-set VPN2-VPN
match address 101
!
!
!
controller T1 0/0/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24

interface FastEthernet0/0
description GHDSI INTERNAL LAN
ip address 10.10.xxx.xxx 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex full
speed 100
no mop enabled
!
interface FastEthernet0/1
description GHDSI EXTERNAL WAN
ip address 173.xxx.xxx.xxx 255.255.255.240
ip nat outside
ip virtual-reassembly
duplex full
speed 100
crypto map VPN
!
interface Serial0/0/0:0
description QWEST INTERNET CIRCUIT ID# DS1IT 14436097
no ip address
ip virtual-reassembly
shutdown
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 173.xxx.xxx.xxx
!
!
ip http server
no ip http secure-server
ip nat inside source route-map VPN1 interface FastEthernet0/1 overload
ip nat inside source static 10.10.xxx.xxx 10.129.40.0 route-map VPN2MAP
!
no logging trap
access-list 100 permit ip any any
access-list 100 permit icmp any any echo
access-list 100 permit icmp any any echo-reply
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any administratively-prohibited
access-list 101 permit ip any any
!
!
!
!
route-map VPN1 permit 10
match ip address 100
!
route-map VPN2 permit 10
match ip address 101
!
!
!
!
control-plane
!
line con 0
line aux 0
line vty 0 4
privilege level 15
password 7 0045120209520547
transport input telnet
!
scheduler allocate 20000 1000
end

Any help is greatly appreciated.

[Federico Coto Fajardo]

Some questions:

1. Which tunnel is not coming up? I see two (206.xx.xx.xx and 12.xxx.xx.xx)
2. For the first peer, you're sending all IP traffic (ACL 100), in this way no traffic will ever be sent
through the second tunnel.
3. The route-map VPN2MAP does not show in the config.

Federico.

[toddmanger]

The first peer (VPN 1) is up and works.  The second peer (VPN 2) going to the

12 network will not come up.  This is the peer that requires that my 10.10.x.x network be NAT'd to 10.149.20

.x prior to sending.

[Federico Coto Fajardo]

Todd,

One of the problems is that the ACL for interesting traffic for the first tunnel is sending ''ip any any''

It means that all IP traffic is being sent through the tunnel that is already established.

There's no traffic that's going to be sent through the second tunnel.

What you need to do is:

1. Define only the interesting traffic that should be sent through the first tunnel (only between the appropiate networks)

2. Define the traffic for the second tunnel as well.

Federic0.

[toddmanger]

Thank you for the additional help and please excuse my ignorance.

What should that acl look like?  permit ip MY INSIDE ADDRESS SUBNET to CUSTOMER INSIDE ADDRESS SUBNET or CUSTOMER PEER IP?

[Federico Coto Fajardo]

The crypto ACL should be a different ACL that the NAT ACL.

The crypto ACL (to define the VPN traffic) should be from your internal LAN to the remote LAN. On the remote end it should be a mirror.

The NAC ACL should define which traffic to NAT or to bypass NAT.

So, if your network is 1.1.1.0/24 and the remote network is 2.2.2.0/24

The crypto ACL should be:

access-list 170 permti ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255

And the NAT ACL should be:

access-list 160 deny ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255

(In case you want the traffic through the tunnel to bypass NAT)

If you want to NAT the traffic, then the NAT ACL should be defined as permit (and the interesting traffic will not be sourced from the real internal LAN, but from the NATed IPs)

Federico.

[toddmanger]

Does this look a little better?

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname RH2811-B
!
boot-start-marker
boot-end-marker
!
logging buffered 52000 debugging
no logging console
enable secret 5 $1$dd6D$n9e1IAQ54XJLMOYtMBwO31
enable password 7 015207005602084E
!
archive
log config
  hidekeys
!
!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key 6 GHdsI2^hE@lthD address 206.17.98.20
crypto isakmp key Meds01GhD! address 12.195.64.10
crypto isakmp keepalive 10
!
crypto ipsec security-association lifetime seconds 86400
!
crypto ipsec transform-set HEDI-VPN esp-3des esp-sha-hmac
crypto ipsec transform-set MEDSOLUTIONS-VPN esp-3des esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 206.17.98.20
set transform-set HEDI-VPN
match address HEDI-CRYPTO-ACL
crypto map VPN 2 ipsec-isakmp
set peer 12.195.64.10
set transform-set MEDSOLUTIONS-VPN
match address MEDSOLUTIONS-CRYPTO-ACL
!
!
!
!
interface FastEthernet0/0
description GHDSI INTERNAL LAN
ip address 10.10.10.28 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex full
speed 100
no mop enabled
!
interface FastEthernet0/1
description GHDSI EXTERNAL WAN
ip address 173.210.58.197 255.255.255.240
ip nat outside
ip virtual-reassembly
shutdown
duplex full
speed 100
crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 173.210.58.193
ip route 12.195.64.10 255.255.255.255 173.210.58.193
!
!
ip http server
no ip http secure-server
ip nat inside source route-map HEDI interface FastEthernet0/1 overload
ip nat inside source static 10.10.10.0 10.129.40.0 route-map MEDSOLUTIONS
!
ip access-list extended HEDI-CRYPTO-ACL
permit ip 173.210.58.0 0.0.0.255 206.17.98.0 0.0.0.255
ip access-list extended HEDI-NAT-ACL
permit ip 10.10.10.0 0.0.0.255 10.100.0.0 0.0.255.255
ip access-list extended MEDSOLUTIONS-CRYPTO-ACL
permit ip 10.10.10.0 0.0.0.255 12.195.64.0 0.0.0.255
ip access-list extended MEDSOLUTIONS-NAT-ACL
permit ip 10.129.40.0 0.0.0.255 10.10.131.0 0.0.0.255
!
no logging trap
snmp-server community ghdsi_public RO
!
route-map HEDI permit 10
match ip address HEDI-CRYPTO-ACL
!
route-map MEDSOLUTIONS permit 10
match ip address MEDSOLUTIONS-CRYPTO-ACL
!
!
!
!
control-plane
end

[Federico Coto Fajardo]

Exactly, it looks a lot better.

Are you able to establish both tunnels?

Federico.

[toddmanger]

I have not yet established the tunnels because the first peer is operational in production right now and being used, so I

wanted to make sure that i had the config completely correct before loading it.

Does everything else look ok to you?

Basically, Peer 1 (VPN 1) needs my internal address nat'd to my public address prior to being encrypted, and currently it is working the way it is setup.  Of course, the permit ip any any guarantees that, but also exludes getting the second tunnel properly setup.

Peer 2 (VPN 2) needs to have my internal address nat'd to 10.139.40.0 prior to being encrypted and sent to his network.  The only host in his network that i need to talk to is 10.10.131.63.

Thanks again for all your help.

Todd