Block rule for RFC 1918 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
-
@Antibiotic yeah as I said from the beginning its very possible.. You saw it your lease file right..
Rfc1918 doesn't route across the public internet - but your isp network isn't the public internet, its a network your directly attached to.. And you point your default gateway to a device in their network, so yes its possible to talk to rfc1918 space in their network.
-
@johnpoz Now another traffic:
I'm using OpenVPN as client on pfSense with UDP protocol, could be this information from VPN provider?
-
@Antibiotic look in your state table if client on your network is creating that traffic.. I take it that 92.x address is your pfsense wan IP..
Could be something inside your network trying to go there..
Example, if I try and go to https://10.0.0.1 my outbound rule blocks it.
If it was related to your vpn why would pfsense send it out your wan vs out your vpn.. Could just be a client on your network, my work laptop when the work vpn on it disconnects I see it trying to talk to work stuff on rfc1918 because yeah their are things in the work network its wanting to talk to - but the vpn is not connected.
From those vpn networks unless they have /8 for a tunnel mask, or there is something on remote network via those tunnels on 10.0 your wanting to talk to and you don't have routing setup right for what is on the other end of your vpn tunnels.
ugggh - I forgot to setup sniff for that dhcp traffic..
