ACL logs - TCP/UDP port 0

aweise · ‎01-26-2012

Hi all - looking through my ACL logs, I've seen some inconsistencies about logging. In some cases, a router will log port zero from the ACL, but in other cases, it will show the port. Here's an example:

Router 1 ACL log:

Jan 26 10:00:59.757 EST: %SEC-6-IPACCESSLOGP: list BLAH denied tcp X.X.X.X(2853) -> Y.Y.Y.Y(25253)

Router 2 ACL log:

Jan 26 10:31:56.105 EST: %SEC-6-IPACCESSLOGP: list BLAH denied tcp X.X.X.X(0) -> Y.Y.Y.Y(0)

The ACL is an extended, named ACL that's applied on both routers...of which have the same IOS and are the same model (2811).

I know that if only the protocol is specified (IP in this case), it wouldn't show the port. However, this is the same ACL on both routers. Why would it show the port on one router and port zero on the other?

Richard Burts · ‎01-26-2012

I am guessing that there is something different in the configuration between the two routers that explains why one is logging the port number as 0. Can you post the configuration of both routers - at least the configuration of the access list and the interface(s) on which they are applied.

HTH

Rick

HTH

Rick

aweise · ‎01-27-2012

Here you are....IPs are changed to protect the innocent:

Router that logs only port 0:

RT01#sh run int fa0/0.100

Building configuration...

Current configuration : 305 bytes

!

interface FastEthernet0/0.100

description DATA VLAN

encapsulation dot1Q 100

ip address 192.168.DDD.1 255.255.255.0

ip access-group DENY in

ip helper-address 192.168.XXX.YYY

ip helper-address 192.168.ZZZ.YYY

no ip redirects

no ip unreachables

no ip proxy-arp

ip tcp adjust-mss 1436

end

RT01#sh access-lists DENY

Extended IP access list DENY

10 permit ip any 192.168.PPP.0 0.0.1.255

20 permit ip any 192.168.AAA.BBB 0.0.0.7

30 deny ip any 192.168.JJJ.0 0.0.0.255 log

40 deny ip any 192.168.BBB.0 0.0.1.255 log

50 deny ip any 192.168.CCC.0 0.0.1.255 log

60 deny ip any 192.168.DDD.0 0.0.0.255 log

70 deny ip any 192.168.EEE.0 0.0.7.255 log

80 deny ip any 192.168.FFF.0 0.0.31.255 log

90 deny ip any 192.168.GGG.0 0.0.63.255 log

100 deny ip any 192.168.HHH.0 0.0.31.255 log

110 permit ip any any

Router that logs the actual TCP port:

RT02#sh run int fa0/0.100

Building configuration...

Current configuration : 304 bytes

!

interface FastEthernet0/0.100

description DATA VLAN

encapsulation dot1Q 100

ip address 192.168.ZZZ.1 255.255.255.0

ip access-group DENY in

ip helper-address 192.168.XXX.YYY

ip helper-address 192.168.ZZZ.YYY

no ip redirects

no ip unreachables

no ip proxy-arp

ip tcp adjust-mss 1436

end

RT02#sh access-lists DENY

Extended IP access list DENY

10 permit ip any 192.168.PPP.0 0.0.1.255

20 deny ip any 192.168.JJJ.0 0.0.0.255 log

30 deny ip any 192.168.BBB.0 0.0.1.255 log

40 deny ip any 192.168.CCC.0 0.0.1.255 log

50 deny ip any 192.168.DDD.0 0.0.0.255 log

60 deny ip any 192.168.EEE.0 0.0.7.255 log

70 deny ip any 192.168.FFF.0 0.0.31.255 log

80 deny ip any 192.168.GGG.0 0.0.63.255log

90 deny ip any 192.168.HHH.0 0.0.31.255 log

100 permit ip any any

The premise of this is to block traffic from the VLAN on Fa0/0.100 to specific subnets, then allow to everything else. There is one different between the two - RT01 has the extra line to allow to an additional subnet - but that's it.

TIA,

-Andy

Richard Burts · ‎01-27-2012

Andy

Thanks for the additional information. Based on what you have posted here I am surprised that RT02 shows numeric port numbers in the ACL log output. What I have learned is that if the access list is not examining the port values then it can not report port values. Both of the routers access list are doing permit ip and not permit tcp and since it is not having to check any tcp port values then I do not see how it is reporting tcp port values.

HTH

Rick

HTH

Rick

aweise · ‎01-27-2012

Thanks, Rick. It makes sense that the logs wouldn't specify the port if the ACL is only examining the protocol, but why it shows the port on one router and not the other makes no sense. I certainly hope there isn't a bug.

Richard Burts · ‎01-28-2012

Andy

I believe that there is some explanation. Is it possible that there was a line in the access list on RT02 that had a permit or a deny for TCP and that the line was removed?

Would you try configuring a new access list on RT02 with the same content and apply the new access list to the subinterface and see if the behavior changes?

HTH

Rick

HTH

Rick

