06-11-2018 07:01 PM - edited 02-21-2020 07:52 AM
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.
4 | 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.
Solved! Go to Solution.
06-12-2018 06:59 AM - edited 06-12-2018 07:00 AM
This helped me get closer to the final solution. See the original post for edited solution.
06-11-2018 09:20 PM
06-12-2018 03:43 AM
06-12-2018 05:17 AM - edited 06-12-2018 05:19 AM
@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.
06-12-2018 05:36 AM
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.
06-12-2018 06:59 AM - edited 06-12-2018 07:00 AM
This helped me get closer to the final solution. See the original post for edited solution.
06-11-2018 10:23 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: