Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

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

 

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)# 

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

7 REPLIES
Bronze

Luis.Hi Andy,Based on the

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. 

New Member

Hi Luis,Thanks for helping

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)# 

Hi, your first two packet

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?

New Member

Hi Rudy,Thanks for the input,

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.

New Member

Just updating, I wanna say

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.

Bronze

Hello Andy, Great to hear

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.

Bronze

Hello Andy,Thanks for the

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.

634
Views
0
Helpful
7
Replies
CreatePlease login to create content