Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Trying to replace a BO UTM with a XG. Running into issues where allowed networks are not allowed to access the HO :4444 (or any other web traffic within the tunnel).

The issue effects all SSL/TLS traffic. Any web traffic (regardless of port) times out with the following packet logs:

Not sure if this is coincident, but we also get the logs littered with this:

Where 192.168.12.12 is the "public" side of the XG (this is a lab behind another router) and the public IP starting with 69. is the WAN of the HO. As a note: routing works fine and we are able to ping all of these IPs with zero issues. We also see the traffic hitting the HO firewall (and being accepted).

Any suggestions are welcomed.



This thread was automatically locked due to age.
  • Additional screenshots:

    This is the traffic successfully exiting the XG (allegedly) for tunnel-bound resources:

    And the logsof the traffic being "Accepted" on the HQ side (getting screenshots is impossible due to the issue without being at HQ)

    2022:08:24-15:08:35 firewallHQ ulogd[5683]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="eth1" srcmac="dd:3e:11:67:9f:d0" dstmac=xx:xx:xx:xx:xx:xx" srcip="192.168.125.60" dstip="192.168.64.130" proto="6" length="52" tos="0x02" prec="0x00" ttl="127" srcport="58488" dstport="4444" tcpflags="SYN"

    But we see the packet is accepted.

  • Hi Aaron Becker

    Both the sites have Sophos XG firewall ? and the current firmware version running on the appliance 

    Please share current settings done on Sophos XG please go to System -->Administration--->Device Access 

    Regards

    "Sophos Partner: Infrassist Technologies Pvt Ltd".

    If a post solves your question please use the 'Verify Answer' button.

  • The HQ is a UTM and this configuration works with 0 issues when both sites were on UTM FWs.

    As you can *clearly* see in the above log line (repasted here for clarity) the packets are accepted at the UTM.

    This is occurring with *all* TLS traffic, not just web admin (4444) traffic. See the "packet accepted" below. The UTM equivalent of "device access" is not the culprit.

    2022:08:24-15:08:35 firewallHQ ulogd[5683]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="eth1" srcmac="dd:3e:11:67:9f:d0" dstmac=xx:xx:xx:xx:xx:xx" srcip="192.168.125.60" dstip="192.168.64.130" proto="6" length="52" tos="0x02" prec="0x00" ttl="127" srcport="58488" dstport="4444" tcpflags="SYN"

  • 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? 

    __________________________________________________________________________________________________________________