cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6877
Views
0
Helpful
18
Replies

I cannot ping from anyconnect client but i can ping from inside network

jacobwminja90
Level 1
Level 1

My Inside network: 10.10.30.0/24

My Outside network: 10.10.90.0/24

My VPN POOL: 192.168.0.0/24

I can ping one way ie from 10.10.30.195 to 192.168.0.1 but not from 192.168.0.1 to 10.10.30.195

Here below is my configurations


: Saved
:
ASA Version 9.1(2)
!
hostname XXXX
enable password 8Ry2YjIyt7RRXU24 encrypted
names
ip local pool SVCPOOL 192.168.0.1-192.168.0.254 mask 255.255.255.0
!
interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 10.10.30.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif outside
security-level 0
ip address 10.10.90.1 255.255.255.0
!
interface GigabitEthernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/5
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
management-only
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
object network INSIDE
subnet 10.10.30.0 255.255.255.0
object network OUTSIDE
subnet 10.10.90.0 255.255.255.0
object network PAT_10.10.90.1
subnet 10.10.30.0 255.255.255.0
object network PAT_OUTSIDE
subnet 10.10.30.0 255.255.255.0
object network NAT_EXMPT
range 192.168.0.1 192.168.0.254
object network ANYCONNECT_192.168.0.0
subnet 192.168.0.0 255.255.255.0
access-list SVCACL extended permit ip 10.10.30.0 255.255.255.0 any
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (inside,outside) source static INSIDE INSIDE destination static NAT_EXMPT NAT_EXMPT
!
object network PAT_OUTSIDE
nat (any,outside) dynamic interface
route outside 0.0.0.0 0.0.0.0 10.10.90.99 1
route outside 192.168.0.0 255.255.255.0 10.10.90.99 1
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
http server enable
http 10.10.30.0 255.255.255.0 inside
http 10.10.90.0 255.255.255.0 outside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet timeout 5
ssh 10.10.30.0 255.255.255.0 inside
ssh 10.10.90.0 255.255.255.0 outside
ssh timeout 5
ssh version 2
ssh key-exchange group dh-group1-sha1
console timeout 0
management-access inside
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
enable outside
anyconnect image disk0:/anyconnect-win-2.5.2014-k9.pkg 1
anyconnect image disk0:/anyconnect-linux-2.5.2014-k9.pkg 2
anyconnect image disk0:/anyconnect-macosx-i386-2.5.2014-k9.pkg 3
anyconnect enable
tunnel-group-list enable
group-policy WEBVPNPOLICY internal
group-policy WEBVPNPOLICY attributes
banner value WELCOME TO CLIENTLESS VPN
vpn-tunnel-protocol ssl-clientless
group-policy SVCPOLICY internal
group-policy SVCPOLICY attributes
wins-server none
dns-server none
vpn-tunnel-protocol ssl-client ssl-clientless
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SVCACL
default-domain none
address-pools value SVCPOOL
username admin password eY/fQXw7Ure8Qrz7 encrypted privilege 15
username admin attributes
vpn-group-policy WEBVPNPOLICY
group-lock value WEBVPNGROUP
username cisco password 3USUcOPFUiMCO4Jk encrypted privilege 15
username cisco attributes
vpn-group-policy SVCPOLICY
group-lock value SVCGROUP
tunnel-group WEBVPNGROUP type remote-access
tunnel-group WEBVPNGROUP general-attributes
default-group-policy WEBVPNPOLICY
tunnel-group WEBVPNGROUP webvpn-attributes
group-alias WEBVPNUSERS enable
tunnel-group SVCGROUP type remote-access
tunnel-group SVCGROUP general-attributes
default-group-policy SVCPOLICY
tunnel-group SVCGROUP webvpn-attributes
group-alias SVCUSERS enable
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect icmp
!
service-policy global_policy global
prompt hostname context
call-home reporting anonymous prompt 2
Cryptochecksum:d516f11792080d08006fd5bbf5eec2c6
: end

18 Replies 18

Boris Uskov
Level 4
Level 4

Hello,

I ckecked the config very briefly, and it seems to be ok.

I advice you to check, if host firewall on 10.10.30.195 (maybe, windows firewall) is blocking ICMP traffic from 192.168.0.0/24.

Also, you may use packet capture feature to check, if ICMP Echos apear on inside interface of ASA, and if ICMP Replies come from 10.10.30.195 back to inside interface.

Also, it is not neccessary to add static route to 192.168.0.0/24. You can remove the following statement:

route outside 192.168.0.0 255.255.255.0 10.10.90.99 1

Hi Boris,

I have remove the statement but still the same,

