Block rule for RFC 1918 traffic
-
Look like there is port 67 UDP traffic coming into your WAN interface.
Thats DHCP client traffic. Strange.
Ok, I saw the firewall log lines, and that doesn't make sens.If you can't stop this, I mean it didn't came from your ISP router/modem, apply this :
Check both checks and call it a day.
After all, it has happened before : DHCP traffic on the ISP side of your (WAN) network. There is a lot of garbage traffic on the Internet and the more local ISP side of their network.
-
@viragomann
pfSesne connect directly to ISP ethernet cable, no any modem or router between this. Not to clear regarding DCHP? Should set IP to static on WAN? -
@Gertjan Im not clear. Pfsense connect directly to ISP ethernet cable.
-
@Gertjan said in Block rule for RFC 1918 traffic:
Look like there is port 67 UDP traffic coming into your WAN interface.
Thats DHCP client traffic. Strange.But WAN do not have any opened ports!
pfSense plus 24.11 on Topton mini PC
CPU: Intel N100
NIC: Intel i-226v 4 pcs
RAM : 16 GB DDR5
Disk: 128 GB NVMe
Brgds, Archi -
@Antibiotic said in Block rule for RFC 1918 traffic:
Not to clear regarding DCHP? Should set IP to static on WAN?
As I wrote, this seems to be a clients request. So obviously there is a DHCP client connected to your WAN.
If the router is the only one device, it might be this. And it should have a static IP. -
@Antibiotic said in Block rule for RFC 1918 traffic:
But WAN do not have any opened ports!
Maybe.
But you have a firewall rule on your WAN that you didn't create yourself, but activated on the WAN interface settings :
and that one make showing up firewall logs lines about 1918 traffic.
So : remove the "RFC1918" option on your WAN interface settings
or
Make that option stop logging.@Antibiotic said in Block rule for RFC 1918 traffic:
Pfsense connect directly to ISP ethernet cable.
There is not only 'you' on that connection. You see that traffic.
-
@Antibiotic that traffic outbound, see the arrow in the log - and being blocked by your floating rule..
pfsense is prob trying to renew its dhcp lease.. The isp could for sure be running their dhcp server on rfc1918 space.
If your isp is running their dhcp server on rfc1918 space, your going to need to adjust your rules. I run the same type of rule, blocking rfc1918 outbound, just being a good netizen keeping noise off the public internet.
But my isp doesn't run their dhcp on rfc1918 space..
look in /var/db
You should see a dhclient.leases.igb1, where yours would end with what interface your using, mine is using igb1
Does it show your dhcp server as that 10.42.2.1 address?
If that is the case, then put a rule above your floating block rfc1918 rule that allows outbound to 67 on udp, to that specific IP if you want, but they could change their dhcp servers IP at some point.
edit: hmmm, if that was a typical renew the source port should be 68... but yours is some random high port???
-
@johnpoz said in Block rule for RFC 1918 traffic:
Does it show your dhcp server as that 10.42.2.1 address?
Yes, correct
This will correct rule?
-
@Antibiotic what is odd is that source port is not 68.. Now with a relay it is possible to not use 68 as the source, normally it does too.. But I believe on some switches/routers that do relay that is possible to change.
So it is curious why the source port is not 68???
edit:
Yeah that should allow the traffic before your block rfc1918. -
@johnpoz said in Block rule for RFC 1918 traffic:
But I believe on some switches/routers that do relay that is possible to change
Do you mean ISP router or switch in them office?
-
@Antibiotic yeah anything that does a relay and sends the traffic on to a dhcp server - this is normally done in large corp network where they have a central dhcp server with many scopes handling multiple segments.
But yours is logged locally so its not a relay, unless pfsense was relaying dhcp to that address as well?
I can't see what pfsense does on a renew vs a rebind, ie when it hits T1 of the dhcp timers it should send a unicast to the dhcp sever (which is what your seeing).. And the source port should be 68 from its IP.
But can't really find a way to force that early, and the lease from my isp is long, I just did a release/renew and the T1 timer isn't until the 11th.. But this is actually a full release and the "renew" if you will is then broadcast from 0.0.0.0 vs unicast to the dhcp server..
But notice the answer... Came from a rfc1918 address.
But my lease still shows the IP of dhcp server as public.. But my rfc1918 rule wouldn't block that traffic because it was to broadcast, not a rfc1918 address.
I will have to setup a sniff running to try and catch the renew at the T1 time in the lease
renew 1 2024/11/11 23:58:41;
-
@johnpoz Should option "Relinquish Lease" to bet set ON in this case?
-
@Antibiotic no like I said that would do a full rebind, ie send traffic to broadcast and from 0.0.0.0 which your block rfc1918 wouldn't block anyway..
You kind of have to wait to see when you do a normal renew where its sourced from your ip and unicast to the dhcp server IP..
Your not seeing those logs currently are you?
-
@johnpoz said in Block rule for RFC 1918 traffic:
Your not seeing those logs currently are you?
Now this warning disappeared, actually.
-
@Antibiotic I am assuming you got a new lease once you put the rule in to allow the traffic.
As dhcp lease gets closer and closer to expire - the dhcp client will frantically try and renew faster and faster.. I would have to reread the rfc.. I thought at some point, when T2 is hit it would send out a renew to broadcast hoping any dhcp server would renew its lease. But some clients don't always follow the rfc to the letter, etc. And its been quite some time since I read that rfc ;)
But when the lease does actually expire, the client would send out a new discover which would be to broadcast.
Generally speaking a dhcp client when it hits 50% of its lease, it would renew - this should be a unicast sent to the dhcp server IP it got the lease from to port 67, from its IP with source port of 68.. If it does not get a renewal - it will try again, and then again and then again - near the end it will be asking like crazy hey can I get a renewal please.. Now what I am a bit fuzzy on, is if at some point it sends out a renew to broadcast.. And this could be dependent on the actual client as well.
But I am pretty sure the source port should be 68 in all of these instances.. your log was not 68, but some random high port which is odd.. I thought that could only really happen when relay was in play. But maybe pfsense on renewal sends from some random high port and not 68.. I have never really looked into it - because well never had any sort of problems with pfsense getting a renewal, etc.
But now I am curious - so I will be doing a sniff when my lease is about to renew in a couple of days, to see what it actually does. I am currently trying to catch a client renewing.. But my clients don't seem to want to renew currently ;) I have a lot of iot devices so at some point will see a renewal - but I do run really long lease times so it could take a bit. This should show the client IP from source port 68 to pfsense IP destination port 67
-
@johnpoz Please, write your future adventures here)))
-
@Antibiotic so caught a bunch of devices renewing their leases.. Notice the source port when the client sends the request is 68..
So yeah its odd why your log was some high port for the source of the traffic... But have to see what happens when pfsense does its renewal
edit: I have to possible reasons why the log might show high port vs 68...
1 - something different in the dhcp client on pfsense that is not using the standard 68.. This seems really weird if the case.
2 - The actual source of the request is localhost 127.0.0.1 and is being natted to your public public IP which would be some random high port.
These are 2 theories that could explain why your log wasn't showing the typical 68 source port.. You notice in my package capture when it did discover that source was 68, but that was from 0.0.0.0 to broadcast, and not a unicast request.
So yeah I am curious what my sniff will capture in a couple of days.
-
@johnpoz So, the same as my
-
@Antibiotic oh the dhcp server being rfc1918, yeah in the sniff it was rfc1918.. But rule would not take effect with discover since its to broadcast 255.255.255.255 not an rfc1918 address.
But notice in my lease it shows public IP, while yours showed the rfc1918 address. So mine could of been just the loopback address the actual dhcp server sent the answer from.
-
@johnpoz said in Block rule for RFC 1918 traffic:
while yours showed the rfc1918 address
So, is it possible that my ISP use this for DCHP lease?Oh same block but now on 10.42.2.2
