Remote access VPN problem due to overlapping address range

Unanswered Question
Mar 2nd, 2009

Hi,


I have 2 sites, lets say A and B.


I am using private address range 172.16.0.0/16 in different locations at Site A but not using the 172.16.64.0/23 in Site A. So i am using 172.16.64.0/23 in site B.



I have build the site to site VPN between the site A and Site B.


172.16.0.0/16 <> 172.16.64.0/23



The site to site VPN works without having any problem.


When i build the Remote access vpn on site B with POOL 172.16.65.1-10, the firewall automatlically routes the destination traffic 172.16.0.0/16 to site A due to existing site-to-site VPN. So from remote access VPN terminated on site B, i cannot access site B subnets but can access site A subnets without any problem. on site A firewall, i can see the SRC: 10.16.65.1 DST: 10.16.64.1 traffic which meand site B is routing that traffic to site A.


if i rebuild the site to site VPN like below.


Subnets of 172.16.0.0/16 without having 172.16.64.0/23 <> 172.16.64.0/23


Remote access VPN works straight away.


Can you please tell me how can i solve this problem? Is there any way to prioritize the remote access vpn over site to site for routing purpose?


your help in this case will be highly appriciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
t4tauseef33 Mon, 03/02/2009 - 05:49

We have offices all around the world. we are based in England with 10 offices throughout the country. we have been allocated 172.16.0.0/16 by our headquarter for this country. we are using the address space as required for projects / requirements and now we have opened 11th site in england and we have few addresses left and in which 172.16.64.0/23 is one of them.


Actually Site A (main office in England) is also very big consisting of 5 firewalls with isolated/independent/firewalled subnets. thats why 172.16.0.0/16 is almost full. The Site A is acting as hub for many other sites.


At the moment we cannot change the subnet address range for site B due to critical services running on it. Is there any option that we can give priority to remote access VPN or any other way.

t4tauseef33 Mon, 03/02/2009 - 06:17

Hi Andrew,


172.17.0.0/24 is allocated to other country. we can only use 172.16.0.0/16 in our sites in england.


site to site VPN's doesnot have any problem but only the remote access. you can say that i cannot change the remote access subnet on site B due to routing. otherwise remote access client will not be able to access the servers at other countries. Any solution other than that.?


It seems strange to me that why Site B firewall routes the destination site B directly connected subnets to site A over the site to site VPN. directly connected subnets always takes precedence over any other traffic.

OK - can I assume that your encryption domain config looks something like:-


Site A:-


access-list <> extended permit ip 172.16.0.0 255.255.0.0 172.16.64.0 255.255.252.0


route outside 172.16.64.0 255.255.252.0 <>


Site B:-


access-list <> extended permit ip 172.16.64.0 255.255.252.0 172.16.0.0 255.255.0.0


route outside 172.16.0.0 255.255.0.0 <>


An the "inside" interfaces at both sites have teh correct IP Subnet Mask??

t4tauseef33 Mon, 03/02/2009 - 06:50

site to site VPN is not having the problem. Remote access vpn has the problem. remote access pool is 172.16.65.0/28. when it tried to access 172.16.64.0/24 that is locally connected to firewall, traffic is routed to site A through site to site VPN.

How is that even possible?


If you have the "inside" interface 172.16.64.x/24


With a local IP pool of 172.16.65.0/28 - THEN the firewall will KNOW that the 172.16.65.0/28 is LOCALLT attached to itself - the 172.16.0.0/24 route to site A is a less specific route that 172.16.65/28 - why would it route it to site A?


Can you post your firewall config for review - remove all sensitive information.



t4tauseef33 Mon, 03/02/2009 - 07:50

For removing any confusion let me explain according to the configuration


Site A: 172.16.0.0/16

Site B: 172.16.64.0/21


Remote VPN Profile Name: Company-Name-Site-B


Remote Access POOL: 172.16.69.50-100


Summary of configuration

*************************************


access-list Internet_SDSL-1_cryptomap_1 extended permit ip 172.16.64.0 255.255.248.0 172.16.0.0 255.255.0.0



crypto map Internet_SDSL-1_map1 1 match address Internet_SDSL-1_cryptomap

crypto map Internet_SDSL-1_map1 1 set pfs

crypto map Internet_SDSL-1_map1 1 set peer *************

crypto map Internet_SDSL-1_map1 1 set transform-set ESP-3DES-SHA

crypto map Internet_SDSL-1_map1 1 set security-association lifetime seconds 28800

crypto map Internet_SDSL-1_map1 1 set security-association lifetime kilobytes 4608000



ip local pool POOL-172.16.69.0 172.16.69.50-172.16.69.100 mask 255.255.255.0



tunnel-group Company-Name-Site-B type remote-access

tunnel-group Company-Name-Site-B general-attributes

address-pool POOL-172.16.69.0

authentication-server-group NT-Domain

default-group-policy Company-Name-Site-B

tunnel-group Company-Name-Site-B ipsec-attributes

pre-shared-key *



************


How can i attach the file to this?

adamclarkuk_2 Mon, 03/02/2009 - 06:03

Hi ( Sorry jon.marshall, I know your not a fan of NAT but................)


You could use source NAT based on destination address before you send the traffic down the IPSec tunnel (Site B) so that is is unique at the other end (Site A). Then inject the subnet you are natting into the IGP at both ends so routing is handled.


I'm not proud to admit it, but a solution I have used in this sort of situation where NAT at one end was not possible was to terminate the IPSec tunnel into a VRF, NAT within the VRF and then route it into the global routing table as unique address space. When the traffic returns, the NAT table handles the reverse an routes it back.


You need to use NVI and not inside/outside domains for that to work.



t4tauseef33 Mon, 03/02/2009 - 06:24

Hi Adam,


Problem is not at site A. From the Site B, remote access traffic to site B subnets is routed to site A due to site to site VPN. The site B firewall should not route the remote access traffic to site A that is destined to its local subnets.

adamclarkuk_2 Mon, 03/02/2009 - 06:33

Then flip what I said around I guess so A is unique with the Site B domain. You could even do a 1 - 1 mapping based on the first x octets so all IP's are unique at both ends ?


Otherwise you will need to match only the networks outside of your /23 in your crypto ACL with a load of /23 after your block at Site B.


I guess the easier way would be to match only the networks that are needed and add more as necessary to the crypto ACL's, then local traffic will not be routed down the VPN tunnel.

Actions

This Discussion