Try the "NAT + proxy" mode or set up split DNS instead.

I would suggest you troubleshoot the port forward like you would any other

https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

But here I just setup your exact rule.. And works just fine.

otherport.jpg

Also!!!! I would not suggest you open remote desktop to the public, even if using a different port.. If you want to rdp to your machines from the outside - vpn would be the more secure option. At a min you should lock it down to only known source IP that you would be using.

I had this open for like 10 seconds, just long enough to test it and show you that can work.. Not that its a good idea to ever do such a thing.

You understand that windows remote desktop has had multiple security issues, has been all over the news as of late with remote access issues.
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-security-explained/

I'd recommend everyone using a VPN Provider with pfSense to watch
https://www.netgate.com/resources/videos/openvpn-as-a-wan-on-pfsense.html ☺

-Rico

@johnpoz
You are 100% correct.
pfSense can port forward at any subnet behind other routers as NAT and Routing tables are correct. The problem was on my ISP and the new Public IP he gave me which was blocked in inbound traffic. SOLVED. Thanks a lot for your time.

@joregartinez You can use it just like that I think with the /29 configured on your DMZ interface. In that case, you would probably want to disable NAT for it (enter hybrid NAT mode and put a NO NAT rule for the /29 there.)

Binding services on the firewall itself (Like a VPN Server) should be able to be told to listen on the DMZ address, but I can think of things the system is going to do that will break that, like the host route to the other side. You might need a VIP on the WAN for that. Outbound NAT for connections from the firewall itself should be able to be told to use the DMZ address as well using manual outbound NAT but I have never tried that. Seems it should work just fine but you might hit some kind of route-to weirdness I'm not thinking of. But if you have a VIP on the WAN for service binding you might as well just use that.

It is generally a bad idea (as in it breaks things) to NAT connections from the firewall itself and from the WAN address. You will want to do exactly that, though.

If you do put a VIP on the WAN make it a /32. Note that hosts on the DMZ will not be able to access that VIP because they will not know it is not on their local subnet.

Again, the solution lies in marking traffic as it enters the firewall and matching that mark on its way out WAN.

https://forum.netgate.com/post/489029

The diagram is down below. There are two. That was written against the one with the blue symbols. The version of pfSense there is old but the principles haven't changed.

@Lazer13 said in Active mode ftp trouble:

Wan ip to DMZ ftp port 21

This one has been removed for testing but still no go.
I also removed the openvpn server.
No difference

Just realized that i posted in the wrong section - going to repost in the right section.

Great - glad you got it sorted.

@Derelict nevermind i understand what you mean now. I can have a gateway just don't assign it under the interface settings itself...

Should be pretty simply, actually...

First of all, you need to setup an alias for ports 14000 - 15000. See attachment:

Screen Shot 2019-09-27 at 9.29.00 AM.png

Then make a port forward on the appropriate interface (I used WAN in the example), using your alias from above as the destination port:

Screen Shot 2019-09-27 at 9.33.36 AM.png

Enter the IP address of your server in the "Redirect target IP" box. Let the NAT auto-create the firewall rule, see the bottom of the window, it says "Filter Rule Association". Make sure it says "Add associated filter rule"

That's all you have to do in pfsense.

Make sure your server is set to listen on port 13000, and if there is a built-in firewall, like in Windows, it is set to allow traffic thru.

If this is passing traffic thru the internet and your ISP, you should also make sure your ISP allows ports 14000 - 15000 to pass to you. If they block, you will never get this to work.

Jeff

@kiokoman Thank You, I now see what I may have done. Sincerely Thanks

Bull's-eye. The answer I was looking for. Thank you @viragomann very much

@Ivan007

Welcome to one of the "benefits" of NAT. When you set up port forwarding on your firewall and have a public address on the WAN side, the traffic from the web site can reach your firewall, where port forwarding is used to send it to a specific computer. When the ISP puts NAT ahead of your firewall, there is no way for you to configure port forwarding on it, so there's no route to your firewall.

NAT is a hack to get around the IPv4 address shortage and it breaks somethings Port forwarding is a way around one of the things it breaks, that is transparency along the entire path. With ISPs NAT you can longer work around it.

This is why the world MUST move to IPv6 as soon as possible. The more NAT is used, the more things break. Already with VoIP and some games it is necessary to use STUN servers, to get past NAT. I don't know that those will still work behind ISP & customer NAT combined.

@superprick said in multiple virtual ips port forward strange lan behavior (solved):

dig curl both fail

You might benefit from showing your work there.