@panzerscope Yup or put pfsense wan IP in the dmz host role so that all traffic is forward to pfsense... Or put that device in bridge mode, so it doesn't do nat, etc. Impossible for pfsense to send anything to your plex, if it never sees the traffic because the device in front of pfsense is not sending it on to pfsense.

@johnpoz said in Port 80 not forwarding: But again wouldn't not say getting a Refused is valid test that pfsense sent on the traffic.. Maybe your ISP is blocking that traffic and sending the RST. We've already established that my ISP is not blocking those ports, since I can get them to test as open, simply by running the associated service on my server. I appreciate your help, but I think I'm going to let this sit for a while, before I have a stroke. I may come back to it later. Thanks again.

@menethoran moved.. Where you thinking outbound nat, 1:1 nat? I am not sure.. But if something is behind pfsense on port xyz, and you want something to hit your pfsense wan IP on port, and get forwarded to say 192.168.1.100:abc - then port forward is the common term used https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html#port-forwards

@vmac Yes. It boils down creating an alias with the target ip's.

I am now just deciding if we should apply a dev version to our production kit or wait it out for a stable release of 2.6

@johnpoz said in Solved - Why can i access internet from a subnet not defined in outbound NAT ?: I see you did it correctly via a "transit" Yepp - I usually have a "Interconnect IF" on my fwalls , all external traffic enters there. Well besides WAN , and OVPN. Makes Security reviews smooth(er). /Bingo

@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP: manual outbound and vpn had no impact It wouldn't have an impact unless you messed with them, or added another network and not an outbound nat and then wondered why it wasn't working ;) Its just bad setup to switch to manual, and then create the nat required for the vpn, when you could just add the hybrid nat for the vpn.. I don't use nat reflection, since in my opinion its an abomination to all things networking ;) Now in some instances true it can be useful. When some client is is hard coded to use a public IP, or when it is using external dns and no way to have it use internal for whatever reason. As to having to set a default gateway, might have to do with having a vpn setup which your pulling routes with and it gets set as the default gateway regardless of what might be shown in the gui.. Again more bad advice from the vpn providers - but then again they want you to send all traffic to them, not just the traffic you want to send.

@olddirtypossum said in Port Forwarding not Working: I have set up NAT Reflection Why ? You connect from the outside : you'll be using the (pfSense) WAN IP and a the UDP port. This port will get "natted" to the server LAN IP, using a (same or not) port, also UDP. Done. You connect from the inside : Just use the IP of the server. pfSense doesn't even come into play here, as it is a device to device connection. The 'use the WAN IP or WAN host name' on the LAN is not good practice. You could add a "DNS host override" on the Resolver settings page (bottom) : [image: 1640948793118-3b0daa09-6504-4f44-83c4-59b8843718e6-image.png] Now, when connected locally, LAN, the myserver.mypfsense.local will resolve to 192.168.1.10 (your craft server). From the outside myserver.mypfsense.local is your DynDNS that will resolve to your WAN IP. Btw : There can't be an issue that resists the Docs » pfSense software » Troubleshooting guide ;)

In case anyone sees this reply on this old post, I am having a similar issue, I did port forwarding for Minecraft Bedrock Server, Port 19132. Minecraft can see the server online and ping it but I can not connect to it. I have read through all of the Troubleshooting info from Netgate, I checked through several guides from others and all of the info was the same, so I believe I am configuring it correctly. I attempted dropping the TCP permission as Bedrock uses UDP, and I have added it back. I have set up NAT Reflection and tested the port on my Desktop and off the LAN with my phone on 5g, and still the port says closed. I have also rebooted the router. I was wondering if it had something to do with my server being in a Docker Container, but in general as long as the port is forwarded then I should be able to at least see it as open right?

@lesserbloops no problem, glad you got it sorted. It for sure is not a "optimal" sort of setup.. While I am not sure on whatever constraints your having to work with.. And sometimes you just need to get something to work, be it not how it should properly be done ;) If you have the ability I would look to not having to jump through such a hoop.. Is there anyway for example to connect pfsense to your current routers that are being used as gateways for these 2 networks via transit networks so that pfsense could be used for the firewall router joining these 2 networks together. That way users in network A could just rdp directly to the IP of network B, all you would have to do is allow the traffic you want and in what direction in pfsense. Optimally you wouldn't need the 3rd router at all, and just connect your 2 different routers via a transit so you could correctly route between your 2 network.. In a truly optimal setup those 2 routers would already be pfsense ;) I find that pictures are sometimes worth 10k words, and sometimes descriptions no matter how elegantly worded can be misinterpreted sometimes due to different use of terms or misunderstanding of how a term is being used.. The term gateway comes up a lot around here for example.. Users try and use that to describe the IP they set on pfsense interface ;) that is not a gateway, that is the interface IP.. Stating you set a gateway means to me you did that you put in a gateway address ;) Also users tend to say they did X when they really did (X+y^2) * Z + Q, etc heheheh.. So a "picture" makes sure everyone is on the same page ;) Which for example is why I drew up a quick layout of how I was understanding what you were up against, so was sure we were understanding each other.

Maybe it can be useful to prevent configuration issues, clearing cache automatically after some functions made or every REBOOT. I worked on this issue to find almost 1 month. Thank you.

@gatenet well if you lan 1 devices that need to talk to lan 2 devices that point to 192.168.16.1 as their default gateway. Just source nat your traffic from lan 1 so it looks like it comes from pfsense lan 2 IP via outbound nat on the lan 2 interface.

There may be a bug there but running without a default gateway is a bad idea and isn't doing what you think it's doing. Setting a gateway in rules only affects traffic for hosts on the local networks matching those rules, not the firewall itself. And doing that in outbound floating rules doesn't actually help move traffic out different interfaces in most cases. The firewall itself always needs to have a default gateway. If it doesn't, services on the firewall can't properly get out to check for updates, install packages, DNS may fail, VPNs can't establish, etc. Some of that can be worked around with static routes for specific remote hosts but still, it's not ideal. The "none" setting for default gateway is primarily intended for situations where the default is managed by BGP or OSPF, NOT for policy routing. tl;dr; There may be a quirk there but you're running an unsupported configuration so not something that would be a priority to investigate.

@mcury Disabling the second rule gives me this message upon testing multiplayer connect: "It's all good There are no problems with your connection for multiplayer. If you're still having trouble, try testing your NAT type again. " NAT detection returns Open still. Thanks!