webserver with sophos utm - website not found 404 error

I am trying to host a website through Sophos UTM and setting up a DMZ
I configured the website in IIS and configured the webserver in Sophos UTM
did the port forwarding in the router tested it on the server and it worked
when I test the website I get not found 404 error this is with a NOIP hostname
when I test it with the public IP address I get forbidden error
no problem with the IIS configuration I tested it without going through Sophos UTM and it works

this is the guide I followed in configuring the webserver in Sophos UTM

pictures of my configuration, also I captured some packets but for some reason, the capture file can't be downloaded
instead, it opens it in the browser tried both chrome and opera so most of it is symbols this is part of it
 
edit: It worked but not exactly the way I want it to 
the only way for it to work is to remove the hostname from the IIS bindings and the virtual server and use my public IP address instead 
also now I'm getting a 400 error - bad request this happened after I changed in the IIS bindings IP address settings from a static address 192.168.5.5 to All Unassigned
this persists even though I changed it back to 192.168.5.5
 
I'm thinking maybe there is something wrong with my DNS configuration here is pictures of it
  • Hi

    When you say testing it, are you trying to access it from inside your own network by using the noip FQDN? If so, that same scenario happened to me after [from memory] the previous UTM firmware update and I 'fixed' it (well, more accurately, I worked around it) as is described, below. Okay, the setup is not quite the same as your one (as I'm using the WAF rather than open ports) but the symptoms you describe are identical to the ones that I encountered, so the below trick (adding my ddns.net as a DNS host to the transparent skip list) might also work for yourself.

    Firstly though, I had no need to use a DMZ entry (I have no such DMZ entries in my Sophos UTM's interface settings) as in my case, it is the WAF (reverse proxy service) itself that facilitates the WAN side access to the internal web server's web page. If you are instead just wishing to open a port (or ports) to the IIS box, perhaps it would be safer to create rule(s) in the DNAT section (Internet -> http -> WAN ) rather than opening all the ports to it? As I instead use the WAF feature, I don't need to open any ports to my internal web server (the WAF 'does that' for me) but I've just created the below example DNAT entry for only port 80 to better illustrate what I'm suggesting (where the '-Beacon R Pi' is my internal web server):

    Getting back to the access issue and in my case, I'm using UTM in transparent mode with https inspection enabled (and it sits behind an ISP router, so I am using a double NAT scheme) and I also have two internal web services (served by a Raspberry Pi on the UTM's LAN side) reverse proxied (AKA using the Web Application Filter) via UTM to its WAN side (obviously, I've also had to open the appropriate ports in the ISP router ahead of UTM). One of them is an http Internet 'radio' streaming service (provided by Darkice / Icecast) that I use WAF to harden (and it appears as an http service on the Internet) and the other is an internal http page (generated by Apache, also on a Raspberry Pi) that I've used Sophos UTM's WAF to convert to an https service by using a LE generated certificate. In both cases, I used to be able to use myddns.ddns.net to access both these services from inside my network (and obviously, I could access both from outside) but after a recent firmware update (I think it was the last one, as in 9.700-5) I lost access - as in the same symptoms that you are describing - when trying to use myddnsname.ddns.net from inside my own network (though it still worked when accessing them from outside; others reported no problems viewing the pages from the Internet).

    I was intending researching this further, but as a quick fix, I simply added myddnsname.ddns.net (so in your case, yourname.noip.net) as a DNS Host into the transparent skip list (so web protection -> filtering options -> misc -> Skip Transparent Mode Destination Hosts/Nets section) and that enabled me to again view the page (from inside) by using http(s)://myddnsname.ddns.net (and indeed, also the streaming page via http://myddnsname.ddns.net:8000).

    I intended either posting a question here about why that had changed after a firmware update, but it had no impact when looking at the site from an external network (and with the above tweak, I can now again access it from my internal network) so I didn't pursue it any further (incidentally, I also get a 404 if trying to use the external IP address, even when just attempting to access the http Icecast page).

    Hope that fixes it for you, too.

    Kind regards,

    Briain

    Incidentally, just in case you wish to instead try the WAF (as opposed to opening ports via DNAT rules) below shows the WAF settings that I use for the real and virtual servers (for the Icecast server http page on port 8000 which also externally appears as an http page on port 8000, and for the other is for a web page which is internally just an http page on port 80 and externally appears as an https page on port 443).

    Real ones

    Virtual ones

    Okay, I'm using the WAF (as opposed to a DNAT rule to open a port to the internal web server) but the symptoms are the same, so I suspect the skip list trick might work for you. I'll not suggest is as an answer; it's a shame that there isn't a 'Suggest as a kluge' tick box on this forum, though (it would be really rather amusing -and also jolly handy - if Sophos did add one, though)!

  • In reply to Briain:

    in my case, I can access the website internally and I didn't update to the recent firmware so it's possibly not the same problem 
    I was actually missing the DNAT rule so it worked as soon as I added it 

    I will try your suggestion about the WAF thanks for all your help  

  • In reply to zakaria zaki:

    Hi

    Great to hear that the DNAT rule fixed things and I'd very highly recommend having a shot of the WAF (and remember to toggle off that DNAT rule in the NAT section before toggling on your new virtual server entry in the WAF section).

    Before going any further, it would be worth having a quick look at the Webserver Protection -> Firewall Profiles (then select 'Edit' for the basic and advanced profiles, just to see what each of these profiles can bring to the party (in terms of protection); you'll see that the WAF contains a very nice set of features! For the two examples that I mentioned in my post (reverse proxy of the http Icecast page / streaming service and the reverse proxy plus http->https 'conversion' of the http Apache page) I can get away with using the 'Advanced' protection' set (including the AV scanning feature) and everything work perfectly.

    I'd first set it up with no profile (just to initially get it all working; in the virtual server settings, you might have to experiment with selecting / deselecting 'Rewrite HTML', 'Rewrite cookies' and 'Pass host header'; I have them all selected) then once you have it working, then try seeing if you can add the 'Advanced Protection' profile, then if that breaks anything, instead try the 'Basic Protection' profile.

    Have fun experimenting!

    Briain

    NB Note that as per my original post, if you can't access it when trying to use your NOIP FQDN from within your network, you might then have to add your FQDN as a DNS host into the [Destination Hosts] transparent skip list.

  • In reply to Briain:

    Good stuff, Briain!

    You can do a lot of experimenting by setting up a Virtual Server on an Additional Address on the Internal interface.  Once you have the basics as you mentioned in your post above this one, you can then start with a Firewall Profile in "Monitor" mode and learn what needs to change by looking in the log.

    Cheers - Bob

  • In reply to BAlfson:

    Hi Bob

    That is an intriguing idea (setting up an additional Virtual Server, but on an internal interface) and I'll definitely have some fun experimenting with that.

    Thank you for making me aware of the 'Monitor' feature. I hadn't spotted that one until you prompted me to go looking for it.

    Kind regards,

    Briain