@viragomann said in [NAT Outbound WAN IP X to WAN IP Y not working]

If pfSense would do this, the DNS client would ignore and drop the response packet. If he is requesting X, hence he is awaiting a response from X and will ignore any other source IP.

I know in that simple case it wouldn't work, but that's what needs to be done in my setup. It's an ugly workaround for a problem we currently have.

I think I've found my mistake. In my case, random Z is asking pfsense box Y a request, that request is DNAT'd and forwarded to the pfSense box X. Both X and Y share the same firewall states via pfSync. So I thought, as X is aware in its states of the box Y's DNAT, it would simply follow it back with the auto-SNAT; just as any other normal NAT rule.

But X doesn't take Y's DNAT into account, and instead replies directly to Z, bypassing Y, so it cannot be auto-SNAT'd back to source Y. So that's why I wanted to force the rewriting of X to Y using my own DNAT rule. It'd be nice if we could do that too.

What I need to do on box Y is to add a VIP of W, and SNAT Z to W along DNAT Y to X. Then X would reply to W which would be SNAT'd back to source Y and DNAT'd back to destination Z.

Thanks for the support @viragomann. Have a nice day!

@pmai72 said in Mail Server Not Working:

Is it still something missing?

Probably. Can't tell right now.
You have world's most famous log file at your disposal. It's the file nearly every post (=mail) master looks at 24/24H, as it is very important.

/var/log/mail.log

It has all the details.

edit : /var/log/mail.log is the file and location for most mail servers.

@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.