Block rule for RFC 1918 traffic
-
@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..
