ASA problem routing from inside back to VPN client

[Wayne_G]

Hi,

I have a problem where I cannot reach VPN clients with their vpn pool IP from the inside, or from the asa itself. VPN clients connect and can access internal network fine. I have no nat configured for the vpn pool range, and packet tracer encrypts the packet and puts it down the tunnel. I'm not sure whats wrong.

Here's some relevant config:

object network obj-192.168.245.0

subnet 192.168.245.0 255.255.255.0

ip local pool vpn 192.168.245.1-192.168.245.50

nat (inside,outside) source static any any destination static obj-192.168.245.0 obj-192.168.245.0 no-proxy-arp route-lookup

Packet tracer output:

firewall# packet-tracer input inside icmp x.x.x.x 8 0 192.168.245.33

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.245.33  255.255.255.255 outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group acl-inside in interface inside

access-list acl-inside extended permit icmp any any echo

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) source static any any destination static obj-192.168.245.0

obj-192.168.245.0 no-proxy-arp route-lookup

Additional Information:

Static translate x.x.x.x/0 to x.x.x.x/0

Phase: 8

Type: VPN

Subtype: encrypt

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 277723432, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

There is no route to the vpn pool address though. Maybe this is the problem? I'm sure this used to work before we upgraded to 8.4.

[Julio Carvajal]

Hello Wayne,

No route is required, it should be implied that there will be connecting from the outside so the outside should be the one interface used to route back to this guys,

Just as a test can you create a more specific object network ( with the LAN )

object network LAN

subnet 192.168.12.0 255.255.255.0

nat (inside,outside) 1 source static LAN LAN destination static obj-192.168.245.0 obj-192.168.245.0

Then let us know the result,

Also is this an IPSec client or Anyconnect deployment?

[Wayne_G]

Hi,

Thanks for your help with my issue. The clients are using Cisco VPN client, ie IPSec.

I tried your suggestion but still got the same result. I connected a vpn client and got an IP from the pool (192.168.245.40). Then tried a ping from an inside host. No reply.

firewall(config)# object network inside_subnet

firewall(config-network-object)# subnet 172.20.0.0 255.255.0.0

firewall(config-network-object)# exi

firewall(config)# nat (inside,outside) 1 source static inside_subnet inside_subnet destination static obj-192.168.245.0 obj-192.168.245.0

firewall# ping inside 192.168.245.40

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.245.40, timeout is 2 seconds:

?????

Success rate is 0 percent (0/5)

firewall# packet-tracer input inside icmp 172.20.5.103 8 0 192.168.245.40

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.245.40  255.255.255.255 outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group acl-inside in interface inside

access-list acl-inside extended permit icmp any any echo

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) source static inside_subnet inside_subnet destination stati

c obj-192.168.245.0 obj-192.168.245.0

Additional Information:

Static translate 172.20.5.103/0 to 172.20.5.103/0

Phase: 8

Type: VPN

Subtype: encrypt

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 278219622, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

[Andrew Phirsov · Accepted solution]

Check if firewall is enabled on your ravpn client host and blocking all your pings.

[Wayne_G]

Thanks Andrew. But the firewall is not enabled on the client. This was the first thing I checked.

[Julio Carvajal]

Can you share the entire configuration please?

Do you have NAT-T enabled? If  not please do

Regards,

[malshbou]

Hi,

did you check routing at the inside hosts so that they point to the ASA ?

please get these outputs:

cap capin interface inside match icmp any any

cap asp type asp-drop all

clear crypto ipsec sa counters

then, run a continuous ping from one of the inside hosts, and get:

show cap in

show cap asp

show crypto ipsec sa

----

Hope this helps

Mashal

[Wayne_G]

We don't have NAT-T enabled. Do you think this will help? The clients can access internal hosts with no issues.

Mashal,

It's not a routing issue, I can't ping the clients from the asa itself. To confirm I did the capture for icmp and the pings are reaching the asa. I also tried the asp capture you suggested, but there was way too many logs and I couldn't find the relevant entries. What are you looking for with the asp-drop capture? Can I filter it down?

[Julio Carvajal]

We don't have NAT-T enabled. Do you think this will help? The clients can access internal hosts with no issues??

YES, I have this same issue once.. Try that and I got to work....

Regards,

Julio Carvajal

Advanced Security Trainer

[Wayne_G]

Thanks everyone for your help. Turns out this is a firewall problem on the client after all. While we had disabled the firewall for the Domain networks profile, it was still enabled for private and public. The VPN adapter must get assigned to the public profile and not Domain profile like I thought (This is for Windows 7).

[Julio Carvajal]

Hello Wayne,

Good to know that,

Please mark the question as answered so anyone can learn from this topic,

Regards