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

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

Thanks for the suggestion.  I have no plans to replace my edge NAT device (a Ubiquiti USG).  All i wanted to do was reverse publish some internal websites.  The ability to do that with WAF and add XGs intrusion protection to the system was very attractive   My journey started here.

I only put the NGIX up (its running on my windows desktop for now) to see if i could make that reverse publish the sophos interface and the other websites.  It does so perfectly. With the one addition of supporting websockets - which i actually need for one of the apps.

That leaves me without the IPS/IDS protection of the XG which i thought i would compare to the cujo - my assumption being the XG must be way better.

So i will stick with nginx but see if i can continue to use the XG as a transparent bridge.

...2 hours later...

What's really weird is that with the nginx running on .88 address when i put the XG bridge between my USG router and the rest of my network it is now doing some VERY strange things. For example when i connect to https://servernameX.mydomain.com (note the X changes) the XG seems to do one of three things:

• bind to the wrong port - e.g. 443 on the device even though my NAT port map on my USG says to take all incoming 443 and send to ngix and ngix is supposed to remap. this would indicate it is intercepting the traffic and sending it directly to the requested host ignoring the NAT rule!?  Weird.
• One site i requested (remeber this is all external to my network) went to a different host and port (these were in the business rules but they are turned off
• presenting the self signed XG server certificate on one of my internal sites for no reason i can summarize as i have turned of all HTTP inspection and have no HTTPS inspection AND i have configured a real cert on the XG...

This weird behaviour is concerning, i don't discount user error, but this is a basic system.... as soon as i take the XG out of being inline it all works flawlessly.. hmm let me try one more thing, i will delete the disabled business rules and the hosts and web servers i defined for user with them. I wonder if 'off' isn't 'off'...

..2 hours later still..

Hmm even with a factory reset, with all protection turned off save for one ALL firewall rule the GX seems to be dicking with the inbound HTTP/HTTPS traffic from NAT router.  I give up.

I am sure this works brilliantly as a primary / traditional router-firewall but as a transparent-bridging firewall it isn't ready for prime time.

as i am sucker for staying up way past my bedtime i had one more poke and hope and found the issue wrt nginx / sophos

I hit this bug https://community.sophos.com/products/xg-firewall/f/web-protection/75282/sophos-xg-breaks-ssl-when-connecting-to-outlook-anywhere/320751#320751 

Needed to run this command

• system application_classification microapp-discovery off