@viragomann Thank you Sir, i'm avoiding 1:1 NAT on new installations, but sometimes there are issues like that.

Next step is to use a LAN port on the pfSense firewall to "reproduce" the 2.1 gateway and put the modem on a dedicated port as WAN on another range. This way i think will be ok because the outbound will not be translated.

Ok,
well, that might be an issue. I have a catalyst 3560G with the corresponding VLANs on it. I did some googling and it seems that the 3560G switch does not support NAT. Could this be my problem? How can cisco make an L3 switch that does not support NAT? Is there a workaround for this problem?
Thank you in advance.
DZ

@cyrilbuchs said in Access Web server behind NAT:

Just checking with my small laptop, I cannot access the public IP (finishing by .146). And with another PC, I can??

From inside your LAN or from outside? By using the IP or the host name.

Can you please provide the whole certbot log?
Still not clear which authenticator methode it is using.

@zoltan Nope.

@viragomann i will try that, thanks :)

I answered my own question, I made the switch and it worked as expected. The autogenerated rules populated leaving all of my custom rules intact.

@omid_1985 said in Does my ISP use CG-NAT?:

As far as I'm aware, my ISP does not use CG-NAT, and I do not have double NAT (at least this is what they keep saying to me), but in pfSense and besides my WAN public address, I have another WAN_PPOE IP address which is an RFC1918 private address.

From your screenshots I'd assume that no, you do not have a CG-NATted address. Normally with CG-NAT you get assigned a 100.x range IP address from the CG-NAT gateway. That your upstream GW is a private IP is a bit unusual/strange but that may or may not have to do how your ISP is doing things.
Did you check if that IP you got (203.xx) is reachable via internet or from an external address and if you see those connections on your firewall rules logging? I like to test those things with trying to connect to e.g. a nc/telnet <ip>:12345 command from an external host to simulate access to tcp/12345 on that IP, then go to Status/System Logs/Firewall and filter for "destionation port 12345" to check if that request was blocked.
Other possibility would be to run a packet capture for that port and check if you had incoming traffic on your checkport on the IF.

If that's the case then I'd say your ISP routes or hands you that public IP and you're well.

I have another WAN_PPOE IP address which is an RFC1918 private address.

I'd guess that is for the ISPs router/modem in front of your pfSense to be available in case the connection to upstream is broken so you/a technician on site can check the modem status.

Also, considering I have a private IP address in my gateway, should I leave "Block private networks and loopback addresses" in the WAN setting disabled? It is enabled by default, but I've disabled it, which didn't change anything that I could notice.

if your public IP is indeed the 203.xx address and you are sending/receiving traffic from that address primarily, then you can enable the private block. I don't see that it would have any negative side effects then.

Cheers

Hi @chpalmer,
You were right; the problem was an incorrect gateway configuration on the webserver.

Thanks again!

@snewby said in Port Forward not working to static IP (multi-WAN):

I had thought I could just create NAT rules with the static IP as the destination

This requires that the additonal IPs are routed to your primary WAN IP.
If this is not the case you have to assign them as virtual IPs, otherwise the packets never reach your WAN on L2 base.

In the time it took to fix this critical bug, I was able to:

Set up and thoroughly test out OPNsense in a staging environment Find viable replacements for all the pfSense plugins and features I was using Weigh the pros and cons of switching to OPNsense Realize that open source pfSense has become a second class citizen Provision a new production firewall with OPNsense Manually copy the configuration from pfSense to the new OPNsense box Retire my pfSense box and switch permanently to OPNsense

@viragomann

Thank you, I think you've pointed me in the right direction. The release of 2.5.2 could not have come at a better time! Well, last week before I upgraded to 2.5.1 would have been better, but I'll take today.

https://redmine.pfsense.org/issues/11805

Yeah, the Destination of the automatically created rule is incorrect and should be 192.168.1.10, as you found out. Odd that it was created with the LAN address of the firewall as destination, unless your port forward rule was originally created that way and the firewall rule wasn't automatically updated when the NAT rule was.

@viragomann thanks again for the reply. Next Tuesday afternoon I'll be able to test it and see if that fixes it. Yes, I'll be removing it from vlan 7 and creating a VLAN just for the ASA.

@pomtom44
Yes, you can remove one of the double. Obviously there was something going wrong with automatic rule generation.

The matching parameters of the rules are:
Interface
Address family
protocol
source address
source port
destination address
destination port

If all these values are equal, the rules match to the same traffic and hence only the first one is applied while the next are ignored.

@viragomann Thanks, this just might work, appreciate the input!! Sorry for not getting back sooner, been a busy weekend rebuilding a small datacenter lol.

@sisko212
Never done, but as far as I know, it should be possible.
Change the branch for updates in System > Update accordingly.