Solved: Port Forwarding ASA5505 packets dropping - Page 2

staylor2112 · ‎01-18-2017

Outbound traffic works but inbound does not. I have checked my ACL and it looks correct, but I am still not seeing what I missed. I have attached our current running-config as well as a screenshot of the Packet Trace utility. Below is the detailed packet-tracer results.

Result of the command: "packet-tracer input outside tcp 8.8.8.8 888 192.168.1.88 888 detailed"

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

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit object FrontelPort1 any object FRONTELSVR1
Additional Information:
Forward Flow based lookup yields rule:
in id=0xd003f6b8, priority=13, domain=permit, deny=false
   hits=7, user_data=0xca0e8a80, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
   src ip/id=0.0.0.0, mask=0.0.0.0, port=888, tag=0
   dst ip/id=192.168.1.88, mask=255.255.255.255, port=888, tag=0 dscp=0x0
   input_ifc=outside, output_ifc=any

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xcba010a0, priority=0, domain=nat-per-session, deny=false
   hits=1193646144, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
   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=any, output_ifc=any

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xcc08d5a0, priority=0, domain=inspect-ip-options, deny=true
   hits=612753499, user_data=0x0, cs_id=0x0, reverse, flags=0x0, 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=outside, output_ifc=any

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xcca5dc28, priority=13, domain=ipsec-tunnel-flow, deny=true
   hits=373410, user_data=0x0, cs_id=0x0, flags=0x0, 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=outside, output_ifc=any

Phase: 6
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network FRONTELSVR1
nat (inside,outside) static interface service tcp 888 888
Additional Information:
Forward Flow based lookup yields rule:
out id=0xd06d4bb0, priority=6, domain=nat-reverse, deny=false
   hits=2, user_data=0xd04266d8, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
   src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
   dst ip/id=192.168.1.88, mask=255.255.255.255, port=888, tag=0 dscp=0x0
   input_ifc=outside, output_ifc=inside

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

staylor2112 · ‎01-19-2017

I can check in the morning. I know at the office end (outside interface) is open. I will check from a different ISP/Location. Also, was my capture setup correct? (see above)

Rahul Govindan · ‎01-19-2017

Yes, capture was correct. I would recommend the following capture so that you do not get your teamviewer packets in the capture also:

no capture capo

no capture capi

cap capo interface outside match tcp host <your public ip> host <ASA public ip> eq 888

cap capi interface inside match tcp host <your public ip> host 192.168.1.88 eq 888

clear capture /all

This will only capture the traffic to the server from your PC.

staylor2112 · ‎01-20-2017

Looks like the ISP is not blocking port 888, but the packet is not showing on the inside capture.

Result of the command: "show capture capo"

1: 07:22:29.641064       802.1Q vlan#2 P0 104.137.90.176.60744 > xx.xx.xx.xx.888: S 3035968005:3035968005(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
   2: 07:22:32.641202       802.1Q vlan#2 P0 104.137.90.176.60744 > xx.xx.xx.xx.888: S 3035968005:3035968005(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
   3: 07:22:38.641904       802.1Q vlan#2 P0 104.137.90.176.60744 > xx.xx.xx.xx.888: S 3035968005:3035968005(0) win 8192 <mss 1260,nop,nop,sackOK>
   4: 07:22:50.692942       802.1Q vlan#2 P0 104.137.90.176.60744 > xx.xx.xx.xx.888: R 0:0(0) win 0
4 packets shown

Result of the command: "show capture capi"

0 packet captured

0 packet shown

Rahul Govindan · ‎01-20-2017

Strange. Considering both the captures are correctly configured, looks like the ASA is not forwarding the packet to the inside interface. Can you attach the "show capture" and packet-tracer output to confirm that nothing has changed from before.

A few other troubleshooting steps you can try:

1) check the local buffer syslog for anything regarding this transaction that could indicate that the ASA dropped it.

2) Apply an ASP drop capture - this will capture all the packets the ASA drops. Steps to do this are:

a) Command "cap capasp type asp all"

b) Send traffic

c) show cap capasp | in <your public ip address>

If you are seeing this, you may get a reason for the drop in the last output. This would help in investigation on the packet drop.

staylor2112 · ‎01-24-2017

Here are the results:

Result of the command: "show cap capasp | in xx.xx.xx.xx"