aweise · ‎01-30-2012

Rick - I don't believe that's the case. We have several remote offices that have this ACL - some have an additional line to allow traffic for a specific subnet (as I noted above), but that would be the only difference.

That said, I can create a brand new ACL for RT02 and see if that does anything. I'll post my results once I get them.

Richard Burts · ‎01-30-2012

Andy

I look forward to seeing the results of your additional testing.

HTH

Rick

HTH

Rick

aweise · ‎02-02-2012

Well, the new ACL didn't seem to help. The router that has been logging port 0 still does that, but I have yet to see any logs from the router that was reporting the actual port. I'll update once I see any logs.

CORRECTION (I got confused between the two)

The router that was reporting the actual TCP port is now reporting port 0, which is consistent with the theory that it would log that only if the protocol was being matched.

Richard Burts · ‎02-02-2012

Andy

Thanks for the update. I am glad to know that with a new access list that the behavior is what we expect - if the access list is not examining the TCP ports then it can not report any port numbers in the log messages.

I can only assume that at some point on the router that was reporting actual port numbers that the access list was coded to check port numbers and then it was updated and those lines were removed.

HTH

Rick

HTH

Rick

jp.briggs · ‎02-19-2015

I know this is super old, and I should probably start a new topic, but going to see if I get a response here.

Does this mean that a permit ip entry that logs will show up on the terminal as tcp(0)?

Richard Burts · ‎02-19-2015

You are correct that this is a fairly old thread and that frequently it is better to start a new thread. But if your question really is just a repeat of the original question then it is justified to post in the old thread.

I would be more comfortable in answering your question if you provided a bit more context and detail. But essentially the answer is yes. If you have an extended access list and the permits and denies are all using ip (and not any tcp or udp) and if some of the statements include the log parameter then the log messages for tcp and udp packets will log a port number of 0.

HTH

Rick

HTH

Rick

james.berg · ‎09-07-2018

Old post I know, however if you are looking to see the ports being used, then the ACL needs to define them. Here is a simple example of how you can see that.

ip access-list extended ACL_VLAN
permit tcp any any range 0 65535 log-input
permit udp any any range 0 65535 log-input
permit ip any any log-input

interface VLANx
ip access-group ACL_VLAN in
ip access-group ACL_VLAN out

the first two lines will log any port used in / out within the standard ranges.

The third line will log source & destination ports of (0). This tells you that non standard ports are used.

The third line is also your guarantee that you will not block traffic while trying ot see what is being used....

Richard Burts · ‎09-08-2018

Yes it is an old post. You are sort of right in your explanation. But I take exception with this statement "The third line will log source & destination ports of (0)". The third line will not log any port numbers. Lines 1 and 2 do report TCP and UDP which do utilize port numbers and the log output will report the specific port number. Line 3 will permit traffic that is neither TCP or UDP, such as ICMP, or GRE, or IPSEC, or other protocols like these and these protocols do not utilize port numbers and so the log messages will not report any port number. It is not that they are non standard port numbers it is that there is no port number in these protocols.

HTH

Rick

HTH

Rick

james.berg · ‎09-10-2018

Hi Richard - With all due respect, when outside of the the ranges of the first two lines., a port number of 0 is shown for both source & destination ... You can see evidence of this below ...

Here is a snippet from one of my Cisco 3750 stacks.
Sep 10 03:59:57.503 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted tcp 10.11.3.114(62221) (Vlan3 0050.56b0.1279) -> 10.11.5.58(9100), 1 packet
Sep 10 04:00:00.699 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.11.3.114(61659) (Vlan3 0050.56b0.1279) -> 10.11.5.57(161), 4 packets
Sep 10 04:00:00.699 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.11.3.114(61659) (Vlan3 0050.56b0.1279) -> 10.11.5.58(161), 3 packets
Sep 10 04:00:09.448 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 0.0.0.0(68) (Vlan5 2c44.fd05.6a91) -> 255.255.255.255(67), 1 packet
Sep 10 04:00:19.086 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.11.3.114(61659) (Vlan3 0050.56b0.1279) -> 10.11.5.57(161), 2 packets
Sep 10 04:00:21.771 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.65.5.177(0) (Vlan25 d072.dc98.1b81) -> 10.11.5.60(0), 1 packet
Sep 10 04:00:23.540 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted tcp 10.11.3.114(0) (Vlan3 0050.56b0.1279) -> 10.11.5.58(0), 1 packet
Sep 10 04:00:27.189 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted tcp 10.11.3.114(0) (Vlan3 0050.56b0.1279) -> 10.11.5.57(0), 1 packet
Sep 10 04:00:29.865 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.11.3.112(0) (Vlan3 0050.56b0.296c) -> 10.11.5.63(0), 1 packet
Sep 10 04:00:32.986 PDT: %SEC-6-IPACCESSLOGP: list ACL_VLAN5 permitted udp 10.11.3.114(0) (Vlan3 0050.56b0.1279) -> 10.11.5.60(0), 1 packet