The issue which am facing is when i use the same pool as the lan, i can ping both sides but when pool is different which is requirement i can ping only one side, i have tried to debug, find attached

Have you checked host-firewall on 10.10.30.195?

 Window firewall is okay and have checked it before but even device inside ie switch i cannot be able to ping them but i can ping from switch.

What about packet-capture?

May you perform the following test?

1. Configure capture

capture TEST interface inside match ip host 192.168.0.1 host 10.10.30.195

2. Try to perform ping from 192.168.0.1 to 10.10.30.195

3. Post the output of show capture TEST here.

Hi Boris,

Below are packet tracer from cli

SR2FW3# packet-tracer input inside rawip 192.168.0.1 1 10.10.30.195 detailed

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffa223ffa0, priority=13, domain=capture, deny=false
        hits=8371, user_data=0x7fff9e3de6a0, 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=0x7fff9fc71f20, priority=1, domain=permit, deny=false
        hits=260407, 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: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.10.30.0      255.255.255.0   inside

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fff9ebb9940, priority=111, domain=permit, deny=true
        hits=864, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=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

It is ok. Packet tracer won't show you the correct results in case of VPN, because there is no way to explain for packet tracer, that the test-packet comes from VPN (not just from outside interface).

What about packet capture?

Hi Boris,

see the capture below

SR2FW3# capture TEST interface inside match ip host 192.168.0.1 host 10.10.30.$
SR2FW3#
SR2FW3#
SR2FW3# show capture TEST                              

1206 packets captured

   1: 05:07:59.793751       10.10.30.195 > 192.168.0.1: icmp: echo request
   2: 05:07:59.798802       192.168.0.1 > 10.10.30.195: icmp: echo reply
   3: 05:08:00.595855       192.168.0.1 > 10.10.30.195: icmp: echo request
   4: 05:08:00.792210       10.10.30.195 > 192.168.0.1: icmp: echo request
   5: 05:08:00.795689       192.168.0.1 > 10.10.30.195: icmp: echo reply
   6: 05:08:01.790593       10.10.30.195 > 192.168.0.1: icmp: echo request
   7: 05:08:01.794712       192.168.0.1 > 10.10.30.195: icmp: echo reply
   8: 05:08:02.789006       10.10.30.195 > 192.168.0.1: icmp: echo request
   9: 05:08:02.792332       192.168.0.1 > 10.10.30.195: icmp: echo reply
  10: 05:08:03.787419       10.10.30.195 > 192.168.0.1: icmp: echo request
  11: 05:08:03.790776       192.168.0.1 > 10.10.30.195: icmp: echo reply
  12: 05:08:04.785863       10.10.30.195 > 192.168.0.1: icmp: echo request
  13: 05:08:04.789189       192.168.0.1 > 10.10.30.195: icmp: echo reply
  14: 05:08:05.595153       192.168.0.1 > 10.10.30.195: icmp: echo request
  15: 05:08:05.784215       10.10.30.195 > 192.168.0.1: icmp: echo request
  16: 05:08:05.787328       192.168.0.1 > 10.10.30.195: icmp: echo reply
  17: 05:08:06.782643       10.10.30.195 > 192.168.0.1: icmp: echo request
  18: 05:08:06.786000       192.168.0.1 > 10.10.30.195: icmp: echo reply
  19: 05:08:07.781041       10.10.30.195 > 192.168.0.1: icmp: echo request
  20: 05:08:07.784337       192.168.0.1 > 10.10.30.195: icmp: echo reply
  21: 05:08:08.779515       10.10.30.195 > 192.168.0.1: icmp: echo request

So, I see, that there are only echo requests from 10.10.30.195, aren't they?

There are no echo replies from 10.10.30.195. Right?

So, I still believe, that ASA's config is ok. Echo replies from 10.10.30.195 are simply not reaching ASA's inside interface. The problem is somewhere between 10.10.30.195 and ASA.

You wrote previously: "Window firewall is okay and have checked it before". What do you mean by "windows firewall is ok"? Can you try to switch it completely off on 10.10.30.195 host and perform the test one more time?

Hi Boris,

I rebooted 10.10.30.195 but result still the same,

Ok, but you didn't answer about windows firewall on 10.10.30.195... Can you try to switch it off?

Or, maybe, you don't have specific permitions to modify firewall rules?

Hi Boris,

unfortunately, i dont have permission but even using a switch as a host inside the network with ip 10.10.30.9, i cannot be able to ping the switch so firewall is not an issue

Ok, but I still advice you to consult with some Microsoft-guys about windows firewall.

What about switch. Does it have the route to 192.168.0.0/24? Or, maybe, does it have any default-gateway configured?