Reference for blast protocol communication

[sjesse]

I have two pods in a federations, one production pod and a dr pod. The DR pod works if we point the dns name there, but I can't seem to get connections to the dr desktops from the production connection servers. I am sure its a firewall issue but I don't see any denies in our firewall logs. The only thing I can see is the remove desktop connecting from port 22443 back to the unified access gateway at what seems to be a random port. There are no blocks by connection is ended with a SYN timeout . Does anyone have a reference for the exact handshake, I'd like to run a few tests but I can't find this. I do have all the firewall rules that are listed in

Network Ports in VMware Horizon 7: VMware Horizon 7 version 7.2

For each pod, but I think there is something missing between the UAG and desktops. I just recently updated the firewall groups in both firewalls to use our virtual desktop ranges in both pods in the firewall rules for communicating with the UAGs but its still not working.

[BenFB]

For Blast we only had to allow TCP/UDP 22443 from the UAG backend NIC to the Horizon Agent. This is in addition to the Cloud Pod ports that are required between the connection servers in the two pods.

[sjesse]

Yeah thats what I have each DC has its own firewall and I have all the UAG from both environments in both firewalls in one group and one group with the reserved ranges I have for desktops in another and its allowing 22443 in both directions. Tracking this between the two firewalls is difficult without doing telnet or something. What it looks like its doing is the desktop is trying to connect to the UAG first, and I think the UAG has to connect to the desktop first and thats being blocked but I can't prove it yet because no blocks are being recorded.

[BenFB]

The traffic is initiated from the UAG to the Horizon Agent. What I bet you are seeing is that the firewall state no longer exists and the Horizon Agent is trying to respond to the connection initiated by the UAG. The state is no longer valid in the firewall so it's denied but you see it as new traffic (It would be a destination of the UAG with a source port of TCP 22443 and a random destination port which is the inverse of what the UAG initiated of a random source port and a destination port of TCP 22443). This sounds like a firewall or possibly routing issue.

[sjesse]

That's exactly what I'm seeing. I'm not seeing the normal connection tracking denies  though that I was expecting. Usually I would see that and our firewalls would and a (no connection) string in the firewall log. The desktop reaches out from 22443 to a random port, then the connection is ended with a syn timeout saying it never finished.