@n3mmr: Costs 99 dollars to see. Then you get the free version here: https://doc.pfsense.org/index.php/Outbound_NAT

Get an IP address allocation, a layer 3 switch, and give each of your tenants a /30 (or more) and let them worry about their own firewalls. Kind of like a real ISP.

This is just what I was looking for…. (I think) The reason I want to do something like this, is WAN failover to LTE... We have a /26 IP range and host many services on site. The problem is LTE we one get a single IP and it is not even static. If we have to use the LTE we will have internet access but lose any hosted services. I would like to get a /26 range of IPs in a cloud provider and the portforward these IPs to the local servers on site. Then these will be the permanent IPs for those services. If we have to use LTE or change ISPs we would not have to think about the IPs changing or DNS ttl or anything like that.... this will also bring our uptime closer to the cloud provider's. Is this a good idea, or you think there is a smarter solution? Would IPSec or OpenVPN be the better options for the site-2-site VPN connection? Thanks

You pick your wan interface where that IP sits.. If its some sort of vip or something on the interface then when you do your export you can pick other and put in the VIP if not your wan interface ip, etc. [image: wizard.png] [image: wizard.png_thumb]

You have to bypass policy routing for internal network prior to the policy routing rule that matches. https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

@karldonteljames: I don't really want to set a rule that allows all, then another to block DMZ to LAN; I would much rather set a rule that allows DMZ to access the internet only. Problem is that you cannot define "the internet" in an alias or CIDR notation. You could make a single rule with a negotiation "allow all but LAN" with the "NOT" checkbox. Deny LAN will finally catch with the hidden/invisible "block everything else" rule at the bottom of your ruleset. Problem is that such a rule implies something that is not expressively written and thus makes it hard to understand what you were doing in future reviews/changes. With two separate rules it's obvious and visible. @karldonteljames: I think I've got this now, please correct me if I wrong. Nothing to correct, well done! And I mean really well done. You learned a lot, didn't you! @karldonteljames: Enable "Block private networks and loopback addresses" and "Block bogon networks" on all interfaces except LAN. That's usually not really needed and if you use it then that'll be on WAN at best. The "Bogon" part can come handy there but better ISP filter that anyways. Except for edge-cases you will not have traffic from private IPs to your WAN anyways. On local interfaces the "Block private networks" can do more harm than good. All local interfaces usually belong to private networks, aka  RFC1918.

Without knowing exactly how you have the NAT set up, the A pfsense will NAT to the (going to get this wrong as I don't see the diagram anymore) 10.0.8.1 IP as the client goes to the web server. Meaning, the rule is not to allow that internet client(it's internet IP) access but to allow the 10.0.8.1 IP access over port 80. This is under the assumption that OpenVPN has routing information for the 192.168.125.x, and that network exists in both pfsenses as a routable network. Internet clients will be nat'd to the IP of the interface you specify, in this case, the openVPN IP of 10.0.8.1. Again, going on conjecture and assumption of how the rules may be set up.

<breaks out="" dead="" horse="" beatin'="" stick="">Oh wait, nevermind. So, I finally found time to upgrade from 2.3.4 to 2.4.0. This upgrade seems to have fixed the rule issue I originally posted about. I upgraded and didn't have to do any wonky LAN setting changes to get IPv4 working again. So I'm going to chalk this up to weirdness in 2.3.4 since 2.4.0 doesn't seem to have this issue and since everyone should probably update to 2.4.x I'm guessing this will get no more traction as it's now out of date. Upgrades /woot. Now, to figure out why my dashboard says 2.4.2. is available but the update says I'm up to date at 2.4.0.</breaks>

Have a look at his earlier thread concerning this: https://forum.pfsense.org/index.php?topic=140777.0

That makes sense, thanks for the clarification!

You might try OpenVPN with a TAP interface, rather than TUN, as described here: https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Dear Sir Thanks for your valiable information.Now I am able to block the free DNS also.I have made an allias and apply in the NAT rule.Contents are filtering as well as free DNS are being blocked.But this is a tidious and lengthy process.There are thousands of free DNS IP are exisitng. pfSense doesn't alowing me at all to put that huge amount of ip's in my allias list. Restriction is there for the number of entries.My question is there that is there any rule will be possible in pfSense that all the request will come to the pfSense and pfSense will reject if the DNS request are not matching which are mentioned in the DNS Server of the pfSense section. Thanks in advance.

Thank you mate!!!! yes, corrected firewall rule and works immediately as expected! :-)

It still makes no sense. What is "Static routing network" and how does it work with the OpenVPN tunnels? I might need a picture. I don't immediately see the topology based on your description. See dig for a diagram with the sort of information that makes it easy for someone to help you.

I have the same problem in version 2.4.1. Did you find any solution?