Some Inside Networks Unreachable through VPN

[GRANT3779]

Hi All,

I have clients connecting in through cisco vpn client. All is good and they receive IP etc.. and can get access to remote office subnets over the WAN and also some local subnets. However, not all local subnets are accessible. I find it strange as clients can access remote sites, which first have to traverse the LAN then go out.

VPN Clients receive an address on the 10.44.11.0 /24 range.

My ASA Interfaces are below.

interface Ethernet0/0

nameif inside

security-level 100

ip address 172.27.4.15 255.255.252.0

!

interface Ethernet0/2

nameif outside

security-level 0

ip address "PUBLIC IP"  255.255.255.0

!

interface Ethernet0/3

nameif Voice

security-level 90

ip address 172.27.15.15 255.255.255.0

!

interface Management0/0

management-only

nameif management

security-level 100

ip address 172.27.10.15 255.255.255.0

I also have the following routes in place.

route outside 0.0.0.0 0.0.0.0 Public IP 1

route inside 10.44.0.0 255.255.240.0 172.27.4.1 1

route inside 10.44.128.0 255.255.240.0 172.27.4.35 1

route inside 10.44.144.0 255.255.240.0 172.27.4.35 1

route inside 10.44.240.0 255.255.240.0 172.27.4.1 1

route inside 10.129.0.0 255.255.0.0 172.27.4.1 1

route inside 172.16.0.0 255.240.0.0 172.27.4.1 1

route inside 192.111.111.0 255.255.255.0 172.27.4.1 1

172.27.4.1 is the SVI on my Core switch.

Now the ones in green I can route to from my VPN client, however the one in red I cannot. The route statement above not highlighted means i can route to some of the networks within that summary, but not all. E.G I can route to any address in the 172.27.4.x network, also any address in the 172.27.33.x network, but for example I cannot route to 172.27.10.x /24.

Am I missing something? From the ASA direct however, I can ping and route to all the addresses i cannot via the VPN client.

[Jouni Forss]

Hi,

Seems to me that the 172.27.10.0/24 is directly connected to the management interface on the ASA.

Its set as "management-only" which means that no actual data traffic can cross this interface. Its purely for management connections to the ASA itself. Nothing going through to a network behind another interface.

On the original ASA5500 Series you can simply remove this command to enable the traffic to flow. On the new ASA 5500-X series this is not possible. Judging by your interface IDs I assume you are using the ASA5510 model.

Naturally you would have to make sure that you had NAT0 configurations etc if you remove that setting as it might not be just that setting that is causing problems but its one clear problem.

- Jouni

[GRANT3779]

Hi Jouni,

Yes it is a 5510. If this command is not available on this model, is there any way round it?

I gues more importantly, is there any reason why i may not be able to access say the 10.44.0.0 /24 network from my VPN clients? I have routes to it and it sits behind interface 0/0. I can ping this network from the ASA itself. If you need any more info / config just let me know. I've attached most of the current config.

Thanks

[Jouni Forss · Accepted solution]

Hi,

I mean that considering that you ASA is from the original ASA5500 Series (Not the new X-Series) you can simply remove the "management-only" from under the interface if you need traffic to flow from that network to the VPN Client also.

interface Management0/0

  no management-only

With regards to the network 10.44.0.0/24 I am not sure. I am not sure if the attached configuration lists all the NAT configurations. For example there seems to be one NAT command there which doesnt show the "object" name above it. Must have been edited out?

It seems that you dont have much NAT0 configurations on the ASA. Naturally if they are needed depends on the fact if the destination LAN network has any Dynamic PAT (that is why I was wondering what the "nat" command was for which is missing the "object" in the attached configuration).

Naturally you could add this configuration just incase

object network LAN-10.44.0.0-24

subnet 10.44.0.0 255.255.255.0

object network VPN-POOL

subnet 10.44.11.0 255.255.255.0

nat (inside,outside) source static LAN-10.44.0.0-24 LAN-10.44.0.0-24 destination static VPN-POOL VPN-POOL

