ASA5520: access from VPN client to S2S VPN terminated on the same device

[bartholomiew]

Hello Everyone

I have a Cisco ASA5520-K8 (asa821-k8.bin, VPN Plus license) on which I terminate remote users via Cisco VPN Client and also remote sites via S2S IPsec VPNs. ASA has only one Internet interface thus both "groups" of VPNs are terminated on the same interface.

The problem is that I cannot provide access from remote users network to the remote sites network.

1. Is such thing possible at all? Or not due to e.g. routing logic?

I tired to get to this problem also other way. Behind ASA there's a corporate FW. From this FW there's an access to this remote sites network. I thought that if  I force somehow ALL traffic from remote users netw. to go unconditionally firstly to the FW then it should be able to return to ASA and access this remote sites netw. as a traffic comming from the FW.

2. Is this the right idea?

I tried to implement it by policy based routing but it seems not to be possible on my device.

3. True?

My another idea is to set somehow a default gateway for VPN CLients to be the FW IP. Then all traffic from remote users would firstly go directly to the corp. FW, and then eventually back to the remote sites network. So far, VPN Clients don't receive any gateway:

IPv4 Address. . . . . . . . . . . : 172.31.252.59

Subnet Mask . . . . . . . . . . . : 255.255.0.0

Default Gateway . . . . . . . . . :

4. Is this possible to be done?

Below is the small diagram of my connections:

If necessary I can obviously provide any output from the device.

Thanks in advance

Regards

Bartek

[rizwanr74]

Please read this thread and answer is right there.

https://supportforums.cisco.com/message/3576912#3576912

[bartholomiew]

Thanks rizwanr74

I think that this may be this issue. Nevertheless I have few questions about this solution but I'll ask them in the topic which you linked.

One more thing regarding this default gateway for RA clients. Do you know if the solution with setting the def. gtw to the corp. FW for RA clients is possible?

This would be the best solution for us because we'd be able to filter traffic additionally on the corp FW.

rgds

B

[rizwanr74]

"I'll ask them in the topic which you linked."

Please post your question on this thread, as that thread is closed and it was answered and if you do not mind, please delete the your input on the other thread because the solution was already provided and it would be come overwhelming to readers when a third issue is inserted into other thread.

"Would you be able to describe shortly what exactly is behind this config that you inserted?

Why did you use this network

192.168.250.208 255.255.255.240 ?"

the remote-clients' ip range falls in the network of "192.168.250.208 255.255.255.240", which is used to indentify remote-client users and are used for no-nat with remote-site-to-site networks on the outside interface.

thanks

Rizwan Rafeek

[bartholomiew]

Hi

I removed my post from the other topic as you advised.

rizwanr74 wrote:
 
the remote-clients' ip range falls in the network of "192.168.250.208 255.255.255.240", which is used to indentify remote-client users and are used for no-nat with remote-site-to-site networks on the outside interface.

So it's basically about disabling NATing between my RACLIENTs netw. and remote LANs netw. on the outside interface, right?

I tried to follow your steps from that other post but it didn't work.

I added the following lines to my config:

access-list OUTSIDE-NAT0 extended permit ip 172.29.0.0 255.255.0.0 172.31.252.0 255.255.255.0

access-list OUTSIDE-NAT0 extended permit ip 172.31.252.0 255.255.255.0 172.29.0.0 255.255.0.0

nat (outside) 0 access-list OUTSIDE-NAT0

same-security-traffic permit intra-interface

I'd gratefull if you could take a look at my config - maybe there's sth else wrongly setup.

Attached is the config with cut unnecessary tunnel configs.

How about this RA Clients default gateway - do you have any idea?

thanks!

BK

[rizwanr74]

Please follow the syntax.

object-group network CSM-RLANS
network-object 172.29.255.16 255.255.255.240

access-list outside_nat0 extended permit ip object-group CSM-RLANS 172.31.252.0 255.255.255.0
access-list outside_nat0 extended permit ip 172.31.252.0 255.255.255.0 object-group CSM-RLANS

nat (outside) 0 access-list outside_nat0

same-security-traffic permit intra-interface

"How about this RA Clients default gateway - do you have any idea?"

If you are not pushing everything i.e. every traffic into the tunnel, then remote-clients do not need a default-gateway being installed on the remote-client adapter on their PC.

Hope this answers your question.

thanks

Rizwan Rafeek

[bartholomiew]

Unfortunately, this way it's also not working.

I already tried the same thing (see 2 posts above) but:

- I used the scope 172.29.0.0/16 (this scope includes around 200 remote LANs) instead of

172.29.255.16/28 (this is scope for a single remote LAN which was disabled btw)

- I used the strict netw/netmask statement instead of defining a object-group network

Do you have any other ideas?

If you are not pushing everything i.e. every traffic into the tunnel, then remote-clients do not need a default-gateway being installed on the remote-client adapter on their PC.

Actually my next planned step was to disable the split tunneling so that all traffic from RA client is going through the tunnel. In this case default gateway could exist, right?

Now there's a question if we could set it up for the IP of our CORP FW (not ASA)?

Regards

Bartek

[rizwanr74]

Please add this on the ASA.

route outside 172.29.0.0 255.255.0.0 193.158.23.129

"Actually my next planned step was to disable the split tunneling so that all traffic from RA client is going through the tunnel. In this case default gateway could exist, right?" Yes.

Please fix your pool range as shown below, not zero.

ip local pool CLIENT-VPN 172.31.252.1-172.31.252.255 mask 255.255.255.0

Please let me know, how things coming along.

thanks

[bartholomiew]

route outside 172.29.0.0 255.255.0.0 193.158.23.129

I tried with this as well but it didn't help. This is a must of course, but when the L2L VPN is up the I have the right entries in the routing table inserted by RRI

I think that we found the problem source however. ACLs responsible for encrypting traffic to L2L tunnels weren't including the RAVPN IP scope.

We'll now consider if we'll readdress the RAVPN scope which will require many changes on the firewall or we'll pick another separate device for this RAVPN connections.

Anyway - many thanks for your help and involvement!

Regards

BK