topic Re: Problem with ACL in Network Security

Problem with ACL Edited with solution

ACStech — Fri, 21 Feb 2020 15:52:02 GMT

The issue was that I didn't realize that I accidentally created the service with a source and destination port. The source port is randomly generated along a range of ports so, by designating a source port, I accidentally caused the access rule not to match the actual traffic that was hitting the firewall. Removing the source port fixed the issue.

Apologies if this isn't the most elegant post but I'm pretty tired of staring at this problem.

I created a custom service object for port 3001. I also created an Access Rule in the ACL for the WAN port where this traffic enters the ASA to allow this object through the firewall to an internal IP address.

My ASA 5008 is denying service to the ip/port, and the reason given is the ACL in which the permit rule exists.

Jun 11 2018

21:47:17

SourceIP

Source Port: [many]

DestinationIP

3001

Deny tcp src Outside:External IP/External Port dst Outside:External IP/3001 by access-group "WAN1Port_Outside_access_in" [0x0, 0x0]

Here's the relevant part of the access-list from show run

access-list WAN1Port_Outside_access_in extended permit object obj-tcp-eq-3001 any object obj-192.168.1.200

I've setup NAT to map an external IP to the internal IP above (192.168.1.200). This isn't the real IP, I've changed some numbers for obfuscation purposes.

object network obj-ExternalIP
 nat (Outside,inside) static obj-192.168.1.200 service tcp 3001 3001

Here's a line from the same ACL for a service/server that works, just for reference:

access-list WAN1Port_Outside_access_in extended permit object-group DM_INLINE_SERVICE_11 any object obj-192.168.1.114

DM_INLINE_SERVICE_11 is there as it gets created when you create a group of services associated with the same object. Basically, this IP has multiple services allowed to get to it.

The only Deny line in the ACL is for RDP and disabling that line does not help.

I have other external IPs NAT'd to internal IPs in a similar manner. I host servers that need HTTP, HTTPS, ssh, and etc traffic to get to them and all the other things work just fine. I could really use some help on this and I don't have the patience to deal with TAC right now.

Does anything stand out to anyone that I should check? Why isn't the ASA matching my rule and allowing traffic?

Just to clarify, the ACL from above is the same ACL that contains the access rules for all the other servers. Those are just some examples.

Re: Problem with ACL

shimenoy — Tue, 12 Jun 2018 04:20:52 GMT

Hi 🙂

Can you post the results of packet-tracer?

https://supportforums.cisco.com/t5/security-documents/troubleshooting-access-problems-using-packet-tracer/ta-p/3114976

# packet-tracer input outside tcp [src_addr] [dst_addr] 3001

Re: Problem with ACL

Dennis Mink — Tue, 12 Jun 2018 05:23:38 GMT

you re using object NAT, which is fine, but it has a lower priority, so some other NAT rule might be blocking it. do a packet trace

Re: Problem with ACL

Florin Barhala — Tue, 12 Jun 2018 10:43:57 GMT

If I correctly remember here for dst_addr use the public IP used for NAT OBJECT.
Make sure the NAT rule shown in the output is the one you created.

Last but not least how's the routing for the public IP you're using for NAT? Post some relevant config.

Re: Problem with ACL

ACStech — Tue, 12 Jun 2018 12:19:25 GMT

@shimenoy Thanks for the suggestion.

ASA# packet-tracer input outside tcp [src] 58286 [dest] 3001

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop [External IP] using egress ifc Outside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Since it is being dropped by the implicit rule (if all other rules don't match, drop packet) it looks like the firewall is not matching traffic to that access rule? Does it have anything to do with the source port being different from the destination port (the source port for this service is chosen at random from a range of ports).

I noticed a difference on our old firewall was this line which is not in the new firewall:

nat (inside,outside) source static obj-[inside IP] obj-[inside IP] destination static obj-[External IP] obj-[external IP] service obj-tcp-eq-3001 obj-tcp-eq-3001

Unfortuntately, when I try to issue that command in the new firewall, it puts a break in between "desti" and "nation" and then tells me that the invalid input is detected at that point.

Re: Problem with ACL

ACStech — Tue, 12 Jun 2018 12:36:03 GMT

I replied to this but it was marked as spam. I guess I will have to open a TAC troubleshooting ticket. Thanks for trying but no points on any of these replies.

Re: Problem with ACL

ACStech — Tue, 12 Jun 2018 14:00:38 GMT

This helped me get closer to the final solution. See the original post for edited solution.