Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
442
Views
0
Helpful
10
Replies

ASA 5515 Management able to telnet but unable to ping from different subet

Steve Cheung
Level 1
Level 1

‎03-24-2016 02:24 AM - edited ‎03-12-2019 12:32 AM

Recently setup an ASA 5515 for remote VPN purpose. All the inbound and outboud traffic through the internal and external interfaces are working fine. There is an issue that the management port is able to telnet but unable to ping from different subnets, but it is able to ping if hosts were are on the same subnet of the management port. As we have an oversea monitor device which would use the ICMP for the keep alive the ASA status, so at them moment the monitor system show the ASA status is down.

Want to see any similar experience and suggestion can be advised.

Thanks

Labels:
0 Helpful
10 Replies 10

Aditya Ganjoo
Cisco Employee
Cisco Employee

‎03-24-2016 02:29 AM

Hi Steve,

Are you using any NAT statements for the VPN traffic on the ASA ?

If yes could you add route-lookup keyword to the NAT statement ?

Also is your inside interface configured as management-access ?

Regards,

Aditya

Please rate helpful posts.

0 Helpful

Steve Cheung
Level 1
Level 1
In response to Aditya Ganjoo

‎03-24-2016 02:37 AM

Hi Aditya,

Thanks for the reply. For your first question, NO NAT statement has been configured. For the second question, the internal interface and management interface are segregated, which interface has there own default route.

interface GigabitEthernet0/0
 nameif Internal
 security-level 100
 ip address 10.146.122.2 255.255.255.240

interface Management0/0
 management-only
 nameif management
 security-level 100
 ip address 10.146.120.13 255.255.255.

route management 0.0.0.0 0.0.0.0 10.146.120.241 2
route Internal 10.0.0.0 255.0.0.0 10.146.122.1 1

0 Helpful

Aditya Ganjoo
Cisco Employee
Cisco Employee
In response to Steve Cheung

‎03-24-2016 04:22 AM

Hi Steve,

Is your management port IP a part of the VPN traffic ?

Regards,

Aditya

0 Helpful

Steve Cheung
Level 1
Level 1
In response to Aditya Ganjoo

‎03-24-2016 07:01 AM

Hi Aditya,

Yes, the Management port IP is part of the VPN. Attached a simple diagram to describe the connectivity. In the diagram, the VPN traffic is able to reach Host-A via Internal interface from external , and the Host-A also able to telnet to the Management port, but just cannot ping. Host-B is hosting on the same subnet of the Management port, which is able to ping and telnet. It is hard to say that it is related to the routing or IP Spoofing as Host-A is able to telnet to the Management port.

Regards,

Steve

Preview file
32 KB
0 Helpful

Aditya Ganjoo
Cisco Employee
Cisco Employee
In response to Steve Cheung

‎03-24-2016 08:10 AM

Hi Steve,

Can you try taking asp captures on the ASA ?

Try initiating a continuous ping to the management IP and apply cap asp type asp-drop all and share the output.

Do a no cap asp after you are done.

Regards,

Aditya

Please rate helpful posts.

0 Helpful

Steve Cheung
Level 1
Level 1
In response to Aditya Ganjoo

‎03-28-2016 11:47 PM

Hi Aditya,

Sorry for the late response as the Easter holiday.

Just made the cap asp type asp-drop all and captured the details below.

vpnc001# capture asp type asp-drop all
vpnc001# sh cap asp detail trace dump

4 packets captured

   1: 14:18:24.976267 6d36.3c5c.ac4c 1503.0100.160d 0x1f0a Length: 27

0x0000   1503 0100 160d 6d36 3c5c ac4c 1f0a 41a3        ......m6<\.L..A.
0x0010   12e8 7852 50de 7fa0 36ab 6a                    ..xRP...6.j Drop-reason: (np-socket-closed) Dropped pending packets in a closed socket

   2: 14:21:24.985621 068b.997b.fa2f 1503.0100.16e2 0xe490 Length: 27

