Amazingly, I now tried the following and it works:

I do everything in the guide (https://support.adamnet.works/t/running-on-a-transparent-pfsense-bridge/79) up to the point where I am supposed to set the LAN interface to have no IP.

I do NOT set the LAN interface to have no IP but rather do everything described after that point.

Then, at the very end, I set the LAN interface to have no IP.

Not sure why the guide does it in the wrong order? Maybe they have > 2 NICs and can reach the web interface on the third one?? I don't know but it kinda makes sense that the web interface would not be reachable from the WAN side if there are no firewall rules configured, yet, to allow that? Of course the web interface won't be reachable with only two NICs of which one doesn't provide DHCP service (the LAN NIC) and the other is likely blocked by default to allow the web interface (the WAN NIC)....

@sierrastar said in Isolating wireless devices with firewall rules while using a private DNS server:

Is there a way to set the firewall to block all traffic from private addresses except for a specified address? Or am I possibly going about this completely wrong? I just want to be able to quarantine devices but allow them to access the internet, and still be able to filter their traffic through the pihole.

With pfSense you don't block from *-addresses but to *-addresses for the most part, so I guess you have a problem with your rules to begin with.

I have found my problem...
The L2 switch in front of FW on OPT1 interface was configured with default management VLAN which forward traffic coming from other Subnet toward the OPT1 interface of the FW. it which 192.168.1.x adress appear on this interface and listed on the GUI of the FW
Thanks for your reply which help to ask me the good question.
Many Thanks

@JonathanLee its its at all FFs its a broadcast address.. You have mask set at /27 says so right there in your ifconfig.. see the "broadcast 192.168.1.31"

If you send a ping to broadcast, then yeah your going to get an answer ;) if there is anything on that network that will answer ping..

here when I send a ping to .255 broadcast on a /24 in this case 9.99 answered (one of my switches is on that 9.99 address)

$ ping 192.168.9.255 Pinging 192.168.9.255 with 32 bytes of data: Reply from 192.168.9.99: bytes=32 time=7ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64

Why would you think a multicast would be all FFs? But look, your going to see multicast on pretty much any network.. Lot of devices/OSes love to squawk on multicast.. I wish I could find a way for plex to freaking shut up for example...

ash-4.4# tcpdump host 239.255.255.250 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 16:56:51.900218 IP nas.local.lan.51573 > 239.255.255.250.ssdp: UDP, length 101 16:57:01.901295 IP nas.local.lan.51573 > 239.255.255.250.ssdp: UDP, length 101 16:57:11.901589 IP nas.local.lan.51573 > 239.255.255.250.ssdp: UDP, length 101 16:57:21.902645 IP nas.local.lan.51573 > 239.255.255.250.ssdp: UDP, length 101 16:57:31.904568 IP nas.local.lan.51573 > 239.255.255.250.ssdp: UDP, length 101

I took to blocking it at my switch.. I looked and looked to try and get plex to stop it, but it just wont shut up..

acl.jpg

If you don't like seeing the in your firewall logs, look to see what is sending it and try and turn it off there - you can really quiet windows down if you turn off some services, and make some reg changes. If it really bothers you get a switch that allows you to block it.. Or you could make some firewall rules to block it and not log it, or allow it if its say mdns and your wanting to discover over vlans with something like avahi...

But yeah on pretty much any network your going to see a bunch of it..

edit: same with broadcast - see that port block on 8667, my wifi light bulbs send out tons of those!! So I block it at the switch port the AP are connected to, so it won't go to the rest of my network..

edit2: look here my other switch at 9.98 chimed in with broadcast ping

Pinging 192.168.9.255 with 32 bytes of data: Reply from 192.168.9.99: bytes=32 time=1ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64 Reply from 192.168.9.98: bytes=32 time=1ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64

edit3: here on one of my other networks 2.200 is answering

user@NewUC:~$ ping -b 192.168.2.255 WARNING: pinging broadcast address PING 192.168.2.255 (192.168.2.255) 56(84) bytes of data. 64 bytes from 192.168.2.200: icmp_seq=1 ttl=64 time=331 ms 64 bytes from 192.168.2.200: icmp_seq=2 ttl=64 time=240 ms 64 bytes from 192.168.2.200: icmp_seq=3 ttl=64 time=160 ms

Which is my IPad ;) 192.168.2/24 is one of my wifi networks.

I encountered this bug last night while attempting to perform a bulk alias import of CDN IP ranges. 23.05.1 needs to get release SOON. Creating a FW alias should NOT cause the entire appliance to fall over... That's terrible.

I figured it out ... when copying/editing the 3rd rule I had either mis-typed or missed completely the "Firewall_Svc_ports" value for the port block.

@GorillaP said in Simple Setup assistance:

I thought the simplest way to segment off an IoT network would be to give it its own dedicated port and AP.

So you have these nice AP that support vlans, and then a switch that does as well? Or is that some dumb omada switch?

As mentioned bridging is rarely a good thing to do on your router.. Why would you not just plug in your controller into your switch?

@DominikHoffmann

The typical of the mill DD-WRT device has this option :

