Nice.

You'll want the isp's modem/ONT in bridge mode... not DMZ mode

Hard to say without logs of the failure but the most likely error there is that the end behiond NAT is using the "My IP" as it's local identifier but the other side expect to see the external public IP there so it fails. If so change the Identifier to IP and set it to the public IP. Or chnage both ends to use non-IP identifiers. Steve

So when pfsense forwards (or resolves) - ie asks your internal NS say vs a domain override in unbound for something and it gets back rfc1918 then that would be a rebind. You can set this domain to be private, then when pfsense forwards to it, it will allow for rfc1918 to be returned. Or you could (not recommended) just turn off rebinding protection all together. Here https://www.netgate.com/docs/pfsense/dns/dns-rebinding-protections.html There really should be no reason to have to nat reflect for this if your local NS return the rfc1918 address..

That is not showing.. [image: 1545403715951-inlinepic-resized.png] Here I uploaded it for you.. [image: 1545403753668-uploadpic-resized.png] Just attached your screenshots inline.. What are your LAN rules.. Where exactly is this 10.x network somewhere out the wan? What is the network on this wan this 10.x ?? Why not show the whole address its rfc1918 for gosh sake. BTW what version of pfsense is that - it sure not current...

Would using IPV6 help solve the issue?

Anyone wih any hint? Thanks! bye, Speck

If we all got $1 for every "Gah! pfSense is hacked/broken/whatever!" and it turned out to be a configuration issue, we would all be able to retire.

For concurrent outgoing TCP or UDP connections pfSense uses different ports on a single public IP. So it's possible that all of your devices out of the /23 net have outgoing connections concurrently. However, you may configure the outbound NAT to randomly select an IP out of a stated subnet or in Round Robin mode.

Correct. pfSense won't alter the TTL for you so you can evade your ISP TOS.

@a77ila I'm facing the same issue on OVH. I see I'll need one Network interface on the PFSense VM for each Public IP... I hoped to be able to have only 1 NIC on the VM using the OVH MAC, and assign the rest as virtual IPs, but it does not seem to work this way. The problem is when i try to make a given host to exit with a choosen virtual ip instead of the default gateway. That is something I'm looking at too, I need two of my VMs to exit as two specific public IPs, but haven't managed to do this yet either :(

NAT for IPsec traffic is handled in the Phase 2, not on WAN.

@johnpoz said in NAT not opening on custom Ports: Go to a forum that supports that software... Or game players that run it... This is a forum about pfsense and general networking... Not how to run game X on OS Y... You might find 1 or 2 people here if you posted in the genera section about why your game isn't doing what your telling it.. But I would think there would be 1000's of other users on their forums that have maybe run into the problem already. If you have a question about vlans, or firewall in general then sure ok - lots and lots of people here to help with that.. Some game server not so much... Run your game on linux ;) https://ark.gamepedia.com/Dedicated_Server_Setup#Linux here https://survivetheark.com/index.php?/forums/ you prob get much better help over there. Soon as steam get more games on their system they are developing i'm moving to Linux x)

You have to outbound NAT on the interface you are forwarding the traffic out of to the target. That way the source address appears to be from an address on the target's local subnet so reply traffic doesn't get forwarded by the target server to its default gateway. If you were port forwarding TCP port 80 to LAN host 192.168.1.100 the NAT would look like this: Firewall > NAT, Outbound Select hybrid if not already hybrid or manual and save. Make a new rule: Interface: LAN Address Family: IPv4 Protocol: TCP Source: Any Destination: 192.168.1.100 - Port: 80 Translation Address: Interface Address

That's a bit of an unusual situation but I could see how it could happen. If your firewall rules are completely empty and you attempt to delete an imported NAT rule that references a firewall rule that doesn't exist, it could fail like that. I opened a ticket for it and pushed a fix: https://redmine.pfsense.org/issues/9193

@johnpoz I based my assertion, on a bad assumption. I asked for expert help. When nobody could tell me I missed something, there seemed only one explanation. No need for the kiddy stuff, we are all just trying to get this open source tool working for ourselves, correct? Apologizes to the team for bug talk.

@woodsomeister Read again the replies. The OP mentions the case that he can't control the "server", he can't "snif" on that side. So I guess the situation is answered. You saw the "@JohanGelp You can't. That's how networks work" and the more complicated "Much depends on your scenario." ?

What is the full and exact error message? You might need to check in the system log, or with it set in the problematic way, run pfctl -f /tmp/rules.debug from a shell prompt and check what it prints. Normally the syntax of the line you posted would be fine, but it's possible there is some point in some when that interface doesn't have an address which might cause pf to fail to expand the macro temporarily. In that case it might be a race condition and thus difficult to reproduce.

@johnpoz The sniff was done on the WAN interface. The floating rule must have been incorrect as it was not allowing all traffic out from the LAN bridge to the WAN (besides http/s), but was letting traffic in and to the DVR. Since the pfsense web configurator port itself is not part of the LAN bridge, it seems that's why it was accessible from the outside but nothing else was. I will recreate the rule tomorrow to show that it was the cause and post results. Either way, that rule was the only difference between a very similar working setup and this setup. I tested (refreshed) between each configuration change and nothing worked until I deleted the floating rule, which was the last change to make so that this setup matched the working setup. Sorry for the noob problem, but each new solved problem is a new learning experience and one that will not be repeated again.

I've already tried the method you mentioned. But i think there is a bug in pfSense. What i want to set is Primary dns 192.168.0.1 Secondary dns 8.8.8.8 Note pfsense ip address is 192.168.0.30 When i set primary dns 8.8.8.8 Secondary dns 192.168.0.1 Dhcp settings are right this way. And dhcp clients get the correct order from dhcp server But when i set what i require Primary dns 192.168.0.1 Secondary dns 8.8.8.8 Clients get Primary dns 192.168.0.1 Secondary dns 192.168.0.30