If I had to do in this way: [image: zn206r.jpg] [image: wi3ghs.jpg] [image: 2wqtnnk.jpg] [image: sm3m6t.jpg] I would still have the Internet service on the LAN? Thanks Bye

Your NAT and rule looks ok.  Get rid of those last two rules on WAN.  Non-floating rules are processed top-down, first-match so that block on the end will never get triggered, and you don't definitely want the Allow Any rule above it.  All your other NATs seem to work ok?  Do you know for sure that the NAT'd server accepts connections?  When in doubt, use the built-in pfSense packet capture to sniff on LAN (filtered by the .101 server) and see if traffic is getting past the firewall.  You can also sniff the WAN for rely traffic back to the external client.

There is nothing saying you have to use pfsense as dns… But you do no need to use a dns that will resolve the fqdn your asking about to your rfc1918 address.  This could be your AD dns, this could be bind running on some other box on your network, etc. If your clients are using say googledns or some other public dns - then no split dns would not work would it ;) Public dns is not going to return your rfc1918 address, and if it did - then that would be a rebinding attack normally.. And not a good idea.

@Derelict: Under Advanced System Settings , a field is available called Public IP Override . Any address put into that field will be pasted into the address SIP field Did you do this? No. Pass rules do not log unless you explicitly enable that on the rule. Again, that shows good two-way SIP initiated by the Phone IP followed by OUTBOUND traffic to the Phone IP on ports 7076 and 7077. That will have to be passed at the Phone IP side. Welp, I set that field to my WAN IP and now it's working.  Thank you!

Limiters + NAT is fixed in 2.4.

thanks for your answer. But, i need more than one IP adress, that's what i have tu use virtual IP … nerver mind ... Renaud

@KOM: Yes, by abstracting the actual IP address used to access the resource. Thanks KOM.  I will try that in the a.m.  And No NAT Reflection either way did not work for me.

So your goal is to have less dns queries going out your wan, so vs clients sending querys to outside dns A, B and C… They would think they are asking them but really just get back your cache (if there was one) in pfsense. While this might be useful if you had 1000's of clients, or even say hundreds of them all asking some outside dns.  You can lower your wan queries for dns by just blocking outside and they should be using what you hand them via dhcp, or what you tell them to setup statically.  If they don't then dns just wouldn't work for them - and then you save all their wan traffic ;) If what your wanting to do is have all your iot sort of devices that hard code dns and use your pfsense cache.  Ok - but how many iot devices do you have?  dns traffic really not all that much..  The few bits you save  by just using your pfsense cache wouldn't be much unless you had a shitton of devices ;) Also the stuff iot devices dns for, their CC hosted on CDNs normally has really low TTL's in the first place.. So while you might cache it for 5 minutes, next device would just create another wan query..  So again unless you really had a shitton of devices doing a shitton of queries to all kinds of stuff with longer ttl's the bandwidth savings is going to be very very minor..

"What's the trainwreck?  " Any attempt at support on FB.. I mean really!!  Its worse the subreddit.. Ok clearly that is a trainwreck as well..  So you marked solved so what is working?? Have you even read the port forwarding doc??  Seems like your just clicking random shit hoping it works?? ;) https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense Why do you have rules to allow your lan and wifi networks on your WAN interface as source traffic???  Completely pointless.. Why do you have 4 rules in a row that are any any.. Then calling them blizzard downloader? You do understand then your block rule at the end becomes pointless. Rules are evaluated top down, first rule to trigger wins - no other rules are looked at.  Traffic is evaluated inbound to the interface where pfsense first see's the traffic so rules like source net of lan on your wan would never in a million years do anything.  When would traffic inbound to your wan interface come from your lan network?? What is the attempted point of blocking wifi to the wifi address.  You know the wifi network could just access your firewall on your lan IP, or your wan IP.  Is that rule to block access to the firewall or stop wifi from going else where on say your lan or internet.  Because with that rule only blocking ports that were not allowed to the wifi address.  The default block rule at the end would stop everything else that wasn't in your allow rules..  So not sure what you were trying to do there? Not sure what is in your aliases in your NATS..  But those are all wrong expect the one that lists wan address as destination.. What I would suggest is you start over..  delete all these rules and leave the default any any rules lan side interfaces.  Delete all your port forwards. What do you want to do?  Why are you forwarding a RANGE of Ports to what I assume is an alias with lots of different IPs in it..  That is not going to work.. Pick the port your different torrent devices are going to run on.. Make sure they run on different ones.  The create the port forward - per the doc link shown to 1 of these devices.  Validate it works, then go to your next utorrent client, etc.  If you can ot get a port forward to work then https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting Then we can move on to whatever other ports you want to forward..

