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

@kbarrett said in Keeping Source IPs: Company unfortunately wont allow it Will not allow you to post up what? What your internal rfc1918 address are? WTF?? Someones tinfoil hat is so freaking tight its cutting off the blood flow.. Like giving away you live on main street. Without even knowing what country your in, let alone state, etc. Pretty worried about telling someone you live on the planet earth ;) There is zero issue with post up some arbitrary IP space, and interface be it wan or lan. Hide your rfc1918 space if you want. I just need to see if your using lan as an outbound nat.. Are you using public IP space internally? Not sure how you expect help - when you come back 23 days later and don't even post up an answer to the question. Yes, I am NATing the incoming traffic. If you are source natting external traffic to your webserver - than yeah it is always going to see the IP you natted it too.. Why would you be doing that? Other than circumvention of some firewall running on where your forwarding too.. If you want to see the actual public IP of a client out on the internet talking to something you port forward traffic too, then don't source nat.. Do you understand the difference between a port forward and what I am saying with a source nat? Do you have something in your outbound nat using the LAN interface? vs the WAN - if so that would be a source nat for traffic coming from the internet going to something on your Lan net.. Here - do you have something like this in your outbound nat rules? [image: 1631710185015-sourcenat.jpg] if I forwarded traffic to something on my 192.168.10/24 network - to that device on 192.168.10.X it would look like I am coming from the IP address of my Lan Address.. That is a source nat. edit: BTW to any would be hackers - please don't hack me now that I have given away that my internal networks use rfc1918.. Like every other internal network on the planet ;)

@salmanghiyas Split DNS is basically just overriding local DNS for a hostname. So the entire Internet resolves www.example.com to a public IP, and devices on the LAN are told www.example.com is a private IP via a host override.

@killmasta93 said in Access Website internally?: but wanted the Let encrypt on NGINX rather then on pfSense "Letsencrypt"is a concept, a brand, not code. It needs, on 'your' side, a program, most often scripts like Python, bash etc that runs on some system (OS). NGINX is a web server; that, on request from a web browser, gets files from its local storage and send it to the browser asking for it. It does not natively execute programs or scripts. Your NGINX runs on a device (host) : install certbot, acme.sh or whatever script you like, that interfaces with the Letenscrypt API servers. The traffic will just flow through pfSEnse, as any other traffic.

@kom said in incoming NAT issue: @salmanghiyas That should only be a problem if you're frequently adding new block rules. Usually, you configure the firewall and then mostly leave it alone. If your situation requires these changes then it's best to set a time to make your changes outside of business hours. Or, you can use the state table (Diagnostics - States) and filter for destinations you're trying to block and then only reset those states instead of all established states. Thank you !