ASA VPN 10. can't talk to inside 10. (inside network is 192.168.x.x)

dirkmelvin · ‎04-07-2009

I have several laptops that connect via VPN. These particular logins get assigned 10.42.x.x IPs. My inside IPs for normal devices are 192.168.100.x, but I have a special device that requires my IPs be 10.42.x.x to communicate with it. This device is on the inside network with a 10.42.x.x address. On my PCs inside I have a 10.42.x.x IP assigned as secondary and they have a route statement pointing it directly to the special device for its traffic. They have no problem talking to it.

My issue at this point (and it was working before a power outage this weekend) is now the VPN users that get assigned the 10.42.x.x addresses can talk to devices on the 192.168.100.x network, but NOT devices on the 10.42.x.x network.

bmcginn · ‎04-07-2009

Hi there,

After looking at your configuration, I would suggest that the traffic from the 10.42.26.64/27 range; which from what I can gather are the IP addresses assigned out to your VPN clients, doesn't know how to get to the 10.42.x.x device on the inside network. There doesn't seem to be any route on the inside for that network.

If the 10.42.x.x network where the special device lives was directly connected to the ASA, and assuming it didn't overlap the VPN client pool, you wouldn't need a static route as a directly connected route would already be there.

You could do a capture on the inside interface to see if the traffic from the VPN clients towards the special device is actually leaving the ASA on the inside interface, but I suspect you won't see that traffic there - no route.

Brad

dirkmelvin · ‎04-15-2009

I now have the 10.42.x.x device directly connected to the ASA on port 2. However, I don't see it at all in the ARP list.

Again, the folks on the inside (having both a 192.168.100.x address AND a 10.42.x.x address) can still use the device correctly, it is just the VPN folks that can't.

bmcginn · ‎04-19-2009

Hi there,

Are the IP addresses being dished out to the VPN clients on the same network as the server?

If they are, then it won't work. The ASA won't know where to send the traffic to. If the same addresses are used: eg 10.42.0.0/24 for the server's network and 10.42.0.0/24 for the VPN clients, then the ASA will probably get confused.

Can you put in NATs and port forwarding so that the server sees all conversation as coming from the 10.42.x.x?

Daniela Herrera · ‎04-20-2009

I understand that having the client's pool on the same segment of the inside hosts is not highly recommended, but the ASA is supposed to handle that correctly as long as the proper routes are added to it.

I too believe the best shot is to create a capture on the inside interface and test if the traffic from the client is actually trying to go out that interface or not.

If it is, the problem is between the ASA and the destination server. IF it's not, make sure that the routing table is correct when the clients connect, make sure they have access to that network through the ASA (correct ACL on the clients), verify the logs to see if any packets are being dropped by the ASA and why.

To create the capture you'll need an access-list selecting traffic between the vpn client and the destination server (both ways).

Apply it to the internal interface (where the server is connected):

capture access-list interface

sh capture should show the traffic.

regards,

dirkmelvin · ‎04-24-2009

well with a nudge in the right direction from CiscoTAC. I was able to figure out that, because the ASA didn't get the ARP announcement from the 10.x.x.x device it didn't know what to do with traffic destined for it.

So using wireshark I was able to get the MAC address of the device and statically map the device and all is now well!

Apparently the vendor for this device made a software change and it decided to stop broadcasting itself.

Thank you everyone for your help!