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

@viragomann Thanks for the tip. I tried this method on eve ng it was working fine. Unfortunatelly i dont have access to the other device and they are not cooperative at all, so i have to use only this pfsense for this. I belive that the other device is a virtualized juniper, i think it can handle multiple ph2 entries but they are not willing to change their configuration.

Thanks for the information!

@o12eMaRkAbLeo glad you got it sorted.. It was an odd one.. I did you had pfblocker there with auto rules. But figured you would of seen an error from before when I asked you to watch the reload.

@TrashCo92 EDIT: Solved the Problem, reinstalled my pfsense and restore my config-file, now it works as expected...

@macaruchi The last rule there is the linked rule ("NAT jce"). The circled rule allows your pfSense WAN subnet to access LAN. Though it probably wouldn't actually function unless something on that network was routing packets intended for your LAN subnet to your pfSense WAN IP. You've allowed * to access "WAN2_CENSOL address" meaning anything can access pfSense on ports 22/80/443/other. Since that includes 8443 I don't think it will also forward 8443 on via the NAT rule. Note that rule has 27.3 MB of traffic.

I'll ask my ISP can he open these ports. Thank you @viragomann and @johnpoz for help.

@frog you linked rule shows traffic/states, the numbers on the left. Did you look at https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html And the VOIP pages at https://docs.netgate.com/pfsense/en/latest/recipes/index.html#firewall-nat

I assume this is for a business as a residential isp blocks port 25

@viragomann I was thinking that was like the Netscreen devices and didn't think it would matter for us as a small company. We don't need to apply website access rules according to local IP either. That said, having just checked the Apache logs for one website it is showing the correct client IP for both LAN-based and WAN-based browsers. Thanks again, David

I confirm it works when i set 195.80.241.81/32 in NAT/BINAT. Thank you.

@greatrocket IPSec seems not to be the best choice to realize this. However, yes, you should be able NAT (masquerade) the traffic to get the forwarding work, which means, you loose information about the origin source IP. But I would do this on the internal interface of the other sites router. If you want to do it on pfSense, you will have to configure this in the IPSec phase 2. But not sure if this will work without if you do the settings only on one site. But you can try. Assuming you habe a policy based phase 2 already to connect the both local networks. A "Local Network" enter 0.0.0.0/0, at "NAT/BINAT translation" state an unused address out of the LAN. At "Remote Network" enter 192.168.1.100. Move this p 2 up to the top.

@tompark Outbound NAT masquerades outgoing traffic with the stated translation IP. This is needed for outbound traffic on the concerned interface, but it does nothing else, not routing at all. To route traffic from certain sources out to a non-default gateway, you have to add policy routing rules to the respective interface where the traffic is coming in.