First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

destination unreachable Host administratively prohibited

  • retag add tags

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

quest4answer's avatar
11
quest4answer
asked 2023-03-14 01:12:01 +0000
edit flag offensive 0 remove flag 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's avatar SYN-bit (2023-03-14 21:41:30 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

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.

Jaap's avatar
13.7k
Jaap
answered 2023-03-14 10:10:12 +0000
edit flag offensive 0 remove flag 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's avatar quest4answer (2023-03-14 18:31:51 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer