Need Help! Can't get traffic going through Anyconnect.

MrAndyCappa · ‎03-13-2014

Hi Everyone,

I'm new to the ASA (5505 w/ Base License) & need some help setting up Anyconnect. I've setup the connection & it does establish without a problem but it wont route (most) traffic through the tunnel. After it's connected the sent traffic increments up but the received doesn't increment, except if I ping the ip of the client from the ASA or any client behind the ASA, keep in mind they don't get a response from the ping. I cant ping the ASA's inside interface or anything on the inside network from the outside client.

I've made numerous attempts working on ACL by adding, removing, changing, etc, also tried applying them to the outside interface using access-group but can't get past this yet.

Any help help would be appreciated & I thank you in advance. Below is snippets of the relevant config as I have left it.

--------------------------------------------------------------------------------------------------------------------------

ASA Version 8.3(1)
!
interface Vlan79
nameif INSIDE
security-level 100
ip address 10.40.79.1 255.255.255.0
!
interface Vlan99
nameif OUTSIDE
security-level 0
ip address 10.0.0.101 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 99
speed 100
duplex full
!
interface Ethernet0/5
switchport access vlan 79
speed 100
duplex full
!
object network NET-10.40.79.0
subnet 10.40.79.0 255.255.255.0
object network NET-192.168.1.1
subnet 192.168.1.0 255.255.255.0
!
ip local pool REMOTE_SSL 192.168.1.1-192.168.1.10 mask 255.255.255.0
!
nat (INSIDE,any) source static NET-10.40.79.0 NET-10.40.79.0 destination static NET-192.168.1.1 NET-192.168.1.1
nat (INSIDE,OUTSIDE) source dynamic any interface
!
route OUTSIDE 0.0.0.0 0.0.0.0 10.0.0.1 1
!
webvpn
enable OUTSIDE
svc image disk0:/anyconnect-win-2.5.2014-k9.pkg 1
svc enable
group-policy DefaultWEBVPNGroup internal
group-policy DefaultWEBVPNGroup attributes
dns-server value 208.67.222.222 208.67.220.220
vpn-idle-timeout 30
vpn-tunnel-protocol svc webvpn
webvpn
svc ask enable
tunnel-group DefaultWEBVPNGroup general-attributes
address-pool REMOTE_SSL
default-group-policy DefaultWEBVPNGroup
!
: end
asa00(config)#

--------------------------------------------------------------------------------------------------------------------------

laramire2 · ‎03-13-2014

Luis.

Hi Andy,

Based on the attached configuration everything looks properly configured. The problem seems to be with the packets coming back to the AnyConnect clients. Please enable the management-access on the inside interface and see if the client can ping the inside ip address of the ASA. Use the command below:

Conf t

management-access INSIDE

If the client is able to ping at that point it would mean that packets are traveling through the VPN connection with no issues. Then, you will need to make sure that there are proper routes configured on the inside network sending the packets destined to the 192.168.1.0/24 network (IP Pool) back through the ASA. Otherwise the ASA will be unable to encrypt the packets and send them back through the VPN tunnel.

You could also place some captures on the inside interface of the ASA and do a packet tracer to make sure that the correct flow is being followed.

Captures:

capture cap interface inside match ip 192.168.1.0 255.255.255.0 10.40.79.0 255.255.255.0

After send some packets from the client to the 10.40.79.0/24 network you could use the command show capture cap in order to see if the packets are reaching the ASA and coming back from the inside host.

Packet tracer:

packet-tracer input INSIDE icmp 10.40.79.20 8 0 192.168.1.x (assigned ip address on the connection) detail

Please attach the outputs if the problem continues.

Hope this helps,

Luis.

MrAndyCappa · ‎03-13-2014

Hi Luis,

Thanks for helping out. Now after entering the "management-access inside" cmd I was able to successfully ping the inside interface.

I did some packet traces & would seem there is an issue with the implicit deny ACL, I have no ACLs in the config now but prior to that I only had one which was to allow some icmp return traffic in. See the output from the packet traces below, I'll only put the ones where it results in a "drop".

Any further help would be greatly appreciated.

-----------------------------------------------------------------------------------------------

asa00(config)# packet-tracer input INSIDE icmp 192.168.1.1 8 0 10.40.79.51 det

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xcb059338, priority=13, domain=capture, deny=false
hits=2735, user_data=0xcb059278, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=INSIDE, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9cc63a8, priority=1, domain=permit, deny=false
hits=688085, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=INSIDE, output_ifc=any

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (INSIDE,any) source static NET-10.40.79.0 NET-10.40.79.0 destination static NET-192.168.1.1 NET-192.168.1.1
Additional Information:
NAT divert to egress interface INSIDE
Untranslate 10.40.79.51/0 to 10.40.79.51/0

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9cc72f8, priority=111, domain=permit, deny=true
hits=0, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=INSIDE, output_ifc=INSIDE

Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

-----------------------------------------------------------------------------------------------

asa00(config)# packet-tracer input OUTSIDE icmp 10.40.79.51 8 0 192.168.1.1 det

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.1.1 255.255.255.255 OUTSIDE

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9d8f370, priority=111, domain=permit, deny=true
hits=46, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=OUTSIDE, output_ifc=OUTSIDE

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: OUTSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

-----------------------------------------------------------------------------------------------

asa00(config)# packet-tracer input OUTSIDE icmp 192.168.1.1 8 0 10.40.79.51 det

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (INSIDE,any) source static NET-10.40.79.0 NET-10.40.79.0 destination static NET-192.168.1.1 NET-192.168.1.1
Additional Information:
NAT divert to egress interface INSIDE
Untranslate 10.40.79.51/0 to 10.40.79.51/0

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9d8eb48, priority=0, domain=permit, deny=true
hits=3168, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=OUTSIDE, output_ifc=any

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

asa00(config)#

Rudy Sanjoko · ‎03-14-2014

Hi, your first two packet-tracers are using the wrong interface as input interface. Try adding ACL allowing packet coming from outside as it has lower security level. Can you also post the packet capture result suggested by Luis?

MrAndyCappa · ‎03-14-2014

Hi Rudy,

Thanks for the input, I've attached the capture & full config. I've pretty much narrowed it down to an ACL issue but for the life of me I can't seem to get past this.

Any further help would be appreciated.

MrAndyCappa · ‎03-20-2014

Just updating,

I wanna say thanks for all the input, being a newbie to the ASA i've learnt a lot in what I consider a short space of time.

I got the issue resolved, it was a combination of the group-policy I created & not having the same-security-traffic permit intra-interface cmd. Not sure why my group-policy didn't work but I'm TS that now but once I made those changes I was able to reach clients on the inside lan & tunnel internet traffic over the vpn.

Thanks again.

laramire2 · ‎03-20-2014

Hello Andy,

Great to hear that everything is working properly now. Please rate the question if you found useful our information in order to continue helping others.

Thanks,

Luis.

laramire2 · ‎03-14-2014

Hello Andy,

Thanks for the information!

As Rudy said the first 2 packet tracers collected are not specifying the correct interfaces based on the packet flow. If you would like to do the packet tracer when packets are coming in you will need to allow those packets using an access-group on the outside. Please make sure that you use the ip address assigned to the VPN client.

Also, please take the captures requested before. As I mentioned on my last comment you should probably take a look on the inside routing to make sure that there are routes configured for the packets back from the inside to the VPN clients.

Hope this helps,

Thanks.