SSL VPN behind Nginx Proxy Manager

[sanderl]

Is it possible to. Open 443 on an ip adress through a fortigate (yes :-)) to an nginx server. To then have that nginx server serving several urls and lets encrypt to a webserver(s). And then the magic: to have a url eg. vpn.domain.com serving back to (the internal?) interface of the fortigate. The is only 1 internet ip adress avaliable on the fortigate. And ofcourse port 80 is also forwarded to the nginx in order to renew letsencrypt. Any tips welcome. Thanks.

[emnoc]

That makes no sense if your trying to map tcp.port 443 to a nginx webserver AND the fortigate. You want to use an alternative ports 

i.e

8443=== vpn.domain.com 

443==webserver1.domain.com ,owa.domain.com ,etc.....

If you get a wildcard.cert you can use it on both the sslvpn portal/service and webserver, you can even use a SANs  and share it on the two services just place a altName for two services

i.e

altName field

DNS1=vpn.domain.com 

DNS2=web.domain.com 

DNS3=email.domain.com

Ken Felix

[sanderl]

Hi ken Felix, thank you very much for taking the time to resond to my question!

Of course it makes sense that the widely accepted port for SSL and https is 443. other ports are just "workarounds" and possibly not enabled in a guest network (hence my question). So please, can we go back to the original question and find out if that is possible?

[sw2090]

443/tcp is per default used for https and ssl on the Fortigate.

If you want to fwd that to you ngnix this makes only sense when you reconfigure your FGT to use a different Port for https and ssl before.

The domains then is only dns and Host Headername via vhost on nginx.

Of course you could create a domain that you redirect back to the FGT with nginx. Still that will require that the FGT uses a different port since 443 then would be redirected to nginx.

[otterit]

Hello,

Very interesting post. If I understood right you wish to have this kind of setup:

INTERNET --> FG [VIP TO NGINX]                   --> NGINX [FORWARD to internal interface of FG]

             FG [SSLVPN LISTEN ON INTERNAL LAN ] <--

- Creating a VIP on the FG to forward 80,443 from your public address to your internal NGINX,

- Creating your NGINX config to redirect to an internal IP from the FG (either the internal LAN or a loopback should do) and you can use 443 here as it's a different interface.

- Enabling SSLVPN on the internal interface

But even if I like the idea, I think it will be quite complicated to make it work because your Nginx will cut your TLS connection and remake one toward the FG. So all the features related to certificate checks at the beginning of the TLS connection won't work anymore and should be handed to your Nginx instead, same goes with the security of your TLS cyphers etc.

I'm curious if you achieve to make it work flawlessly so if you feel like giving a feedback, it would be great.

[emnoc]

- Creating a VIP on the FG to forward 80,443 from your public address to your internal NGINX,

The above would be easy and trivial

- Creating your NGINX config to redirect to an internal IP from the FG (either the internal LAN or a loopback should do) and you can use 443 here as it's a different interface.

The above would be solely done by the NGNIX or a LB, has nothing to do with the fortigate

- Enabling SSLVPN on the internal interface

  Yes, you could do that if you had a LB and SNAT the client into an address that is not external or public internet. That would be a turn around LB configuration and again has nothing to do with the fortigate. The src-address of the SSLVPN would have to be anything other than public/untrusted internet due to route table.

Again why do you want to do all of that? tcp.port 8443 just like 8080 are alternative ports and were selected because of that? if you want to use SSLVPN and provide that service to the internet, just enable SSLVPN on the wan interface, change the global system properties for the https-admin to something not 443 and enable the sslvpn services. Way less moving parts and since the fortigate is connected to the internet it has some type of public-address.

Ken Felix

[otterit]

I don't really agree on using different ports than the standards ones for prod. But I also see that the main issue here is hosting services with a basic internet line with only one IP address.

Based on that, I don't see any clean solutions. Using a reverse proxy external to the FortiGate seem really fun to put in place but I wouldn't want that in a final design even if it works.

Other options in my opinion would be to : not use SSLVPN and use a standard L2TP over IPSec tunnel that can be used with Windows's built-in VPN client or as emnoc mentioned, use a non standard port.

If you wish to try another "fun" idea... I saw that now the load-balancer functionnality in FortiGate enables to load balance with the http host header: https://docs.fortinet.com/document/fortigate/6.4.1/cli-reference/290620/firewall-vip (ldb-method http-host).

In this case, you won't need to use a reverse proxy as the fortigate will act as one. The SSLVPN will have to listen on a loopback.

As for the Certificate, you will have to generate it on another server with alternate names and import it manually (or script it).

[sanderl]

Hi, wanted to give this another push. Since my original question was not so successfully answered.

I have tried to change the ssl vpn port to 8443. (management to 10443 first).

Instantly I cannot longin to ssl vpn from KPN 4G mobile. Changing back to 443 works again. I believe 8443 is blocked for whatever reason...

So I would really need a stable solution to "share" that 443 port between my webserver/nginx proxy server to be able to (re)direct traffic to web servers based in http host headers and/or to a loopback address on fortigate to 443

[TRathemP]

Configure SSL VPN on a separate VDOM to keep your traffic path more straightforward. It'll be just like a standalone SSL VPN Server plopped on your LAN.

[poundy]

Just going to throw these out here too....

buy another IP address or three. 

complain to your service provider that they shouldn't be blocking legitimate business traffic, and you'll move to a different provider (because honestly, blocking ports is so 1990's)