Alex,

Use vpn instead. Publishing admin port on wan is not a best practice. In order to allow admin port connection even on wan, go under Administration > device access and enable admin https on wan zone. No firewall rule is needed.

Regards

I understand your perspective but I am looking for an answer to my technical question.

(If I can't trust the efficacy of the security of the XG portal then I might as well throw it out, this is a low threat environment I am using it in,)

lferrara said:

Alex,

In order to allow admin port connection even on wan, go under Administration > device access and enable admin https on wan zone. No firewall rule is needed.

Regards

Thanks I missed that, however It already was enabled, also As it is a bridge I have a question - question when a wan and LAN zone ports are in a single bridge do the per zone policies apply per the side of the bridge? And which side (zone) of the bridge is the bridge IP address considered to be in?

I also tried binding the reverse proxy rules to port4 (LAN) instead of the bridge and making my port mapping point to that (to eliminate the reverse proxy being bound to the bridge as source of issue), but I get same error.

I also tried a path rule and not a service rule. No joy.

My goal here is to understand why this doesn't work but others do and use that to inform my understanding of the inner workings of the XG and what is the art of the possible wrt reverse publishing. I can accept this doesn't appear to work, I don't yet understand why (bug, design decision or config error).

(To be clear I have no interest in doing a straight inbound 4444 port mapping here, I am playing with remapping services to external 443, then once I have done that add another level of auth and after that apply ips to the WAF / reverse proxy / Buisness rule).

I have a thesis (wild ass guess), that because the WAF is on the bridge and the sever I am trying to access is on the same device (either via bridge port or port 4) that the stack is helpfully pushing the traffic to loop back (default behavior of most OSes when connecting to one of ones own IP) rather than putting the traffic back onto the wire, and that the 127.0.0.1 doesn't partipcate in any zone and that the admin web interface is not enabled on it.....)

Alex,

can you share the firewall rule you have created?

Thanks

Sure, is there a way for me to dump rule as text, or should I use screenshots?

Thanks for helping.

The xgadmin rule generates the 503 error.

The  syn rule does not.

Only differences in the rules are the incoming domain name and  destination host IP

I guess i should note the bridged port 1 (WAN) and port 2 (LAN) has the .83 address and port 4 (LAN) has the .17 address

The rules are listening on port 4 at the moment (as the xgadmin rule didn't work on bridge i didn't bother moving them back there)

From my LAN side i can access the webui on both .83 and .17 (even if webui is disabled on WAN zone)

I think the symptoms are identical to this https://community.sophos.com/products/xg-firewall/f/web-protection/76939/is-it-possible-to-reverse-proxy-user-portal  as i look at this more i am pretty convinced this is because the WAF funtion / OS on the appliance is actualy directing packets to 127.0.0.1 as it sees the user and admin portal IP addresses as being same host as the WAF portal.  The issue isn't sharing IP address or interface but rather the WAF letting the stack decide which port to use to send the packet rather than being explcit to put the packet on the wire.  Is there a way to have the portal listen on 127.0.0.1?

I disabled the WAF and setup a separate NGIX box as a atest.  Worked perfectly.  This is an internal issue to the Sophos XG.

Given the XG WAF doesn't support websockets I think i will stay with NGIX for reverse publishing.

Thanks for your help, shame the XG WAF is subpar on reverse publishing, i assumed it would be better than squid on pfsense, but nope :-( an improved reverse publishing platform (i.e. one that supports websockets) seems to be the number 2 request on the community suggestions.  Shame sophos don't listen.  This was for a home project and XG came so close to being great, i may keep it around for firewall but my CUJO seems to be detecting and blocking more threats!

Alex,

you should try to use a DNAT instead of a WAF rule and see if it works (if you can). If you feel confident with another product, stay with it.

Regards