@steveits oh man you beat me to it - but I got in a picture ;) hehehe

edit: Oh wait I beat you, heheheh

@johnpoz thank you, is clear.

im expecting a 6 port device to arrive for this configuration. If i have any questions i will post again. Thank you.

@johnpoz Many thanks)
Compared the settings of both Pfsense - NAT Reflection was disabled.
I set the Nat + Proxy mode, everything worked.
Thanks again!

@viragomann

Thank you for your reply.

The lan interface gateway is empty and the NAT is set in 'Manual Outbound NAT rule generation'.
In any case I found the problem, there was a NAT rule configured to a network interface group with the LAN interface included.

Avevo controllato many time NAT configuration! 🤦

Thank you very much!

Okay, as it always is. As soon as I post a question I figure out the problem HAHA

My problem was I didn't forward correctly from my "modem/router". In the UK we have modem/routers handed out by BT (as an example). Previously I setup a DMZ to solve this issue but I forgot to update the IP on that. Now I've updated it, everything is working as expected.

@bob-dig said in Port forwarding/NAT from VPN to local server:

with them in the first place?

Ahhh. OK. Thanks.
Yes, some servers allow it. One of them happened to be one I used, but switched from, due to speed issues. These speed issues are everywhere though - so I may switch back to the Windows client and Wireguard. Pretty crap, but it's that slow (to PIA) I have just about written OpenVPN off..
OpenVPN (using PFSense) is about 1.5MB/s. Using PIA Client in Windows - Wireguard - is easily over 10MB/s.

Thanks for your time and information guys. Appreciated!

@viragomann Yep, that’s definitely the difference. Upon switching, most of my network broke and it’s been challenging getting each piece back to function. However, it’s been an excellent learning experience.

I think this issue may relate to a concession I made to fix a different problem. Thanks so much.

@viragomann
Confirm. Green flag and it says port is open on public ip address.
I'm going to check the device. It should be the oroblem
Maybe it's not responding correctly.

@cibiri Hi!

Can you post your config?

I'm trying to translate with the newest pfsense but the interface changed and it's not really working

When I configure my nat rule (10.0.64.0 first IP will translate to 192.168.0.0/18 (the overlap)) - my site 0 is 172.x and all my clients (15 of them) are 192.168.0.0/18 )

I;ve also configured OPT1 but nothing.

But it's not working. Any other config somewhere I'm following this tutorial https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-nat-subnets-conflict.html

@volans But they become actual IP addresses on the firewall which is unnecessary for NAT purposes. Making individual "Other" /32 VIPs will add them to the menus too without doing that.

That's probably a GUI defect.

This was already found and fixed in 2.6.0 snapshots.

@jpgpi250
It's to be set in Firewall > NAT > Outbound.

If your Outbound NAT is working in automatic mode switch to the hybrid mode first and save it.

Then add a new rule like this:
interface: this one which is facing to the monitoring / client
protocol: TCP/UDP
source: the clients subnet
dest: the monitoring IP
dest. port: 53
translation: interface address

@viragomann you're amazing. I guess somehow the WAN was configured without selecting the gateway. This solved the issue.

At least hopefully the next person coming across missing NAT rules will find this post in their search results.

@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)
Screen Shot 2021-10-12 at 8.29.46 PM.png
Screen Shot 2021-10-12 at 8.30.33 PM.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.