I would also go through your LAN routers and check what networks masks is used for the 10.44.x.x subnets in the LAN network. It might be that there is a large enough network mask that breaks the return traffic towards the VPN Pool.

One thing to avoid this or rule it out would naturally be to change the VPN Pool to something completely different than you are using on your LAN network.

- Jouni

[GRANT3779]

Hi Jouni,

Regarding adding this NAT. As an example, at the moment I don't have anything setup for the network 192.111.111.0 /24 which is used inside my network and is actually on a remote site from the ASA. (behind the Inside Interface)

route inside 192.111.111.0 255.255.255.0 172.27.4.1 1

I can ping this network from my VPN client but do not have any NATstatements for this. I can also access for example 172.25.33.0/24 from my VPN client but have no NAT statements for this.

From the VPN client I can ping 172.27.4.1 which is n SVI on my core, but I can't ping 10.44.0.1 which is another SVI on the same core.

I did send all the config, I took out some NATs for specific servers so thats probably what you seen was missing.

If I run a trace from the VPN client to 172.27.4.1, the first hop is the external Interface of my ASA. However if I trace to 10.44.0.1 the first hop just times out, it doesn't even go to my external ASA Interface it looks like.

Lost...

[Jouni Forss]

Hi,

Yes, you wont need any NAT configurations for the traffic between a LAN and VPN network if the LAN network does not have any Dynamic PAT configuration. Then the ASA would simply pass the traffic without NAT. The most typical situation is that there is a Dynamic PAT configuration unless its purely VPN device.

If the NAT configuration aint the problem then a routing issue is probably the next most likely reason for the problems. Especially since you seem to be using Full Tunnel so all the traffic from the Client is supposed to reach the ASA atleast.

I can't see any real problems on the ASA configuration at the moment atleast.

So the problem might be somewhere else than the ASA.

- Jouni

[GRANT3779]

Hi Jouni,

Done as you advised and it now works. I can access the VPN subnet from the 10.44.0.0 /24 Network now and vice versa.

Do you have any idea why I had to do this for that specific network, and not for 192.111.111.0 /24 for example? That network can communicate with the VPN subnet already without any NAT statements.

Anyways, Thanks again.

[laramire2]

Hello Grant,

As Jouni said it seems like we are missing some NAT exemption rules. The only NAT rule related to the ip pool used by the VPN clients are a PAT and a NAT exemption rule for the 172.27.4.0/22 network. Remember, that we need a NAT exemption rule for every local network communicating with the VPN clients, otherwise, the packets will be translated to the Public IP address of the ASA and sent to the Internet instead of the VPN.

object network SITE_VPN_ACCESS

subnet 10.44.11.0 255.255.255.0

nat (any,any) source static NETWORK_OBJ_172.27.4.0_22 NETWORK_OBJ_172.27.4.0_22 destination static SITE_VPN_ACCESS SITE_VPN_ACCESS no-proxy-arp

object network SITE_VPN_ACCESS

nat (inside,outside) dynamic Public.11

You can use the same example that Jouni placed for the every nat rule. Please take the packet-tracer and the captures.

Luis.

[GRANT3779]

Hi Luis,

Let me look into this and I'll get back to you.

Thanks

[laramire2]

Hello,

Based on the problem description you can not reach some networks through the VPN connection. We really need more details about the configuration. If you can please send us the running configuration or at least the commands below:

show run nat

show run access-list (name of the nonat access-list)

show run tunnel-group xxxxxx (name of the tunnel-group used by the VPN client)

show run group-policy xxxxxx (name of the group policy used by the VPN clients)

We need to make sure that you have the proper routing configured for the 10.44.11.0/24 network on the Core, in order to send the packets back through the ASA. Of course the most specific route will take precedence. Once the client is connected you could run a packet tracer to check the flow for the packets coming back from the Local network to the VPN clients.

packet-tracer input (inside) icmp (local host) 8 0 (vpn client assigned ip address) detail

Also, you could run some captures on any of the interfaces to see if the packets are coming back to the ASA:

capture cap interface (*) match ip host (local host) host (VPN client ip address)

*name of the interface where you would like to capture the packets.

Hope to hear back from you soon.

Luis.