Ask Your Question
0

destination unreachable Host administratively prohibited

asked 2023-03-14 01:12:01 +0000

quest4answer gravatar image

Hello: i see this periodically zero window with destination unreachable Host administratively prohibited. starting with packet 24. my question is session is gracefully ended with fin-ack on both sides.. why do i see traffic after that. Below is the capture. Also there is no FW between this two hosts. but 192.168.0.1 is zpa app connector .. acting as proxy between remote client and application server (10.10.10.1).. and there is a FW between remote client and zpa app connector.

https://drive.google.com/file/d/1LNYS... thanks

edit retag flag offensive close merge delete

Comments

One thing I noticed, but I doubt if it has anything to do with the issue is that traffic from 192.168.0.1 to 10.0.0.1 is sent to a one Cisco device and the traffic coming back is being forwarded to 192.168.0.1 from a different Cisco device (based on the mac addresses in the trace).

You mentioned that 192.168.0.1 has a proxy role in this connection. I have little experience with Zscaler, so I have no idea if there is connection multiplexing or anything else going on on the incoming connection towards 192.168.0.1. I have seen devices that act as proxy have some sort of spill-over from the client-side of the connection towards the server-side of the connection and vice-versa. It would be interesting to see how this session is handled on the other (client) side of ...(more)

SYN-bit gravatar imageSYN-bit ( 2023-03-14 21:41:30 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2023-03-14 10:10:12 +0000

Jaap gravatar image

It looks like 192.168.0.1 closes [FIN,ACK] its end of the TCP link and immediately throughs up a blocking firewall rule. This even before 10.10.10.1 can send its acknowledgement [ACK] of this closure. This [ACK] triggers the ICMP response. And then 192.168.0.1 repeat its [FIN,ACK] because it didn't receive the [ACK]. Which 10.10.10.1 dutifully does, but is rebuked by the firewall again. And so it continues until end of capture.

Now Wireshark can tell you what is happening, but not why. This is up to you to find in the involved network components, i.e. by capturing at different locations in the link and comparing the captures.

edit flag offensive delete link more

Comments

i understand what Wireshark can do and cannot do. My main question was has anyone seen this type of behavior FW causing this type of issue. Especially ACK triggering ICMP response. only way to explain this, is ACK from server packet 23 not reaching FW. in turn FW terminating session and then client trying to connect to server but FW doesn't have that session anymore so it continues to try.. but never seen icmp response..this is intermittent behavior so will be hard to do packet capture on both sides..but will check further..

quest4answer gravatar imagequest4answer ( 2023-03-14 18:31:51 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2023-03-14 01:12:01 +0000

Seen: 1,774 times

Last updated: Mar 14 '23