b6979722-7de1-463a-bce2-11232c8a43b3-image.png

which is just perfect for 'public' networks : all connected devices - to this AP - can only talk to the gateway.
Be warned : things get trickier when you have more the one AP in the network. My AP's support ebtables - some sort of iptables like firewall, but for mac addresses.

@ronv42

You can also set up MAC-to-IP Address Pairings inside of Snorts LAN Preprocs.

Screenshot 2023-06-21 at 9.42.23 AM.png

@bemethor
Not really clear, what's the benefit of the link switching at all.

pfSense is a stateful firewall. It requires to see the SYN packet of a TCP connection to pass the following packets.

You can close the connection, when switching to the other link, so the client has to establish a new one. But this has to be done on the the openswitch. And it has the drawback that it slows down the communication.

Alternatively you can circumvent the blocking of out of state packets on pfSense by adding a sloppy state rule to allow response packets without an existing state.
But this could be a security impact. So you should at least restrict it to the certain source and destination.

Since you intend to switch the connection in both directions you will need such rule on both nodes.

@stetsip

[Your ISP] <====> <WAN-pfSEnse>[PFSENSE]<LAN-pfSEnse> <=={ this is your LAN } ===> <server>

So, your "LAN" is the cable between the pfSense LAN port and the server network card.

You don't need the second network interface on the <server> device.

Well, I've made a lot of progress ... now everything works except that OpenVPN and Wireguard don't take my DNS 9.9.9.9 configured in pfsense.

I don't know where to force this setting for these two!

Do you have any advice?

@nicolas-pissard said in Wifi Callings not working:

However,

When setting up things, keep everything simple - as basic as possible
No MAC adding. No IP allow, nothing.
Connect your device, check that you see the login page. Login with valid credentials.
Check the pfSense GUI that you are logged in.
Can you visit, for example google.com ?
Can you visit ... www.tf1.fr (tf1.fr wasn't in your local D?NS cache, this test validates DNS lookups).

@nicolas-pissard said in Wifi Callings not working:

How to set up DNS port forwarding on NAT?

You mean this : Redirecting Client DNS Requests ?
Such a redirect is optional.
True, there are people that 'insist' in using their DNS, not the DNS the device got by DHCP.
That's actually their choice.
A side effect is : they can't use the free (portal !!) wifi access at mac Donald's, neither Air France, neither SNCF. And yes, neither your wifi portal. It's their choice ;) Their choice can't be your issue.

But, yes, I admit, I also feel bad for those people.
So I actually did what was explained on that "Redirecting Client DNS Requests" :

8a2ef651-3ff9-4d9b-85b1-c277e00c97e2-image.png

but again : this is not needed to make things work.
It's just an anti-shoot-in-the-foot measure.

These are the first 3 rules of my captive portal :

ed23bcd1-9627-4445-afb9-efa69794f980-image.png

The first one is the firewall rule that was added by the NAT rule.
As you can see, the counter in front of the rules are not zero : so this firewall rule (and redirecting) has been activated for some portal visitors.
Most (low bud !) phones - or their even more stupid (sorry) owners insist on using their own DNS IP : they got redirected to ..... pfSense 127.0.0.1 so the resolver can do it's work for them. If this wasn't they case, DNS would not work for them (as initially the portal doesn't allow any external access !!).
Happily enough : this is a small minority.

The second rule authorizes express all DNS traffic to the pfSense Portal interface : these counters are way higher : which shows most devices to play by the rules : they use the DNS that pfSense DHCP has been given to them 👍

The third rule : This is a safe barrier. If I missed something then let them (the portal visitor) take the wall. This rule is never used, so I took care of all the port 53 TCP/UDP traffic.

@nicolas-pissard said in Wifi Callings not working:

Also I use DNS Resolver for blocking Domain Overrides.

Just for my own curiosity :
First : you add domain overrides.
Then : you have to block them ?

I have a domain override :

4cffca0d-f7e0-4dd1-9ac8-f4b475be26e0-image.png

Where 192.168.2.1 is my pfSense portal IP network.
I need to have a host name, as I'm using https portal login page. Http is pretty dead these days, and most browser just don't allow it anymore, or start to yell 'security issue ahead' !
Portal visitors will panic and say to you : "problem" ?!
https usage is optional, of course.

Screenshot 2023-06-15 at 2.40.04 PM.png
(Blocked IPV6 as my ISP does not hand out IPV6 addresses only IPv4)

Per Netgate docs
"Ethernet rules can use Aliases for L3 source/destination matching but there is no support for MAC Address aliases at this time."

This works and shows traffic. Each IP has its MAC recorded into the rule.

Working config, Squid, Squidguard, Snort, Lightsquid, Auth-NTP, DNS over port 853, Clam-AV, UpNp for xbox alongside floating Queue CODEL this is functional and other ACLs are still working with this version. I have set the top line to block out all IPV6

Test now running for 24 hours no issues.

@ivanjrx Moderators can change the status for solved

Thanks

@alirz Not sure, but the alias should be in Diagnostics/Tables.