09-18-2018 04:01 AM - edited 02-21-2020 08:15 AM
Hi All,
I think i have a pretty simple issue/question. I have a interface called "LSPXSG4". This interface has a ACL named "LSPXSG4_access_in". Within this ACL i have a few ACE's, but the following are interesting:
access-list LSPXSG4_access_in line 10 extended permit tcp host 172.24.0.43 172.24.0.0 255.255.0.0 eq https (hitcnt=7100098) 0x35047896 access-list LSPXSG4_access_in line 18 extended permit ip host 172.24.0.43 172.24.0.0 255.255.0.0 log informational interval 300 (hitcnt=13122) 0xcfa26d33
There are no denies before/inbetween these lines.
As you can see i have set-up logging for line 18 because i want to know what traffic is involved in this "permit ip" statement.
To my confusion, i see the following lines on the SysLog server:
2018-09-18 12:13:38 Local6.Info 192.168.20.71 Sep 18 2018 12:13:39: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.99.13(56014) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:15:35 Local6.Info 192.168.20.71 Sep 18 2018 12:15:37: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.142.208(45253) hit-cnt 1 300-second interval [0xcfa26d33, 0x00000000] 2018-09-18 12:15:36 Local6.Info 192.168.20.71 Sep 18 2018 12:15:38: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.98.81(55814) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:16:49 Local6.Info 192.168.20.71 Sep 18 2018 12:16:51: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.33.4(60432) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:19:12 Local6.Info 192.168.20.71 Sep 18 2018 12:19:14: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.143.95(46592) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:25:04 Local6.Info 192.168.20.71 Sep 18 2018 12:25:07: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.161.125(21874) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:25:23 Local6.Info 192.168.20.71 Sep 18 2018 12:25:26: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.147.134(59052) hit-cnt 1 first hit [0xcfa26d33, 0x00000000] 2018-09-18 12:26:54 Local6.Info 192.168.20.71 Sep 18 2018 12:26:57: %ASA-6-106100: access-list LSPXSG4_access_in permitted tcp LSPXSG4/LSPAPPAMD211(443) -> Zorgnet/172.24.141.241(7358) hit-cnt 1 first hit [0xcfa26d33, 0x00000000]
As you can see, the hex-code (0xcfa26d33) does match line 18 of my ACL. But there are 2 things i don't understand:
I don't seem to understand these logs entries. Normally you would send from a random port to a defined port (tcp/443 in this case).
09-18-2018 05:29 AM
Hi there,
In answer to your questions:
1) Yes.
2) ACE #10 you have a source port of TCP/any (ie not specified) and a destination port of TCP/443 . Since it is clients in 172.24.x.x connecting to LSPAPPAMD211, they will be using ephemeral port numbers not TCP/443.
Whereas the ACE #18 doesn't specify port numbers, hence you see the hits there.
Remember this is an inbound ACL on LSPXSG4 which LSPAPPAMD211 is behind, therefore you are seeing traffic where LSPAPPAMD211 is the source.
Use the following to get the ouput you expect, move the port argument:
! access-list LSPXSG4_access_in line 10 extended permit tcp host 172.24.0.43 eq https 172.24.0.0 255.255.0.0 !
cheers,
Seb.
09-18-2018 07:33 AM
Hi Seb,
Thanks for your answer, it clears up a lot. Just to be 100% sure:
The object LSPAPPAMD211 is sending traffic to various 172.24.x.x hosts with source port 443 and various destination ports. And since those destination ports are not 443, this traffic is hitting rule #18 in stead of #10, is this right?
If that's right, then i'll just have to track down why the hell this device is sending out traffic with source port 443 and random destination ports, that sounds really weird to me.
09-18-2018 07:36 AM
Your understanding is correct.
Regarding your concerns about LSPAPPAMD211, this looks like normal HTTPS traffic to me. The clients in 172.24.x.x are connecting to LSPAPPAMD211 on TCP/443. The logs are showing the replies back to the clients.
cheers,
Seb
09-18-2018 08:53 AM
If you state it that way it looks normal, but isn't it weird that i need a seperate ACE for allowing the return packets?
09-18-2018 01:26 PM
Although an ASA will permit traffic to flow from a high security-level interface to a lower security-level on, as soon as an ACL is implemented an implicit deny is present.
Irrespective of connection state (eg return traffic) you will have to explicitly permit it in order for the communication to succeed.
cheers,
Seb.
09-18-2018 11:29 PM - edited 09-18-2018 11:31 PM
Hi Seb,
Thanks for the reply once again. I'm still having a hard time understanding this one.
Let's say the log entries are return-traffic on HTTPS requests. The traffic is initiated from devices behind the "Zorgnet" interface. On that interface i have a ACE to permit traffic from 172.24.x.x to the LSPAPPAMD211 device.
The traffic coming from the Zorgnet interface reaches the LSPAPPAMD211 machine, and the LSPAPPAMD211 replies to the HTTPS packets. I don't understand why i would have to explicitly define the return traffic on the LSPXSG4 interface. Isn't that what TCP is all about?
Src.Interface | Src.Host | Type | Dst.Interface | Dst.Host |
Zorgnet | 172.24.x.x | SYN | LSPXSG4 | LSPAPPAMD211 |
LSPXSG4 | LSPAPPAMD211 | SYN-ACK | Zorgnet | 172.24.x.x |
Zorgnet | 172.24.x.x | ACK | LSPXSG4 | LSPAPPAMD211 |
09-19-2018 01:03 AM
Forget my last statement I was thinking about routers. On the ASA the packet flow bypasses the ACL check on interface ingress if it is an esablished connection.
The only reason for ACE #18 would be for logging. You should be able to remove ACE #10 and #18 and the connections initiated from 172.24.x.x will be peritted to LSPAPPAMD211 TCP/433 by virtue of the ACL you must have configured on the Zorgnet interface.
cheers,
Seb.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide