@viragomann

Thank you again. I assume that this also would explain why I did see some kind of traffic with the port sniffing. Apologies for the confusion, my ignorance with assuming masquerading certainly didn't help. Lesson learned!

@viragomann I'm using "Any" as port config for accessing the GUI via WAN. Indeed, I need to state a specific port so I can access more than one interface via WAN. Thanks for reminding me of that!

Before anyone points this out, the rules have been turned off temporarily hence the light check marks, while testing the rules below are active.

NAT_GENERAL.png Port_Forward_NAT_Rule.png WAN_Firewall_Rules.png

Apparently this is because pfSense (pf) uses Symmetric NAT. This makes hole punching impossible.

@esilva0608 yes anything with that subnets destination must be directed to the other routers address so it can find what you want. It’s like library it needs the location of where the books or data is. Static route but just for that subnets destination, tell it to go to that firewall, do the same on the other firewall in reverse. If they are geographically separated you will need a VPN networking between them. If you can connect the routers together with a backbone cable you just need a static route.

Static route
Anything requesting the other private subnet——-send to the other firewalls ip address—>

Or you can be specific and the source could be a specific IP address only or a couple of them.

@fuckwit_mcbumcrumble
You need to add the public IPs to the WAN first. Firewall > Virtual IPs
Use type "IP Alias", select WAN interface and state the desired IP with the correct /29 mask.

Then in the outbound NAT rule at translation address you can select this IP from the drop-down. But it should also work with the alias you've already created.

@johnpoz & @SteveITS , thanks for the further feedback and the address for feature requests.

I think I'll try using a single IP address for outbound NAT for some time. With currently only around 40-50 users, that should be enough for now.

Thank you again for the quick and good help and the many considerations and approaches!

@DominikHoffmann I find it highly unlikely that any of these 5G hotspot/internet things are providing a viable public IPv4 address that you could use for unsolicited inbound traffic..

edit: hmmm well butter my butt and call me a biscuit ;)

Maybe you can do it with the verizon 5g internet

https://www.verizon.com/support/knowledge-base-227033/

@viragomann

The internal IP in the 1:1NAT it's a computer from our LAN network

bouncing the states did the trick along with the outbound NAT rule. Of course, nobody is around to answer a radio call, but I'll get to that tonight.

Thank you for working through this with me. I've never had to do this before to get a radio site working, but all firewalls aren't built the same and this is just a little quirk that I'll have to document for the future.

states_updated.png

@beluclark
What exactly do you get in the browser?

Did you tried to access it by IP or just by host name?
Sniff the traffic on WAN port 80 and 443 and enter the IP into the browser. I'd expect to see the packets.

@periko yeah if you don't want that whole network to not nat, then yeah that would work.. I would pick IPv4 only on such a rule. And you would need to need to make sure it in the correct location in your hybrid rules - they evaluate in order.

So you created a hybrid nat, or your doing manual nat.. I never understand why anyone would do manual.. If you need to do something other than the normal automatic nat, then just create a hybrid rule for the stuff you want to do different, etc.

@JustAnotherUser said in Port Forward over VPN not working....:

If you want to go over WAN anyway, assign an interface to the wg instance and enable it at site 2. This brings up a new firewall rule tab for it then.
Now go to the "Wireguard" tab, edit the existing rules and change the interface to the new one.

I'm not sure what you mean by your last sentence but, I've done the rest.

You mean, changing the interface in the filter rule?

In Firewall > Rules you will see a tab called "Wireguard". pfSense might have created a rule on this tab automatically, when you set up the Wireguard tunnel.
So go to this tab and edit the existing rule and change the interface from "Wireguard" to the interface, which you have assigned to the Wireguard instance before.
Then the rule disappears from the Wireguard tab and appear on the new interface tab.

Also in the WG settings on router 2 you have to change the "allowed IPs" to 0.0.0.0/0 to accept public forwarded traffic.

@Scottix I seem to have this same issue. However my IP's do not change for the system with websockets. I get the same issue on multiple apps that use websockets.

My DHCP is giving out the DNS servers for the two local DNS servers which both have the correct IP for the server inside the network. What I think is occurring is sometimes the clients are going to the outside network and sometimes the internal network.

Possibly when it goes out then comes back to itself I do not have a firewall rule to allow WSS maybe. However I do not understand why the dns might look outside to comeback in. I have also disabled DHCP6 but that did not resolve the issue either. Any other suggestions?

@meletechlab
Sniff the traffic to find out where it Stücks.
On pfSense use Diagnostic > Packet capture to sniff the traffic on the VPN interface. If there is nothing check the WAN.

@paul-heidenreich-0
Outbound NAT doesn't work with policy-based IPSec tunnels. You have to do the NAT inside IPSec.
It should work with VTI IPSec, however.

If you have already a phase 2 to for the NAT-IP or subnet at the remote side, an additional is not needed in most cases.

You have always have to add the remote networdk to the "local networks", no matter if you use BINAT or outbound NAT.

That's correct. But you didn't mention, that you have already done this.

@JonathanLee
Your internal device is requesting NTP from a public IP. pfSense nats it to a local IP and translates the source in the respond packet back to the origin public IP, which the client was requesting.
This is necessary that the client accepts the response. But I guess, nothing goes to the outside here.

@srytryagn said in Port forwarding securely:

I will not know the IPs connecting, so I guess a VPN solution will not work either.

Why is that? You mean you don't know the people connecting, and you can not give them the login details for your vpn? What IP they come from for a vpn connection has nothing to do with vpn working.

Not sure what ports your wanting to open, but doesn't matter if you forward X to say 192.168.1.100.. And lets say that .100 box gets compromised and some bad actor gets full control over it. That does not mean he can access everything else on your network or the pfsense gui.

As long as the rules on pfsense prevent that .100 box from going to your other networks, or even its own gui the bad actor/software would be limited to what he can talk to on the 192.168.1 network..

This is why network segmentation is an advantage.. You could also just put this box you want to allow access from the internet to its own network. So no other devices on that network.. And if does need to talk to something else on your network you could limit that to specific ports and Ips of these other devices. So again even if the .100 box is compromised it would have limited access to what you allow on the rest of your network..

Also in reduction of attack surface thing - as shown by StevITS it would be possible to limit who can use your port forward to the country or countries you would have visitors from.. Even if you have no idea what actual IP or network they would be coming from. For example I expose my plex to the public internet via a port forward. But only IPs from the US and Morocco (have family there currently) can access it. Now this doesn't really make it more secure - but it does reduce the overall attack surface a bit..