They aren't. Not Aliases. But VIPs are ON THIS firewall, so it fits the description and the docs to the letter. All IPs that are on interfaces on that firewall. So that matches.
In fact an Alias belongs to TFW ... I had just hoped with an 1:1 Nat on it it would not ...
It still does but if you have defined a BiNAT entry, then the IP gets rewritten FIRST and thus no longer matches "this firewall" as the packet now is destined for the internal IP and has to match it. But it's way too easy to make errors that way so just define the IP you want to match (either by WAN address or by selecting the VIP you want) and use that in NAT/Rules so you're safer that way :)
Also move the WebUI port away from 443 and disable the auto redirect for it, that safes many headaches! We recommend using 4443 and explicitly blocking that on WAN-style interfaces can help avoid the "oopsie" of presenting your webUI to the world :) The rule is just a bonus though as you don't commonly have 4443/tcp allowed inbound anyways.
What could possible have changed in an update that every other port forward works, other than plex? And if there was - why is mine working? I would think if there was something the boards would be a flame with users complaining.. There are a lot of pfsense/plex users.
So something sure is going on with the OP setup, but what that is impossible to figure out without some basic validation of what is going on.
What is more likely.. Something else changed.. There is a know issue if you have multiple wans, which I do not.. But that would effect all port forwards, etc.
Maybe he is using pfblocker and getting new rules for geoip blocking the IPs that plex uses to check.. Those ips can change.. I have a specific list in pfblocker that updates those for example.
Maybe during the update his public IP changed, or maybe plex is reporting the wrong public IP, etc.. There are lots of pieces to the puzzle for sure. Finding the missing piece is not possible without some actual info..
Maybe his plex is on a new local IP, and he is forwarding to the wrong IP? etc. etc..
I have same situation, no matter what I do I can't get a second phase 2 to come up when it uses a subnet that doesn't directly exist on a local interface.
could you please tell me what exactly you did so i can compare with my conf
in my case i have
Palo Alto --- IPsec ---- Pfsense --- IPsec --- AWS
Despite extensive testing before release it's still possible to hit this in 2.5.1 CE but not as far as we know in 21.02.2 (Plus). Though it's unclear what the difference there is. https://redmine.pfsense.org/issues/11805
I wouldn't because, in my view, that complicates things.
You have two services that need http and https. You have to pic one for each port.
In a virtual server setup you can serve http and https depending on the host name request.
1 server > 2 websites
Unfortunately you have...
2 servers > 2 websites (your firewall http and your nextcloud http)
This is why you need to (again, in my view):
1 - Go to: system > advanced > change your port to something else, like me. I serve it on port 10000
Note: You will want to first make a firewall rule to allow port 10000 on your WAN. Firewall > Rules > Floating allow any to 10000 TCP
Here's the advanced web port change.
Once you change your web port on your firewall from http port 80 /https port 443 > you've free'd those up to be used on something else. Now you're doing http/https on port 10000 :-)
Now you can make a NAT rule:
firewall > nat > that says, anything from your WAN on http port 80 and https port 443 > go to your private IP 192.168.1.whatever (or whatever private IP's you're using).
Hope that helps.
That's how we've done these things in the past. Not using standard ports on your firewall for web management helps cut down on the BS even though they'll find you eventually. 10000 is a common port used in web servers as is 8080, and many others.
Alternatively, you could host your nextcloud on an alternative port too like 4434 or something and NAT 4434 > 443 on your private LAN side too. That would maintain the firewall defaults BUT we've found when publishing your owncloud URL that people will often hit the firewall interface not knowing they need to type in https://ip_address_here:4434
...so it can get confusing.
Always take a backup of your firewall before making and testing these changes :)
I don't think it's going to work to have the same public IP subnet on both the router WAN and the DMZ. It won't know where to route. I think you'll need to use 1:1 NAT to forward the IPs to the DMZ servers.
re: outbound NAT try
Destination: any (the Internet)
NAT Address: publicIPofServer1
Also remember to set up firewall rules on the DMZ network allowing access out. They only exist by default on LAN.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.