Solved: Re: VPN clients cannot access remote sites - PIX routing issue?

mitchen · ‎09-23-2005

I have an issue with routing to our company's remote sites when users connect via their VPN client remotely (i.e. for home workers)

Our head office contains a PIX 515E firewall. A number of remote sites connect (via ADSL) to the head office using IPSEC tunnels, terminating on the PIX.

Behind the PIX, sits a 7206 router with connections to the head office LANs and connections to a number of ISDN connected remote sites. The default route on the 7206 points to the PIX firewall i.e. traffic from head office to the remotely connected ADSL sites goes via the PIX. Traffic for the internal LANs and the ISDN connected sites goes via the 7206.

All well and good and works fine.

When a user connects remotely using their VPN client (connection terminates on the PIX) then they get an IP address from the pool configured on the PIX and they can access resources located on the Head Office LANs without any problems.

However, the problem arises when a remote user wants to access a server located at one of the ADSL connected remote sites - they cannot access these sites at all.

On the remote site routers, I've configured the access lists to allow access from the IP address pool used by the PIX. But this hasn't made any difference. I think the problem may be the routes configured on the PIX itself but I'm not sure what is required to resolve this.

Does anyone have any suggestions on what needs to be done to allow access to the remote sites for users connected remotely over the VPN?

(Note: as a workaround, I've suggested the users can use a server located on the head office LAN as a "jump point" to connect to the remote office servers from there)

jackko · ‎09-24-2005

with pix v6, no traffic is allowed to re-route back to the same interface.

e.g. a remote user initiates a rdp session destinated at one of the adsl sties. pix decrypts the packet arriving the outside interface and looks at the destination. since the destination is one of the adsl sites, pix will need to send the traffic back to the outside interface. unfortunately, pix v6.x has a limitation that would force the pix to drop the packet.

with v7, this limitation has been removed with the command "same-security-traffic permit intra-interface".

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_configuration_example09186a008046f307.shtml

View solution in original post

jackko · ‎09-24-2005

with pix v6, no traffic is allowed to re-route back to the same interface.

e.g. a remote user initiates a rdp session destinated at one of the adsl sties. pix decrypts the packet arriving the outside interface and looks at the destination. since the destination is one of the adsl sites, pix will need to send the traffic back to the outside interface. unfortunately, pix v6.x has a limitation that would force the pix to drop the packet.

with v7, this limitation has been removed with the command "same-security-traffic permit intra-interface".

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_configuration_example09186a008046f307.shtml

mitchen · ‎09-26-2005

Thanks for the info, thats what I suspected but its good to have it confirmed. And, at least we can remove this limitation if we upgrade our PIX software to v7!

allanl · ‎10-23-2005

Hi,

Wonder if the above senario can be applied to ios ipsec as well? I have 2 offices with a site to site tunnel up, the vpn client would log into the HQ and I would wish that the client vpn could access to the remote office via the site to site tunnel.

jackko · ‎10-23-2005

kin,

i guess the configuration is less complicated with routers, as routers don't have the "no re-route back to same interface" rule.

basically, when configuring the crypto acl for vpn client on hq router, just including the remote office subnet as well as the hq subnet.

e.g.

net1 <--> hq rt <--> www/lan-lan vpn <--> branch rt <--> net2

net1 <--> hq rt <--> www/remote vpn <--> remote pc

on the hq rt,

access-list no_nat permit ip

access-list l2l_vpn permit ip

access-list remote_vpn permit ip

on the brach rt,

access-list no_nat permit ip

access-list all_vpn permit ip

also have a look at the configuration example (though it's not exactly the same scenario):

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080093dc8.shtml#table1

allanl · ‎10-24-2005

Hi Jakko,

I need this solution as well,some doubts to clear on your config,

On HQ Rt,

the vpn client pool, does it refer to the virtual ip pool of net 1 stated in cmd 'ip local pool'. And does it matter its not in the range of the net1 subnet.

On Branch Rt,

the vpn client pool, does it refer to the virtual ip pool of net 2 stated in cmd 'ip local pool'. And does it matter its not in the range of the net2 subnet.

Lastly if both the HQ and Remote virtual pool does not need to be the same as the local subnet respectively, do they need to be in the same subnet themselves, eg. net1 virtual pool 10.10.10.1-100, met2 10.10.10.101-200.

An example would be helpful

jackko · ‎10-25-2005

yes, the vpn client pool refers to the command "ip local pool". in fact, the ip range specified by this command will assign to remote pc that established a remote vpn connection.

with branch router, i guess there is no "ip local pool" configured unless the branch router itself is supporting remote vpn client as well.

vpn client pool should not be the same as any existing subnet.

further, having a second thought, the additional no_nat may not be required as the vpn client traffic just get in/out on the router outside interface.

below is an example.

on the hq router,

crypto isakmp client configuration group vpngroup

key xxxxxxxx

pool vpnpool

acl remote_vpn

ip local pool vpnpool 10.1.1.1 10.1.1.10

access-list no_nat deny ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list no_nat deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list no_nat permit ip 192.168.1.0 0.0.0.255 any

access-list remote_vpn permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list remote_vpn permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list lan_vpn permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list lan_vpn permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255

on the branch router,

access-list no_nat deny ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list no_nat deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list no_nat permit ip 192.168.2.0 0.0.0.255 any

access-list lan_vpn permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list lan_vpn permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

allanl · ‎10-26-2005

Great Jakko,

I've tried the config u provided, it works, thks.

But I tried setting up vice-versa at the remote it doesn't work.

What I'm having is RouterA site2sitetunnel RouterB,

Both Router has vpn client profile login the Routers,

Now I'm able to vpnclient login to RouterA , from which I can access LanA and LanB.

But When I login to RouterB I can only access LanB but not LanA.

Is this feasible? What do I have to take note?

jackko · ‎10-26-2005

with router b, again the current config would have "ip local pool", which should be different to all other subnets.

crypto isakmp client configuration group vpngroup

key xxxxxxxx

pool vpnpool

acl remote_vpn

ip local pool vpnpool 10.2.2.1 10.2.2.10

access-list no_nat deny ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list no_nat deny ip 192.168.2.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list no_nat deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list no_nat permit ip 192.168.2.0 0.0.0.255 any

access-list remote_vpn permit ip 192.168.2.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list remote_vpn permit ip 192.168.1.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list lan_vpn permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list lan_vpn permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list lan_vpn permit ip 10.2.2.0 0.0.0.255 192.168.1.0 0.0.0.255

on the router a,

access-list no_nat deny ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list no_nat deny ip 192.168.1.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list no_nat deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list no_nat permit ip 192.168.1.0 0.0.0.255 any

access-list remote_vpn permit ip 192.168.1.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list remote_vpn permit ip 192.168.2.0 0.0.0.255 10.1.1.0 0.0.0.255

access-list lan_vpn permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list lan_vpn permit ip 192.168.1.0 0.0.0.255 10.2.2.0 0.0.0.255

access-list lan_vpn permit ip 10.1.1.0 0.0.0.255 192.168.2.0 0.0.0.255

allanl · ‎10-26-2005

Wonderful I'll try this, my config for vpn pool A is 172.16.100.0 0.0.0.255 and vpn pool B is 172.16.110.0 0.0.0.255, looks like its different subnet but it doesn't work from B to A.

When I do a show a ip route on Router A when a client is login, it actually shows 172.16.0.0 as a subnet although already specify 0.0.0.255 as the wildcard. Nevertheless let me try your config 1st

allanl · ‎10-26-2005

Hi Jakko,

The whole solution works now, I can access all Lan subnet when I log into any Router.

jackko · ‎10-27-2005

it's good to learn that your issue has been resolved.

according to cisco,

Why should I rate posts?

If you see a post that you think deserves recognition, please take a moment to rate it.

You'll be helping yourself and others to quickly identify useful content -- as determined by members. And you'll be ensuring that people who generously share their expertise are properly acknowledged. As posts are rated, the value of those ratings are accumulated as "points" and summarized on the Member Profile page and on each member's Preferences page.