DHCP problem

JKnott

Use Packet Capture to see what's happening. Go right from boot up of the device, so you'll get the full 4 step sequence. Filter on port 67 or 68.

PM_13

@JKnott thanks for the pointer, I will try it out and share details here. But your post also sparked another thought. Yesterday I made few new rules on LANs to separate out devices based on trust. See attached screenshot for the new rules I inserted on LAN-1, I turned these rules off and the main router SSID seems back online but still cannot connect to satellites.

I did not think that these rules will have any impact on wireless router but seems otherwise and I have no idea why or how.

PM_13

@JKnott I did some search on Google and found this:
"The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client."

Does it make sense to allow access for port 67 & 68 for LAN clients for Orbi Routers and Satellites?

JKnott

@PM_13

Given the problem seems to have started with the new rules, I suggest you start there. You can disable them and then see if the problem persists. If not, then you have a problem with your rules.

kiokoman

the first DNS rule is wrong, the second, DNS can also be tcp.
it does not force anything, if you want to force LAN-1 to use pfsense for dns you need a NAT rule with destination ip of pfsense interface

PM_13

@kiokoman I got these two rules from the steps mentioned in pfNGBlocker tutorial so your comment peaked my curiosity. Just did a quick test and really feeling stupid!!

I will check out the NAT option later today, thanks for pointing out the flaw in the rules.

PM_13

@JKnott & @kiokoman I managed to solve the initial problem of using Orbi as AP, seems like I turned off DHCP server on LAN...not sure what I was thinking but that was the root cause.

Also found this handy guide that helped the DNS issue too
https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-queries-to-external-resolvers.html

Thanks to both of you for your input

Gertjan

@PM_13 said in DHCP problem:

Does it make sense to allow access for port 67 & 68 for LAN clients for .....

You were told that an - LAN type - interface without (GUI) firewall rules doesn't pass any traffic 'in'.

Well, how to say this ..... that wasn't entirely true "they lied"..

Check out the /tmp/rules.debug file. It's a human readable file.
You'll discover many things. One of them is that DHCP traffic (UDP, ports 67 ...) are actually open.

With no rules what so ever on an interface, when you hook up a device, it will ( ! ) obtain a DHCP lease - if there is a DHCP pfSense server running on that interface.

JKnott

@Gertjan

Quite so. When I set up my guest WiFi a couple of days ago, the first rule allowed ping to the interface (172.16.3.1), the 2nd was to block everything to the entire 172.16.0.0 /16 block. It works fine.

Here are the rules:

PM_13

@JKnott Does pfSense offer "isolation mode" by default?

If not then hosts on VLAN3 can communicate with each other using ARP and bypass firewall rules.

JKnott

@PM_13 said in DHCP problem:

@JKnott Does pfSense offer "isolation mode" by default?

That's a function of the access point, not pfSense. And yes, mine does. Here's what it says:

Enable AP Isolation - Isolate all connected wireless stations so that wireless stations cannot access each other through WLAN. This function will be disabled if WDS/Bridge is enabled.

However, I'm not worried about whether guests can connect to each other, not that I have a lot of guests at any one time (or ever).

Also, ARP doesn't do much, other than provide a MAC address for an IP address. It's not even part of IP. It predates it.