@Derelict: Your SIP provider would be the one with what is needed there. I am the SIP provider. This is a completely internal deployment.  I have various sites and at each site there is a PBX/VOIP/SIP router which communicate amongst themselves to provide seamless intersite communication. Your diagram does not show: Where the PBX is (if any) The VOIP/SIP Router is the local PBX.  I thought that would be self explanatory. Where the phones are (if any) Phones are on a VLAN (10.10.11.0/24) on the LAN (10.10.10.0/24).  However, I'm not sure this is relevant as my primary problem is with the communication between my local and remote PBX servers, which I'm not sure is relevant to the location of the client phones. I'll explain further below: Where the SIP trunks are (if any) There are no onsite, or indeed off-site lines here.  I'm simply trying to get intersite (extension to extension) calling working. People need to realize that there is no "VoIP." They are all different and your SIP/PBX PROVIDER is the one who should know what needs to happen. Not necessarily how to make pfSense do it, but at least what pfSense needs to do. I'll explain some more details.  The VOIP system I'm using is an Allworx brand solution.  The process for creating a link between sites is fairly straightforward and I have it working at 7 sites globally.  One site has a "master" controller PBX.  Every other site must join to this master site, but after that the master provides info about all the other slave sites to each slave, and so the slaves maintain direct and independent communication with each other even if the master site goes offline (mesh network topology). The process for joining us simple.  You input the master site's IP into the slave site and a join request is issued.  You then login to the master site and accept the request and everything else is automatic. The status screen for the multisite network shows an Inbound and Outbound link status for each remote site relative to each local site.  There are three possible status for each link: pending (no response received), syncing (communication in process), and active (all good). From the slave site (in my diagram), I am able to successfully join to the master, and both directions show active links, but internal site to site calls do not work.  However, the slave site fails to sync with any of the other slaves.  All outbound links to the other slaves show as active, while all inbound links remain as pending.  This is what indicates to me that there is an issue with the routing that does not involve the local client phones directly.

Glad to hear, but really there was never a question that it was a better approach and would work ;) Natting has always been a workaround/hack to networks that overlap or napt when you need to have many IPs share the use of single ip.  This work around sometimes is useful in rfc1918 space a quick and dirty way to get something done. But in general if there is no absolute reason to nat, then you shouldn't.. If its rfc1918 to rfc1918 and you control both sides then not the way to do it.. And transit networks you would think were some new concept or something. I don't really understand the almost daily posts where they come up, the most common being asymmetrical routing issues because they didn't use a transit.

What rules did you change?  Do you recall? I'm having similar sounding problems, but everything looks right to me. https://forum.pfsense.org/index.php?topic=121139.0

Fixed it thanks!!

What exactly do you want to achieve? I really don't understand what you want here, but you can create a firewall rule that blocks all traffic from your network to destination any.

This is from a CoD forum: PS4 TCP:    80, 443, 1935, 3480 UDP:  TCP and UDP:  3478-3479, 3074, 3075 By default a new rule in pfSense is created using TCP. Have you remembered to change that to TCP/UDP for some of the rules?

Ahh, so for all the 16 external IP's I have (except the 3 used by the fw's and CARP), I set up an IP Alias to point at the CARP VIP? I had a feeling it had something to do with the fact that I'm trying to forward to addresses that aren't the actual WAN one, and was looking at issue 7 in the guide, but couldn't really wrap my head around it off hand. Thanks, I'll give that a whirl, appreciate it. Edit: Great! That fixed it. No more cranky users. Thanks for the ELI5 explanation.

I would probably have to get about +800 to take the other side of that. (Underdogs would be outright ISP blocking, Double NAT, etc)

Glad you got it working. If you really want to part with $5, please send it here: https://www.freebsdfoundation.org/donate/