110: 07:23:24.467978       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3038: F 2798950241:2798950241(0) ack 859980582 win 17922
323: 07:23:26.529666       802.1Q vlan#2 P0 125.166.73.34.19719 > xx.xx.xx.xx.23: S 1631827714:1631827714(0) win 53422 <mss 1412>
368: 07:23:27.678355       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3039: F 1129114240:1129114240(0) ack 306408100 win 17922
491: 07:23:30.934750       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3040: F 4142979249:4142979249(0) ack 1152365381 win 17922
498: 07:23:31.186437       802.1Q vlan#2 P0 209.183.104.2 > xx.xx.xx.xx: icmp: time exceeded in-transit
536: 07:23:32.180776       802.1Q vlan#2 P0 209.183.104.2 > xx.xx.xx.xx: icmp: time exceeded in-transit
542: 07:23:32.273942       802.1Q vlan#2 P0 104.137.90.176.65498 > xx.xx.xx.xx.888: S 3047924272:3047924272(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
749: 07:23:34.108621       802.1Q vlan#2 P0 209.183.104.2 > xx.xx.xx.xx: icmp: time exceeded in-transit
785: 07:23:35.180151       802.1Q vlan#2 P0 209.183.104.2 > xx.xx.xx.xx: icmp: time exceeded in-transit
790: 07:23:35.273575       802.1Q vlan#2 P0 104.137.90.176.65498 > xx.xx.xx.xx.888: S 3047924272:3047924272(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>
1138: 07:23:40.619245       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3044: F 3166783877:3166783877(0) ack 424008791 win 17922
1159: 07:23:41.274354       802.1Q vlan#2 P0 104.137.90.176.65498 > xx.xx.xx.xx.888: S 3047924272:3047924272(0) win 8192 <mss 1260,nop,nop,sackOK>
1321: 07:23:45.300735       802.1Q vlan#2 P0 64.233.177.95 > xx.xx.xx.xx: icmp: echo reply
1366: 07:23:46.300597       802.1Q vlan#2 P0 64.233.177.95 > xx.xx.xx.xx: icmp: echo reply
1394: 07:23:47.057965       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3046: F 2641336096:2641336096(0) ack 521261747 win 17922
1411: 07:23:47.178137       802.1Q vlan#2 P0 125.166.73.34.19719 > xx.xx.xx.xx.23: R 0:0(0) win 0
1426: 07:23:47.181799       802.1Q vlan#2 P0 104.137.90.176.65498 > xx.xx.xx.xx.888: R 0:0(0) win 0
1480: 07:23:47.301101       802.1Q vlan#2 P0 64.233.177.95 > xx.xx.xx.xx: icmp: echo reply
1586: 07:23:48.302047       802.1Q vlan#2 P0 64.233.177.95 > xx.xx.xx.xx: icmp: echo reply
1659: 07:23:50.275803       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3047: F 4078811515:4078811515(0) ack 739611373 win 17922
1786: 07:23:53.493642       802.1Q vlan#2 P0 52.4.30.92.42000 > xx.xx.xx.xx.3048: F 2564289710:2564289710(0) ack 875854759 win 17922

staylor2112 · ‎01-24-2017

The solution I found was in the ACL. I changed the service from just 888 to ip and now I can telnet into the servers.

Rahul Govindan · ‎01-24-2017

It definitely looks like the ASA is dropping it although there is no reason given as to why

790: 07:23:35.273575 802.1Q vlan#2 P0 104.137.90.176.65498 > xx.xx.xx.xx.888: S 3047924272:3047924272(0) win 8192 <mss 1260,nop,wscale 8,nop,nop,sackOK>

Can you paste the packet-tracer output and the latest sanitized config again? Also, was there any syslogs that showed up on the ASA when this failed?

staylor2112 · ‎01-24-2017

The solution I found was within the ACL. I changed the service from just 888 to ip and now I can telnet into both of the servers on ports 888 and 889.

Thank you for all your assistance

Stephen

Rahul Govindan · ‎01-24-2017

Glad to hear everything is working Stephen !!

emily00001 · ‎01-18-2017

There's quite a bit of nat in there but I believe you need to set it up with after-auto parameter as in the example below.

nat (inside,outside) after-auto source dynamic Inside-Network interface

That shows up after your specific nat rules for the port forwarding.