Tunnel traffic - unable to access web admin for "HO" firewall (previously worked on UTM)

Webadmin is actually a limitation and not possible to access via IPsec.

Essentially you could use the Central Management as well to access the webadmin.

Here would be a workaround for this: https://community.sophos.com/sophos-xg-firewall/f/discussions/104507/site-tosite-vpn-cannot-access-xg-on-remote-site-using-normal-4444-port/389685#389685

Okay.

But I'm still unable to access anything using TLS/SSL when the resource is located at the HQ site via the ipsec tunnel. Is this also a "limitation?"

No, only the Webadmin is known to be not accessible. 

See the original screenshots in this thread - the issue we are having seems to be affecting all TLS/SSL traffic that is going client>SFOS>UTM>webserver (all internal). We see the traffic hitting the UTM and getting accepted but then seeing timeouts on the client..

Again, this setup worked with client>UTM>UTM>webserver.

Check the Packet capture of both appliances, where the actual drop occur. 

Because SYN seems to work. Could be a TLS issue or a packet issue.

And show us your IPsec Policy as well. 

The packet captures on each side shows communication happening between the two hosts (server and client) but when the client attempts to establish TLS, a FIN packet is sent. We are unable to determine if the XG is sending the FIN on behalf of the client since this configuration previously worked without the XG in the picture.

Do you have a TLS Inspection Rule? 

Does other traffic work across the tunnel? 

I am able to ping across the tunnel as well as SSH into the same servers I cannot access GUI for.

You could try to do the 96 Bit Trunking in the SFOS IPsec Policy. See above. 

That broke the tunnel. SA establishes but ping breaks.

That broke the tunnel. SA establishes but ping breaks.

Can you generate a tcpdump on both firewalls and extract them via wireshark? 

I would like to know the MTU Size of the packets as well as the reason for the drop. 

You can do it on SFOS first. 

tcpdump -ni any port 443 and host SERVERIP -b -w /tmp/dump.pcap

Then download it via SCP: https://support.sophos.com/support/s/article/KB-000035842?language=en_US

Eitherway, it could be a MTU problem or a TLS problem of the engine. We should be able to see the reason in the Dump. 

You can do the same dump at the same time on UTM as well. So we can compare the packets. 

Is there a way I can DM you the .pcap files?

Looking at your dumps, there is no TLS Handshake. Not even a TCP handshake. You see a simple SYN paket but UTM is not sending it and dropping it. 

based on the dump of UTM, it sees the packet (unicast to us = getting send the packet) but it does not forward it to the server. 

This means, the UTM is not forwarding this packet to the server. 

If you redo the packet captures and do a SSH as well, what do you see? 

BTW: Just for transparency: You do not see in a tcpdump on SFOS the packets going out the tunnel. Only the coming back packets. 

I sent another pcap for an attempted RDP session.