ASA 5520 8.4(3) tunnel default gateway and various subnets

[lastina38]

Hi,

I am struggling on a problem for over 2 weeks despite of various researches.

We have a Cisco router, then an ASA 5520 8.4(3).

The private interface of the ASA is connected to a switch, and so on connected to one interface of the router.

The private interface is as following : 129.88.63.253 255.255.248.0 (/21) =>

It is in the 129.88.56.0/21 subnet

Here is the part of the router config we are interested in  :

!

interface Vlan32

ip address 129.88.63.254 255.255.248.0 (this is the tunnel default gateway configured on the ASA - 129.88.56.0/21 subnet)

ip address 129.88.71.254 255.255.255.0 secondary

ip address 129.88.75.254 255.255.252.0 secondary

ip access-group CVPN-depuis-129.88.56 in

ip access-group CVPN-vers-129.88.56 out

ip verify unicast source reachable-via rx allow-default

no ip redirects

mls rp ip

!

On the ASA, there is currently one default route for the tunneled traffic :

route Private 0.0.0.0 0.0.0.0 129.88.63.254 tunneled

As you can see, it's on the same subnet as the primary IP address of interface Vlan32 on the router.

The scenario is as following :

- we can connect to the VPN with the appropriate alias (LDAP connection), then we get an IP address in the defined range (it's a local ASA pool)

- the pool is : 129.88.71.0/24

- but, once we are connected, we can't do anything, because it seems like we don't have any network access

My thoughts :

At the moment, we are giving (for the alias/connection profile above which relies on LDAP authentication)

an IP address from a local ASA pool (129.88.71.1 to 129.88.71.253). But this IP address is not on the same subnet as the

tunnel default gateway (129.88.63.254).

For example, if we give an IP address in the 129.88.56.0/21 subnet everything works perfectly.

However, this given IP address is still on the same subnet as one of the secondary IP address of the interface Vlan32 on the router :

ip address 129.88.71.254 255.255.255.0 secondary

The strange problem is that this configuration did work for some days until we reboot the ASA, and now it's over.

Currently, the configuration on the ASA is the same as before the reboot.

Do you have any ideas in order to make this type of configuration  really work (multiples subnets but one tunnel default gateway, which is  the only way

to "access" the network resources) ?

Considering the following...

- we can only set one and only one default tunnel gateway

- we can't extend the '129.88.63.254 255.255.248.0' subnet

- the problem doesn't come from the ACLs (tested with and without, and these are OK, they let pass the traffic from the above pools)

Thanks !

[m.glosson · Accepted solution]

Here's a thought. If the secondary IP address is configured on the router simply for the purpose of being on the same subnet as the clients, that is not necessary. It's better to simply set a route in the router pointing

129.88.71.0/24 at the firewall's Private interface (ip route 129.88.71.0 255.255.255.0 129.88.63.253). It's basically the difference between the data getting sent right at the firewall (good) versus the firewall having to proxy-arp answer an arp broadcast (not as good).

May or may not solve the problem, but it's a cleaner configuration.

[lastina38]

Thank you for your comment, will try this afternoon.

But here is one question (for understanding), you say :

"If the secondary IP address is configured on the router simply for the  purpose of being on the same subnet as the clients, that is not  necessary".

Well, once connnected, my VPN client has an IP address : 129.88.71.1 /24 for example

If I want to reach the following IP address (our DNS server) : 129.88.30.10, what will be the way ?

I mean, in order to attain 129.88.30.10, the VPN client will need to transfer the packet to 129.88.63.254 (the default tunnel gateway), as the DNS server is currently not on the same subnet as the VPN client.

If we use a 'tracert' command, for example, 'tracert 129.88.30.10', the first hop should be : 129.88.63.254

But in that case, which way the VPN client will join 129.88.63.254, directly ? or the traffic is

implicitly sent to the ASA which redirects to 129.88.63.254 ? ...

[Javier Portuguez]

Hi,

1- The VPN clients do not need to be in the same subnet as your Router, just add a route pointing to the ASA in order to reach the VPN pool.

2- Why do you need a "tunnel default-gateway"? Are the clients accessing the Internet through the VPN connection (tunnel-all)?

3- What if you place a packet-capture on the inside interface of the ASA, do you see the packets leaving the FW?

4- Do you have the correct NAT rules to allow this traffic?

5- If you check on the client's statistics, do you see the traffic counter increasing for number of encrypted packets?

Thanks.

[lastina38]

Hi

1- The VPN clients do not need to be in the same subnet as your  Router, just add a route pointing to the ASA in order to reach the VPN  pool.

-> Ok we will try this.

2- Why do you need a "tunnel default-gateway"? Are the clients accessing the Internet through the VPN connection (tunnel-all)?

-> Yes they might access internet through the VPN, and the default tunnel gateway is mandatory in order to access

every network resource (DNS which is in another subnet, ... lots of other things, but not in the same subnet, so we did set a default tunnel gateway, which is in reality one interface of the router, and then the router manage the traffic.)

There are lots of networks connected to this router.

3- What if you place a packet-capture on the inside interface of the ASA, do you see the packets leaving the FW?

-> Will respond after a try.

Here is a subsidiary question : how would my VPN client join the default tunnel gateway (129.88.63.254) while the

IP address of the VPN client is for example: 129.88.71.1 ? It sends the traffic to the ASA, and then the ASA sends the traffic to 129.88.63.254 ? (The ASA has its private interface with 129.88.63.253 IP address)

4- Do you have the correct NAT rules to allow this traffic?

-> ? We have absolutely no NAT rules. Why NAT would be somehow useful in our configuration ?

As I said above, if the given IP address for the VPN client is in the 129.88.56.0/21 subnet

(as the default tunnel gateway, 129.88.63.254 and the private interface of the ASA, 129.88.63.253) everythings works !

But we currently can't use this pool.

Is there something I am misunderstanding ?

5- If you check on the client's statistics, do you see the traffic counter increasing for number of encrypted packets?

-> AnyConnect 3.0.5080 : Bytes sent : increasing / Bytes received : 0 or stay the same

It's the same thing tor the frames.

But since we can't even "ping" our default tunnel gateway... it seems logic we don't have any responses.

[Javier Portuguez]

Dear Marc-Olivier,

Thanks for your promt response.

Indeed the ASA will get the packet from the client and will check on the destination network, if it does not know where to send the packet, then it would use the tunnel default-gateway, which is .254.

On the other hand, I mentioned the NAT rules because I am not familiar with your configuration at all, so I just wanted to make that clear.

Once connected to the VPN, can you ping the internal interface of the ASA (remember to use the management access command)?

Please keep me posted.

Thanks.

[lastina38]

Once connected to the VPN, I currently can't ping the internal interface of the ASA (otherwise it does respond to ping), whatever the connection profile I choose (even those where there are no problems for the rest). So it's not a problem related to the current one. In fact the ping doesn't pass, but ASDM/SSH/HTTPS are OK with 129.88.63.253 (internal interface), even with the pool : 129.88.71.0/24 !

In a couple of hours I will try to add the route on the router, and then come back here if it does not solve my problem.

Will keep you updated asap.

Thanks anyway.

[Javier Portuguez]

Sounds good.

Please make sure you allow ICMP, "show run icmp".

Also please send the output for: "show run nat-control".

Another test is to run a packet-tracer from the inside interface, use any available IP from the inside.

packet-tracer input inside icmp internal_ip 8 0 vpn_IP detail

Please keep me posted.

Thanks.

[lastina38]

So,

The problem is resolved. This was effectively a routing problem.

We removed the secondary ip addresses on the interface Vlan32 of the router, and then added the static route :

ip route 129.88.71.0 255.255.255.0 129.88.63.253

Thank you to both of you, I understand things clearly now.

[Javier Portuguez]

Great news

I hope you enjoy the rest of the day!

Do not hesitate to contact us back at any time.

* Please do not forget to rate the posts.