How to permit a VPN client user to reach distant networks

[andre even]

Hi,

I have a case with a customer who has a cluster of two ASA 5510 running 8.4.7.

Until now the remote access clients through IPsec tunnel were communicating

with the internal network of Site A: 192.1.1.0/24.

Now the customer would like that the clients connected toSite A with an IP address in the

pool 192.168.1.1-100 could also communicate with the internal network of Site B: 172.16.1.0/24.

- So first i think that by adding the 'reverse route' i will have the return route on site A for the VPN pool addresses

" crypto dynamic-map DynoMap 10 set reverse route"

- Then i have to add the 192.168.1.0 in the NAT command to the current one

nat (inside,outside) source static 192.1.1.0 192.1.1.0 destination static 172.16.1.0 172.16.1.0 no-proxy-arp

- and modify the current access-list:

access-list outside_cryptomap extended permit ip 192.1.1.0  172.16.1.0

The connections will only be  initiated from Site A so on site B i have just to ask to the administrator

to indicate how to reach network 192.168.1.0 through Outside interface IP address of Site A.

Does it make sense what i propose or is there a solution more adapted.

It would be easier if the remote clients could ditectly connect to Site B but it isn't authorized.

Best regards.

Andre                

[Jouni Forss]

Hi,

You wond need the "reverse-route" parameter in the dynamic map. This is only needed if you had dynamic routing running from the VPN ASA to some other devices. The ASA automatically add a route for the VPN Clients IP address allocated by the ASA to its local routing table.

Also the "nat" configuration is not exactly what you would need. The VPN Pool IP address seems to be wrong and the interfaces are wrong.

You would be doing a NAT from "outside" to "outside" as the "outside" interface is the only interface on the ASA that would be handling the traffic.

So the configuration would be something like this

object network VPN-POOL

subnet 192.168.1.0 255.255.255.0

object network SITE-B

subnet 172.16.1.0 255.255.255.0

nat (outside,outside) source static VPN-POOL VPN-POOL destination static SITE-B SITE-B

In this case it would also be good to check if you have enabled the traffic to enter and leave the same interface on this ASA which holds both the L2L VPN and Client VPN.

You would need the command

same-security-traffic permit intra-interface

You can check this with the command

show run same-security-traffic

The Crypto ACL addition is ok except for the typo again. You would be sourcing the traffic from 192.168.1.0/24 and destination would be 172.16.1.0/24. You would naturally need the reverse version of this on the Site B VPN device so it knows the network 192.168.1.0/24 behind the L2L VPN connection to the Site A ASA.

So in short you need

• The "nat" configuration from "outside" to "outside"
• Enable the traffic to take U-turn on the "outside" interface with the command mentioned above
• Add the VPN Pool as the source address in the Crypto ACL for destination network Site B. Do the reverse addition on the Site B

If you did not want to touch the Site B configurations you could actually do Dynamic PAT for the VPN Pool 192.168.1.0/24 to some existing address configured as source for the L2L VPN. This would enable connectivity to the Remote site without any changes at that site.

Hope this helps

- Jouni

[Jouni Forss]

Ah,

I just noticed right after posting that the 192.1.1.0/24 was actually marked as the LAN network at Site A. So they werent actually typos in your above text. Though you dont need any additional configurations related to that network as we want the VPN Pool network to be able to connect to the Site B network.

Naturally the exception is the thing I mention at the end of the first reply. And this is that we NAT the VPN Pool with Dynamci Policy PAT to some unused IP address from network 192.1.1.0/24 so the VPN users are seen on the L2L VPN connection from an IP address already configured for that L2L VPN connection.

- Jouni