@viragomann yup, understood. I figured out the NAT rule on the UI, was just looking at it the wrong way previously.

thanks this worked perfectly

Did a deep dive into this today (haProxy) as i had a feeling i was having ssl cert offloading issues. What i did was deleted my ACME cert under cert manager and then created a new key and re-issued the cert. I then went back to haprox and selected that cert again under the frontend and everything started working! I have a VIP which i resolve to under host override with my web servers i want to access internally via the fqdn without going cloudflare and having the extra hops while internal. That resolves the VIP and then in HA prox i am listening to my WAN address and now the new VIP address. So when it sees a request coming from internal/external it will resolve the web server.. Thank you for your help today on that..

Okay so things are stranger and my mind is hitting a wall. I did the upgrade to 21.05.1 and it went super smooth (thanks Netgate!) But! I was still having the issue were traffic from a single IP address was not getting processed in 1:1 NAT. Same as I saw in 2.4.5p1, literally any IP on the internet except the one from my SIP provider would be properly NAT'd and send through to the 3CX system. Grasping at straws I was wondering if the state created by the 3CX registering with the provider was an issue since it contained the same IP and port info as the incoming connection? (Blue is my public address, Red is the SIP provider's) [image: 1634097328881-screen-shot-2021-10-12-at-8.29.46-pm-resized.png] [image: 1634097342749-screen-shot-2021-10-12-at-8.30.33-pm-resized.png] Just for grins, I changed the trunk time at both ends to be IP based (no authentication) just to see if anything changed. For reasons I cannot comprehend, it started working. SAME source address, SAME destination address, but it's being properly NAT'd now. I literally have no idea why that worked when the other way (registration based) didn't? So I guess everything is okay now but I really really hate problems that don't make any sense and the resolution just feels like pushing off the inevitable when it breaks again. Thank you for your help, and if there's anything I've posted above that catches your eye, please let me know, otherwise I will have to be half-satisfied that it works but half-unsatisfied because there's no logical reason for it to have not worked in the first place.

@johnpoz thanks for the comments. I'm setting up a NWN:EE server. After more testing it turned out to be working perfectly from outside as some here had mentioned might be the case. I couldn't test it from within my network. Thanks very much for the suggestions and tips.

@helloha said in Certbot verification issues on webserver behind NAT: I redirected port 80 to 443 It can't work like that. (any) http request (over port 80) will fail, as http - clear http requests - will not understand the TLS type reply coming from a typical TLS web server instance. So port 80 redirects to the http instance of a web server. Port 443 redirects to the https instance of a web server. So, typically, you have always two instances of the web server running, one for each type. The port 80 type is often redirecting all the traffic to the https version, only if (example) the requested file path doesn't contain ".well-known". Details of the "http-01 challenge" challenge : https://letsencrypt.org/docs/challenge-types/ You'll discover that http://xxx.ddns.net:80 can get redirected to https://xxx.ddns.net:443, this is something else as mapping port 80 to 443.

@skiteer747 said in Opening Port: I just want to allow the same ip address in and out on a the specified port stated What IP? What device. A port forward would be to a rfc1918 IP behind pfsense when pfsense is doing nat. Open port would just be a firewall rule if wanting to allow say internet to talk to pfsense wan IP on that port. Or if your wanting a device on say pfsense lan, using rfc1918 to talk tot he internet on that port.. Happy to help - but need some details of what wanting to do exactly, and how your currently setup.

Sorry for the late response, I ended up out of the office until today. I use the Hybrid setting on all of my edge firewalls. This auto sets the NAT rules for all the internal networks and allows for custom rules that need to go out different IP's. I have been using pfSense this way for almost 10 years and remember having to do the outbound NAT a long time ago along with the 1:1, but that hasn't been an issue until now. I'm not seeing this on most of the firewalls either so I may have a misconfiguration in there, or a policy route that I missed.

@viragomann Alright, added a policy routing. Thanks and cheers :)

@goro2205 The outbound NAT is one necessary part, but it does only NAT. The second is the routing. When you want to direct certain internal devices out to the non-default gateway you have to do this with policy routing. I recently explained how to do this in another thread: https://forum.netgate.com/topic/166607/configuring-a-3rd-isp-wan-interface-to-another-lan-interface/2?_=1632396405859

@helloha pfSense cannot see the domain inside the HTTP request. NAT works simply on layer 3, the host name is only available on layer 7. This can only be done with a reverse proxy package on pfSense like HAproxy. For testing you can as well use any unused port and forward it to the other server, you just have to state the port in the request if its not 80 or 443, e.g. host.yourdomain.com:81

@johnpoz Thanks!