Troubleshooting via Packet Tracer - Denied Implicit Rule

Answered Question
Jul 30th, 2010
User Badges:

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
Correct Answer by Magnus Mortensen about 6 years 10 months ago

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

Correct Answer by johuggin about 6 years 10 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
johuggin Fri, 07/30/2010 - 08:11
User Badges:

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_cisco Fri, 07/30/2010 - 09:06
User Badges:

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

johuggin Fri, 07/30/2010 - 09:17
User Badges:

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_cisco Fri, 07/30/2010 - 12:39
User Badges:

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.

Correct Answer
Magnus Mortensen Fri, 07/30/2010 - 17:12
User Badges:
  • Cisco Employee,

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 Fri, 07/30/2010 - 17:13
User Badges:
  • Cisco Employee,

Also,

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


- Magnus

hstf_cisco Sat, 07/31/2010 - 08:32
User Badges:

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!

Actions

This Discussion