0x0000   1503 0100 16e2 068b 997b fa2f e490 e07a        .........{./...z
0x0010   9e23 4aa9 eddb 98d1 b985 dd                    .#J........ Drop-reason: (np-socket-closed) Dropped pending packets in a closed socket

   3: 14:25:24.984324 d183.bf53.3a40 1503.0100.16fe 0x60d9 Length: 27

0x0000   1503 0100 16fe d183 bf53 3a40 60d9 b672        .........S:@`..r
0x0010   ca33 9cdd 35bb 0370 f49d 94                    .3..5..p... Drop-reason: (np-socket-closed) Dropped pending packets in a closed socket

   4: 14:28:24.994592 176f.a611.d5e1 1503.0100.16c8 0xe38c Length: 27

0x0000   1503 0100 16c8 176f a611 d5e1 e38c d3c6        .......o........
0x0010   42d8 f347 a614 df94 b3df 88                    B..G....... Drop-reason: (np-socket-closed) Dropped pending packets in a closed socket

4 packets shown

Then I did the cap asp on the management interface. 10.142.100.60 is my desktop PC, and the ASA management is 10.146.120.13.

vpnc001# cap asp interface management
vpnc001# sh cap asp

110 packets captured

   1: 14:35:35.748176       10.146.120.13.23 > 10.161.84.100.41235: P 828846642:828846644(2) ack 3093954475 win 32768
   2: 14:35:35.785863       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846644 win 43486
   3: 14:35:35.785893       10.146.120.13.23 > 10.161.84.100.41235: P 828846644:828846664(20) ack 3093954475 win 32768
   4: 14:35:35.822879       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846664 win 43486
   5: 14:35:36.005569       10.142.100.60 > 10.146.120.13: icmp: echo request
   6: 14:35:36.945934       10.161.84.100.41235 > 10.146.120.13.23: P 3093954475:3093954477(2) ack 828846664 win 43486
   7: 14:35:36.945965       10.146.120.13.23 > 10.161.84.100.41235: . ack 3093954477 win 32768
   8: 14:35:36.946087       10.146.120.13.23 > 10.161.84.100.41235: P 828846664:828846666(2) ack 3093954477 win 32768
   9: 14:35:36.983042       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846666 win 43486
  10: 14:35:36.983072       10.146.120.13.23 > 10.161.84.100.41235: P 828846666:828846686(20) ack 3093954477 win 32768
  11: 14:35:37.020125       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846686 win 43486
  12: 14:35:37.143059       10.161.84.100.41235 > 10.146.120.13.23: P 3093954477:3093954479(2) ack 828846686 win 43486
  13: 14:35:37.143089       10.146.120.13.23 > 10.161.84.100.41235: . ack 3093954479 win 32768
  14: 14:35:37.143181       10.146.120.13.23 > 10.161.84.100.41235: P 828846686:828846688(2) ack 3093954479 win 32768
  15: 14:35:37.180303       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846688 win 43486
  16: 14:35:37.180334       10.146.120.13.23 > 10.161.84.100.41235: P 828846688:828846708(20) ack 3093954479 win 32768
  17: 14:35:37.222812       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846708 win 43486
  18: 14:35:37.253938       arp who-has 10.146.120.246 tell 10.146.120.243
  19: 14:35:37.404382       arp who-has 10.146.120.249 tell 10.146.120.243
  20: 14:35:37.547518       10.161.84.100.41235 > 10.146.120.13.23: P 3093954479:3093954482(3) ack 828846708 win 43486
  21: 14:35:37.547548       10.146.120.13.23 > 10.161.84.100.41235: . ack 3093954482 win 32768
  22: 14:35:37.547640       10.146.120.13.23 > 10.161.84.100.41235: P 828846708:828846709(1) ack 3093954482 win 32768
  23: 14:35:37.584625       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846709 win 43486
  24: 14:35:37.584656       10.146.120.13.23 > 10.161.84.100.41235: P 828846709:828846737(28) ack 3093954482 win 32768
  25: 14:35:37.621809       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846737 win 43486
  26: 14:35:38.102625       10.161.84.100.41235 > 10.146.120.13.23: P 3093954482:3093954485(3) ack 828846737 win 43486
  27: 14:35:38.102655       10.146.120.13.23 > 10.161.84.100.41235: . ack 3093954485 win 32768
  28: 14:35:38.102747       10.146.120.13.23 > 10.161.84.100.41235: P 828846737:828846738(1) ack 3093954485 win 32768
  29: 14:35:38.139702       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846738 win 43486
  30: 14:35:38.139732       10.146.120.13.23 > 10.161.84.100.41235: P 828846738:828846817(79) ack 3093954485 win 32768
  31: 14:35:38.176748       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846817 win 43486
  32: 14:35:39.515140       10.161.84.100.41235 > 10.146.120.13.23: P 3093954485:3093954487(2) ack 828846817 win 43486
  33: 14:35:39.515171       10.146.120.13.23 > 10.161.84.100.41235: . ack 3093954487 win 32768
  34: 14:35:39.515323       10.146.120.13.23 > 10.161.84.100.41235: P 828846817:828846819(2) ack 3093954487 win 32768
  35: 14:35:39.554933       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846819 win 43486
  36: 14:35:39.554963       10.146.120.13.23 > 10.161.84.100.41235: P 828846819:828846913(94) ack 3093954487 win 32768
  37: 14:35:39.592086       10.161.84.100.41235 > 10.146.120.13.23: . ack 828846913 win 43486

Regards,

Steve

0 Helpful

Aditya Ganjoo
Cisco Employee
Cisco Employee
In response to Steve Cheung

‎03-29-2016 02:02 AM

Hi Steve,

From the asp captures,it seems the ASA is dropping the management traffic.

Could you try the ssh session and then check the output of sh asp table socket ?

Also please provide the output of packet-tracer of the concerned traffic ?

Regards,

Aditya

Please rate helpful posts.

0 Helpful

Steve Cheung
Level 1
Level 1
In response to Aditya Ganjoo

‎03-29-2016 02:39 AM

Hi Aditya,

Please see the capture below. It looks like it dropped the ICMP from different subnet. If the ICMP from the same subnet, it responded properly.

vpnc001# sh asp table socket


Protocol  Socket    State      Local Address                                Foreign Address
SSL       00004e78  LISTEN     10.146.120.13:443                            0.0.0.0:*

TCP       00008778  LISTEN     10.146.120.13:23                             0.0.0.0:*

SSL       0000ffe8  LISTEN     202.136.215.70:443                           0.0.0.0:*

DTLS      00013428  LISTEN     202.136.215.70:443                           0.0.0.0:*

RELAY     b12c14c8  ESTAB      202.136.215.70:443                           114.92.15.40:51556

RELAY     b12c4af8  ESTAB      10.146.122.2:44857                           10.146.104.44:3389

RELAY     b14439c8  ESTAB      202.136.215.70:443                           180.171.99.178:11202

RELAY     b1444bf8  ESTAB      10.146.122.2:18622                           10.146.104.64:3389

SSL       b14b28e8  ESTAB      202.136.215.70:443                           114.92.15.40:52886

TCP       b14b8b18  ESTAB      10.146.120.13:23                             10.161.84.100:33855

SSL       b14d5758  ESTAB      202.136.215.70:443                           180.171.99.178:14121

vpnc001# cap asp interface management trace match icmp any any

vpnc001# sh cap asp

33 packets captured

   1: 17:22:43.742515       10.142.100.60 > 10.146.120.13: icmp: echo request
   2: 17:22:48.715432       10.142.100.60 > 10.146.120.13: icmp: echo request
   3: 17:22:53.716393       10.142.100.60 > 10.146.120.13: icmp: echo request
   4: 17:22:58.716286       10.142.100.60 > 10.146.120.13: icmp: echo request
   5: 17:23:03.744987       10.142.100.60 > 10.146.120.13: icmp: echo request
   6: 17:23:08.719384       10.142.100.60 > 10.146.120.13: icmp: echo request
   7: 17:23:13.715462       10.142.100.60 > 10.146.120.13: icmp: echo request
   8: 17:23:18.722801       10.142.100.60 > 10.146.120.13: icmp: echo request
   9: 17:23:23.734810       10.142.100.60 > 10.146.120.13: icmp: echo request
  10: 17:23:28.716698       10.142.100.60 > 10.146.120.13: icmp: echo request

  75: 17:28:21.196767       10.146.120.243 > 10.146.120.13: icmp: echo request
  76: 17:28:21.196950       10.146.120.13 > 10.146.120.243: icmp: echo reply
  77: 17:28:21.199162       10.146.120.243 > 10.146.120.13: icmp: echo request
  78: 17:28:21.199299       10.146.120.13 > 10.146.120.243: icmp: echo reply

Also captured the telnet traffic for reference.

vpnc001# cap asp interface management trace match tcp any any
vpnc001# sh cap asp

  7: 17:30:18.931409       10.142.100.60.50412 > 10.146.120.13.23: . ack 2002624703 win 64860
   8: 17:30:18.931851       10.146.120.13.23 > 10.142.100.60.50412: P 2002624703:2002624706(3) ack 2835369266 win 32768
   9: 17:30:18.985544       10.142.100.60.50412 > 10.146.120.13.23: P 2835369266:2835369269(3) ack 2002624706 win 64857
  10: 17:30:18.985559       10.146.120.13.23 > 10.142.100.60.50412: . ack 2835369269 win 32768
  11: 17:30:18.985590       10.146.120.13.23 > 10.142.100.60.50412: P 2002624706:2002625985(1279) ack 2835369269 win 327
68

Just thinking there are any hidden command for restrict the ICMP from different subnet.

Regards,

Steve

0 Helpful

Aditya Ganjoo
Cisco Employee
Cisco Employee
In response to Steve Cheung

‎03-29-2016 02:40 AM

Hi Steve,

You can restrict the icmp traffic using icmp deny <subnet> <interface name>

And as per the captures all the traffic is dropped by the ASA.

Are we using any VPN filter on either end ?

Regards,

Aditya

Please rate helpful posts.

0 Helpful

Steve Cheung
Level 1
Level 1
In response to Aditya Ganjoo

‎03-29-2016 02:48 AM

Hi Aditya,

The ASA management port is connected to the LAN directly, and my desktop as well. Other than the routers, there are no firewall and VPN filtering enabled in between. Moreover, my desktop is able to ping other hosts on the same subnet of the management port. The ASA also configured to permit ICMP from Any to Management

icmp permit any management

Regards,

Steve

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card