Troubleshooting via Packet Tracer - Denied Implicit Rule

[hstf_techy]

Hi,

I am pretty new to asa and I am trying to troubleshoot a ssh problem coming from outside interface.

Settings for the servers are identical, however, ssh failed on 2223 where 2222 is running perfect fine. I do not understand why using port 2223 is not working. Any comment or idea will be appreciated!

In summary, i am having two problem:

1. ssh from outside interface is not passing through

2. Packet tracer is reporting "denied implicit rule" with working configuration (may be i have the command wrong?)

sh running

name 192.168.10.90 cent5push01
static (inside,outside) tcp interface 2222 cent5push01 2222 netmask 255.255.255.255
name 192.168.10.80 QCCENT5
static (inside,outside) tcp interface 2223 QCCENT5 2223 netmask 255.255.255.255

sh access-list

access-list outside_access_in line 29 remark ssh1
access-list outside_access_in line 30 extended permit tcp any interface outside eq 2222 (hitcnt=31) 0xbd684543
access-list outside_access_in line 31 remark ssh2
access-list outside_access_in line 32 extended permit tcp any interface outside eq 2223 (hitcnt=23) 0x8890efe9

sh nat

 match tcp inside host cent5push01 eq 2222 outside any static translation to x.x.x.x/2222
 match tcp inside host QCCENT5 eq 2223 outside any static translation to x.x.x.x/2223

sh conn

TCP outside 204.136.26.42:2998 inside cent5push01:2222, idle 0:00:00, bytes 423044, flags UIOB

I tried to use packet tracer to troubleshot the problem, but seems like the packet tracer is not working correctly for me while port 2222 is open.

packet-tracer input outside tcp 1.1.1.1 3000 192.168.10.90 2222 detailed.

Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.10.0    255.255.255.0   inside

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x3d366f0, priority=11, domain=permit, deny=true
        hits=1627282, 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

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

[johuggin · Accepted solution]

Hello,

Your packet-tracer is destined for a private IP address. You should be using the public as defined by your static NAT. In your case, the outside interface.

try this:

packet-tracer input outside tcp 1.1.1.1 3000 [2222 | 2223] detailed

[hstf_techy]

Thanks for the prompt reply! Definitely a beginner mistake, the flow went through. Looks like the problem is on the linux box.

[johuggin]

Hey, no big deal. The conventions can change from release to release so it's hard to be 100% positive on something like that.

If you want to confirm the linux box is the culprit and you have an outside host you can test from, you might try some captures:

hostname(config)# access-list capout permit tcp host interface outside eq 2223

hostname(config)# access-list capout permit tcp interface outside eq 2223 host

hostname(config)# access-list capin permit tcp host host 192.168.10.80 eq 2223

hostname(config)# access-list capin permit tcp host 192.168.10.80 eq 2223 host

hostname(config)# end

hostname# cap capin access-list capin interface inside

hostname# cap capout access-list capout interface outside

Now, generate some test traffic to the 2223 and get the output of:

hostname# show cap capin

hostname# show cap capout

-Joe

[hstf_techy]

I was thinking about the end-to-end model, thats the reason I put in the private address instead of public address.

Back to capture...

sh cap capin

3 packets captured
   1: 15:33:22.978724 802.1Q vlan#1 P0 test_outside_ip.52761 > 192.168.10.80.2223: S 406911835:406911835(0) win 65535 
   2: 15:33:25.965419 802.1Q vlan#1 P0 test_outside_ip.52761 > 192.168.10.80.2223: S 406911835:406911835(0) win 65535 
   3: 15:33:31.954876 802.1Q vlan#1 P0 test_outside_ip.52761 > 192.168.10.80.2223: S 406911835:406911835(0) win 65535 
3 packets shown

sh cap capin

3 packets captured
   1: 15:33:22.978465 802.1Q vlan#2 P0 test_outside_ip.52761 > dest_ip.2223: S 3293377222:3293377222(0) win 65535 
   2: 15:33:25.965404 802.1Q vlan#2 P0 test_outside_ip.52761 > dest_ip.2223: S 3293377222:3293377222(0) win 65535 
   3: 15:33:31.954845 802.1Q vlan#2 P0 test_outside_ip.52761 > dest_ip.2223: S 3293377222:3293377222(0) win 65535 
3 packets shown

On a side note, ssh within the inside network has no problem.

[Magnus Mortensen · Accepted solution]

Since the packet capture shows no return traffic, If it is a linux host, make sure the following look right:

Right IP address ---> ifconfig

Right default route ---> netstat -rn

Right ARP entry for gateway ---> arp -an

- Magnus

[Magnus Mortensen]

Also,

     netstat -an will show if there is a SOCKET open for TCP port 2223.

- Magnus

[hstf_techy]

ping.netstat, arp, ifconfig all reports correclty as it should be.

However, that reminded me to use tracert and ka-boom...The gateway information was missing it was not 'permanently' saved after reboot. I added it in the network config file and it is all set. I overlooked because I was able to ping the router therefore I did not think it was the gateway...

Thanks for the tips!