Remote access VPN problem due to overlapping address range

Unanswered Question
Mar 2nd, 2009
User Badges:


I have 2 sites, lets say A and B.

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

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

The site to site VPN works without having any problem.

When i build the Remote access vpn on site B with POOL, the firewall automatlically routes the destination traffic 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: DST: traffic which meand site B is routing that traffic to site A.

if i rebuild the site to site VPN like below.

Subnets of without having <>

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)
t4tauseef33 Mon, 03/02/2009 - 05:49
User Badges:

We have offices all around the world. we are based in England with 10 offices throughout the country. we have been allocated 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 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 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
User Badges:

Hi Andrew, is allocated to other country. we can only use 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

route outside <>

Site B:-

access-list <> extended permit ip

route outside <>

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

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

site to site VPN is not having the problem. Remote access vpn has the problem. remote access pool is when it tried to access 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 - THEN the firewall will KNOW that the is LOCALLT attached to itself - the 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
User Badges:

For removing any confusion let me explain according to the configuration

Site A:

Site B:

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

Remote Access POOL:

Summary of configuration


access-list Internet_SDSL-1_cryptomap_1 extended permit ip

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- mask

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

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

address-pool POOL-

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
User Badges:
  • Silver, 250 points or more

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
User Badges:

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
User Badges:
  • Silver, 250 points or more

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.


This Discussion