Question on viewing dropped packets and Telnet issue

[Mark Mattix]

Hello, I have a "noobish" question about an ASA. A remote site is trying to establish a Telnet session with a private network but our ASA allowing the remote site to come in seems to be blocking the connection. I was wondering on what's the best method to capture packets or to view the status of packets being allowed or rejected by our ASA?

Would the command, "show logging asdm" display all packet information that's being allowed and also dropped on the Inside, Outside and DMZ interfaces? I'm trying to figure out the easiest command to view the traffic being allowed and also denied. Thanks!

[Karsten Iwen · Accepted solution]

The easiest way is to enable logging to a remote syslog-server where you can see the denied packets and also the allowed connections. If you don't have a syslog-server you can log to the local buffer:

logging buffered informational       ! <--- for logging to RAM

logging host inside a.b.c.d          ! <--- your syslog-server

logging trap informational           ! <--- which level to log to syslog

logging on

show logging                         ! <--- shows the local log-buffer

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Mark Mattix]

Thank you Karsten!

[Mark Mattix]

Well I have set up logging for the ASA but do not see any messages about it dropping a telnet or port 23 packet from my remote site. I also check the log of the router at the remote site and see no notifications about there being an issue.

The remote site connects over an IPSec tunnel, anyone on this site cannot access the telnet application. If you're on our main site it works fine. Pings from the remote site to anywhere on our main site work fine. I'm not sure what's going on and I have ran out of ideas on how to troubleshoot this, any help would be really appreciated!

[Karsten Iwen]

by default, all traffic leaving the IPSec-tunnel is allowed. So it's more likely that the problem is somewhere else. But you can use the command "packet-tracer" to simulate the problematic traffic.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Mark Mattix]

Hmm, if the traffic is allowed through the IPSec tunnel then the other end of the tunnel should be the only area, right? The ISP has no idea what's traveling over the tunnel so there shouldn't be an issue with that port on the Internet, right? I'll try out that packet-tracer command tomorrow, thanks!

[Karsten Iwen · Accepted solution]

please provide a diagram of your setup to see how the traffic flows.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Mark Mattix]

Karsten, could you help me understand the output of the packet-tracer command?

After issuing the command there are 4 phases and then a result. The first 3 phases Allow the packet to pass through but the 4th phase denies it.

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xcd123eb1, priority=11, domain=permit, deny=true

        hits=10857448, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

I assume these phases relate to the ACL but how do I know what portions of the ACL? Also, I'm not sure if it makes a difference but I changed some numbers in this output because I'm not sure what the values represent. Thanks for the help!

[Karsten Iwen · Accepted solution]

It's denied by the implicit "deny ip any any". But to know why you need to provide more info. The config and also your setup which addresses connect from where to which addresses.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Mark Mattix]

I finally got the issue figured out! The problem was at the remote site. In the VPN's ACL the traffic for the telnet session was not specified. I originally thought this was the issue and made the change but it didn't work. I didn't realize that the config had to be saved then the VPN tunnel rebuilt for the change to take effect. I guess the reason why the firewall said it was being denied was because the ACLs were not setup for the network but the VPN connection was still able to tunnel it through, bypassing the outside ACL.

Thanks for the help Karsten!