Re: Multi Client VPNs with Overlapping Networks - Page 3

toddmanger · ‎05-05-2010

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

toddmanger · ‎05-07-2010

ok....there is one additional problem. I do not know that the other peer has been correctly setup. I gave him 173.210.58.197 as my peer because initially, all my L2L vpns were going to be on one router. To test this one and limit breaking down the other tunnels, I used another router to test (173.210.58.198).

If we can verify that this looks the way it should, I can load it onto the production router and test. I can also change this routers public ip to .197 for a quick test.

interface: FastEthernet0/1
Crypto map tag: VPN, local addr 173.210.58.198

   protected vrf: (none)
   local ident (addr/mask/prot/port): (10.129.40.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.10.131.63/255.255.255.255/0/0)
   current_peer 12.195.64.10 port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 5, #recv errors 0

     local crypto endpt.: 173.210.58.198, remote crypto endpt.: 12.195.64.10
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x0(0)

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:
RH2811C#

Federico Coto Fajardo · ‎05-07-2010

Correct,

The peer should not point to 173.210.58.197 but to 173.210.58.198 (or change the IP)

The ACLs look fine now, let us know if you can test the connection.

Federico.

toddmanger · ‎05-07-2010

ok...i changed this routers ip address to .197 (what the peer should be configured for) and ran a

ping from 10.10.10.68 and then did a sh cryp ips sa and got this: Doesnt look like the tunnel is coming up:

RH2811C#sh crypto ipsec sa

interface: FastEthernet0/1
Crypto map tag: VPN, local addr 173.210.58.197

   protected vrf: (none)
   local ident (addr/mask/prot/port): (10.129.40.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.10.131.63/255.255.255.255/0/0)
   current_peer 12.195.64.10 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 4, #recv errors 0

     local crypto endpt.: 173.210.58.197, remote crypto endpt.: 12.195.64.10
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x0(0)

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:
RH2811C#

Federico Coto Fajardo · ‎05-07-2010

It seems that everything is fine up to the point where the traffic should get encrypted.
The Security Association for phase 2 shows the correct traffic between 10.129.40.0/24 and 10.10.131.63/32
The problem is that the same thing we saw when the router's IP was .198
You're sure the remote end is pointing to the .197 IP?

Could you try to bring the tunnel down on both sides and try to re-establish it?

Federico.

toddmanger · ‎05-07-2010

No, I am not sure that the end point is configured correctly as I have not been able to reach their network admin (

to add more frustration to this). But I will be verifying with him on Monday, and I will let you know.

Thank you so much for all of your help with this. Now that I see the finished config, i cant believe I was missing it.....once we get this up and running, let me know where I can send a bottle of (insert favorite beverage here) to thank you properly.

Todd

Federico Coto Fajardo · ‎05-07-2010

Thank you Todd ;-)

Let me know when you check with the other side so we can test the tunnel.

Federico.

toddmanger · ‎05-10-2010

Good morning.

UPDATE:

I have the tunnel established, but I am not able to connect to the host inside my clients network. Thoughts on what I should be looking for?

Federico Coto Fajardo · ‎05-10-2010

Todd,

If the VPN is establishing correctly, check the following:

Output of the command ''sh cry ips sa''

Make sure you have packets encrypted/decrypted for the networks on both sides of the tunnel.

For example, the output should show both packets encrypted and decrypted.

If you only see encrypted it means your side is sending packets but not receiving and if you see only decrypted is the other way around.

From there we can see where the problem is.

Federico.

toddmanger · ‎05-10-2010

Federico,

Thank you for the help. I did get it working. Config posted below. Notice the route statements.

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key Meds01GhD! address 12.195.64.10
crypto isakmp keepalive 10
!
crypto ipsec security-association lifetime seconds 86400
!
crypto ipsec transform-set MEDSOLUTIONS esp-3des esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 12.195.64.10
set transform-set MEDSOLUTIONS
match address MEDSOL-CRYPTO-ACL
!
!
!
!
interface FastEthernet0/0
description INSIDE LAN INTERFACE
ip address 10.10.10.3 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex full
speed 100
!
interface FastEthernet0/1
ip address 173.210.58.198 255.255.255.240
ip nat outside
ip virtual-reassembly
duplex full
speed 100
crypto map VPN
!
interface ATM0/0/0
no ip address
shutdown
no atm ilmi-keepalive
dsl operating-mode auto
!
ip route 10.10.131.63 255.255.255.255 12.195.64.10
ip route 12.195.64.10 255.255.255.255 173.210.58.193
!
!
ip http server
ip http authentication local
no ip http secure-server
ip nat pool MEDSOL 10.129.40.1 10.129.40.254 netmask 255.255.255.0
ip nat inside source route-map MEDSOLUTIONS pool MEDSOL
!
ip access-list extended MEDSOL-CRYPTO-ACL
permit ip 10.129.40.0 0.0.0.255 host 10.10.131.63
ip access-list extended MEDSOL-NAT-ACL
deny ip 10.129.40.0 0.0.0.255 host 10.10.131.63
permit ip 10.10.10.0 0.0.0.255 host 10.10.131.63
!
!
route-map MEDSOLUTIONS permit 10
match ip address MEDSOL-NAT-ACL
!

Federico Coto Fajardo · ‎05-10-2010

Todd,

Is it working fine now?

In theory you don't need this route:

ip route 10.10.131.63 255.255.255.255 12.195.64.10

You would need this:

ip route 10.10.131.63 255.255.255.255 173.210.58.193
ip route 12.195.64.10 255.255.255.255 173.210.58.193

But anyway, is it working now?

Federico.

toddmanger · ‎05-10-2010

Federico,

It is working now. I know I shouldnt need that route, but removing either of them drops the tunnel. I thought it may be because the 12.x.x.x. peer is not a public IP address, but I will try routing both to my public as you intimated.

Thanks

Todd

Federico Coto Fajardo · ‎05-10-2010

Todd,

I'm not suggesting you to do it ;-)

But if you delete this route:

ip route 10.10.131.63 255.255.255.255 12.195.64.10

Everything should continue working because traffic to 10.10.131.63 will fall into the default gateway and worked.

In theory the above route it is not doing anything, because you don't have a next-hop of 12.195.64.10, is just the VPN peer address.

Anyway, glad that it is working ;-)

Federico.