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