Webserver Protection for SSTP on one ip

Hi, Janko, and welcome to the UTM Community!

Like apijnappels, I don't have experience with SSTP.  If you must use TCP 443, I would try Webserver Protection, but I doubt that it would work.  If you're stuck with a DNAT using TCP 443 with SSTP, you will want to change the port for the UTM User Portal to something like 2443.

Also, like apijnappels, I think your folks would be happier with the UTM's SSL VPN.  There is little additional effort to do that and it means that you don't have traffic from anywhere going to your server.  I would still change the User Portal to 2443, but I would use the UDP Protocol with the SSL VPN.  You will find it noticeably faster than SSTP on TCP 443.

Cheers - Bob

Hi bob,

thank you for your answer, and thanks apijnapples too!

1) I will try to use SSTP as it is currently deployed to all internal and external users. as a long term solution I will consider testing sophos ssl vpn :)

2) I tried a test deployment in my virtual hyper-v lab and received the following error message, while using Webserver Publishing:

2016:12:12-01:58:13 xxxxsg1 reverseproxy: [Mon Dec 12 01:58:13.175690 2016] [proxy_http:error] [pid 24576:tid 4129954672] (-102)Unknown error 4294967194: [client xxx.xxx.94.23:17214] AH01095: prefetch request body failed to xxx.xxx.40.3:6601 (xxx.xxx.40.3) from xxx.xxx.94.23 ()
2016:12:12-01:58:13 xxxxsg1 reverseproxy: id="0299" srcip="xxx.xxx.94.23" localip="xxx.xxx.54.138" size="384" user="-" host="xxx.xxx.94.23" method="SSTP_DUPLEX_POST" statuscode="413" reason="-" extra="-" exceptions="SkipURLHardening, SkipFormHardeningMissingToken" time="3229" url="/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/" server="sstp.xxx.xx" referer="-" cookie="-" set-cookie="-"
2016:12:12-01:58:21 xxxxsg1 reverseproxy: id="0299" srcip="127.0.0.1" localip="127.0.0.1" size="209" user="-" host="127.0.0.1" method="GET" statuscode="200" reason="-" extra="-" exceptions="-" time="270" url="/lb-status" server="localhost" referer="-" cookie="-" set-cookie="-"

According to Microsofts guide, one should set RRAS to HTTP listening, I used TMGs internal redirection port 6601 for that. So the traffic should go the following path:
External/Internet --443--> Sophos (Terminate SSL Tunnel) --6601--> internal RRAS (over HTTP).

The redirection seems to work but the error message is a little cryptic for me... could it be that sophos waits for a "complete" http package, although sstp is a stream?

Thanks for any help :)

Yes, your test proved that SSTP doesn't work with the reverse proxy, so you're stuck with a DNAT as I said in the post above.

Cheers - Bob

I don't suppose you ever made this work using "Webserver protection" rules?

I'm in the same boat - SSTP is currently enabled via DNAT, but that uses up the whole 443 port which could otherwise be used via host names...

Hi,

I didn't manage to solve that with webserver protection.

I think the main difficulty here is that nginx is not able to redirect the HTTP stream and separate it from the rest of the HTTP traffic.

Would that be possible, a separation of sstp and normal HTTP traffic would not make problems.

Br

Thanks for the reply.

Well, it SHOULD be possible. I mean, the problem is solvable - the old MS Forefront TMG did that, so... I'm a bit disappointed that Sophos can't. :(

You're right - now that you mention it... I once did an in depth analysis:

TMG split the traffic by host header by HTTP.sys and forwarded it to RRAS internally:

1) sstp traffic was redirected to 127.0.0.1:6601

2) normal HTTP traffic was handed over to TMG routing

On a TMG server: "netsh HTTP show urlacl" shows you what TMG is listening to in order to process sstp.

As this topic was only important for smb deployments with a single public IP I did not invest enough time to setup something similar on Linux / Sophos but I will definitely try to test setup this this week.

Hmm... I still have TFS running, albeit not used since we got Sophos and we had some ISP issues. I wonder if I could DNAT the 443 traffic back to TFS... This wouldn't solve the issue of the 443 port being used up, but it should allow for some testing. [:^)]

Let me know if there's anything I could possibly do to help out with those tests! If you manage to get this working using Webserver protection (i.e. get the 443 port back), that would be awesome!

Hmm... I still have TFS running, albeit not used since we got Sophos and we had some ISP issues. I wonder if I could DNAT the 443 traffic back to TFS... This wouldn't solve the issue of the 443 port being used up, but it should allow for some testing. [:^)]

Let me know if there's anything I could possibly do to help out with those tests! If you manage to get this working using Webserver protection (i.e. get the 443 port back), that would be awesome!