VPN SSL and IP on WAN interface

johnpoz

Nat is not really a security aspect.. While if port X is only forwarded to pfsense rfc1918 wan ip it would keep pfsense logs free of noise.

While nat can be seen as preventing traffic to any port on your device, and could be beneficial if your device doesn't have a firewall and ports you don't want exposed could be exposed if not behind a nat.

Out of the box all unsolicited traffic to pfsense wan is dropped out of the box anyway.

If your exposing service xyz to the public internet - doesn't really matter if natted or not from a security point of view.

I wouldn't expose the pfsense gui to the public internet be it natted or not, unless you could lock down the source IP to your known IP your coming from.

Its best for remote admin to vpn in..

Nat or Napt in general should not be seen as a security feature..

DaddyGo

@reynold said in VPN SSL and IP on WAN interface:

I need to manage the firewall remotely and my worry is that the firewall is accessible from internet with public IP so I was thinking to use natted IP on wan interface.

The firewall (NGFW) by default, all traffic is ~~rejected~~ DROPPED on the WAN interface.

so don't worry until you start opening unnecessary ports to the world

Instead of HTTPS, I would still recommend a VPN solution for remote management, something like this:

DaddyGo

@johnpoz

Oops cross-posted, almost the same

johnpoz

@daddygo hehe - yeah pretty close.

Small edit I would suggest for you

by default, all traffic is rejected on the WAN interface.

Not technically correct - the traffic is not "rejected" its dropped.. Reject on wan is almost always a bad idea.. Why would you send back a RST, you would want to just drop/ignore the traffic.

DaddyGo

@johnpoz said in VPN SSL and IP on WAN interface:

the traffic is not "rejected" its dropped.

True :)

++edit:
The DeepL spellchecker has replaced the words

reynold

@daddygo @johnpoz
Thank you guys

So, just for recap:

public IP on WAN interface
VPN solution for remote management as @DaddyGo explained

I abolutely agree with you when you says to not expose pfsense gui on internet. That is exactly what I want to obtain.

Now i know how i can do that! I will use VPN solution instead using HTTPS on a specific port.

That's absolutely the best way, instead HTTPS or NAT.

Thanks again,

johnpoz

You can run your vpn over 443 if you want.. I do - since 443 is almost always open no matter where your coming from, and you can even bounce it off a proxy (say at your work location)..

I even share this port with other services available to the public, via haproxy.. So my users can request movies for my plex ;) via that service. Haproxy does the ssl offload for that even. And using sni restrictions - if they don't send the correct fqdn, say some bot just hitting my ip on 443.. haproxy would not send the traffic through to my request service.

DaddyGo

@johnpoz said in VPN SSL and IP on WAN interface:

443.. haproxy

We use exactly this solution for our IceCast2 servers running behind pfSense, -cool stuff

reynold

@johnpoz said in VPN SSL and IP on WAN interface:

You can run your vpn over 443 if you want.. I do - since 443 is almost always open no matter where your coming from, and you can even bounce it off a proxy (say at your work location)..

OpenVPN use 1194 port by default isn't it?
Can i run VPN also on 443?

DaddyGo

@reynold said in VPN SSL and IP on WAN interface:

OpenVPN use 1194 port by default isn't it?

Yes and no, you can put it anywhere you like either to 50-60K too

Yes 443 also works :-)

++++edit:

John @johnpoz suggested 443 because it is the HTTPS port.
Therefore it is always open and this is not restricted by the ISPs, because it would be pointless

johnpoz

yeah the default udp port is 1194, this could quite often be blocked from where your at... 443 never going to be blocked if internet is open. even they are forcing traffic through a proxy you can still get your vpn connection over the proxy on 443.

udp is normally a best choice for the vpn - but hey if it doesn't work tcp over 443 is pretty much guaranteed to work - even if not optimal connection, etc.

You can run both, I run a tcp 443 instance along with a 1194 udp instance.