How to force pfsense DNS to be used
-
Is there anyway to force the pfsense DNS to be used when another DNS server appears on the same network?
Its not this setup as described here. https://doc.pfsense.org/index.php/Blocking_DNS_queries_to_external_resolvers
and the following link doesnt exist. https://doc.pfsense.org/index.php/Blocking_DNS_queries_to_internal_resolvers
Its just that if a certain device/code appears on the internal network everything seems to get routed this device totally bypassing pfsense so I wondered what magick they have which pfsense doesnt which is forcing all traffic through their device?
I've yet to see if anything is being injected into the windows devices to make this possible or if there is something in the network protocals/stack/device driver, but all windows network settings both in the gui interface and DOS ipconfig /all is showing the correct settings so this is like a Stingray device for mobile phones. https://en.wikipedia.org/wiki/Stingray_phone_tracker
TIA.
pfsense 2.2.3
-
https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense
-
If there is another DHCP server on your LAN, then that can give out some local DNS server. Or people could manually point their devices to some local DNS server. Nothing you can do about that in pfSense because pfSense does not even see that traffic.
If those rogue DHCP/DNS servers try to go upstream to resolve some DNS then sure, you can block that or redirect it to pfSense DNS. But if a rogue DNS server on LAN is answering name requests itself with dodgy IP addresses that go to bad replicas of a site… then pfSense is not going to be able to stop the dodgy name resolution. (Of course you might have pfBlockerNG or your own rules that then block access to known dodgy IP addresses anyway).
Once you allow any guest device physically onto your network, then the owner of that device can turn on some DHCP server app, DNS server app... To be secure from that kind of thing while still allowing uncontrolled devices onto a LAN requires a bunch of layer2 isolation at switches, AP users,... so that the end-user device broadcasts do not go to all other end user devices - so that end-user devices effectively do not see each other. Or put every untrusted device in its own VLAN. Whatever system, it needs to provide layer2 isolation. -
If there is another DHCP server on your LAN, then that can give out some local DNS server. Or people could manually point their devices to some local DNS server. Nothing you can do about that in pfSense because pfSense does not even see that traffic.
If those rogue DHCP/DNS servers try to go upstream to resolve some DNS then sure, you can block that or redirect it to pfSense DNS. But if a rogue DNS server on LAN is answering name requests itself with dodgy IP addresses that go to bad replicas of a site… then pfSense is not going to be able to stop the dodgy name resolution. (Of course you might have pfBlockerNG or your own rules that then block access to known dodgy IP addresses anyway).
Once you allow any guest device physically onto your network, then the owner of that device can turn on some DHCP server app, DNS server app... To be secure from that kind of thing while still allowing uncontrolled devices onto a LAN requires a bunch of layer2 isolation at switches, AP users,... so that the end-user device broadcasts do not go to all other end user devices - so that end-user devices effectively do not see each other. Or put every untrusted device in its own VLAN. Whatever system, it needs to provide layer2 isolation.Yes, DHCP was on the network which could explain everything else, my network although not setup in a Vlan config, sometimes only has one device on its network, in this instance this was my public network, although I have lots of nics coming out of the pfsense device instead of using vlan because I can bare the CAT5/6 wires and monitor the electrical signals on individual networks in a bid to find anything being transmitted at the HW level which the bios may only act upon and not the OS (irrespective of what OS it is) that is running.
Re pfSense does not even see that traffic.
Wouldnt pfsense see that traffic if its between a device and pfsense, or would it be more accurate to say pfsense doesnt act upon seeing another DHCP on the network and thus flag up a warning at least? I havent tested the latter or seen anything in google results.@doktornotor, thanks I'll check it out.
-
You are looking at completely wrong place here. This is job for switches, not pfSense. (Also, IPv6 RA, ND etc.)
-
If you have multiple physical interfaces in pfSense then you can make each into a separate "LAN" and control them with firewall rules, and broadcasts (like getting DHCP) will be kept on the "LAN" interface concerned. Same if you connect a VLAN switch to pfSense and make lots of VLANs to isolate traffic.
If you have switches/hubs then traffic on those is outside the control of pfSense.
I don't know of anything on pfSense that goes looking for and reporting on the existence of rogue DHCP and/or DNS servers on a LAN. Maybe some package will do that, anyone? I guess something can just scan for ports 53/67/68.
-
If you have multiple physical interfaces in pfSense then you can make each into a separate "LAN" and control them with firewall rules, and broadcasts (like getting DHCP) will be kept on the "LAN" interface concerned. Same if you connect a VLAN switch to pfSense and make lots of VLANs to isolate traffic.
Thats what I do at the moment.
If you have switches/hubs then traffic on those is outside the control of pfSense.
Agreed
I don't know of anything on pfSense that goes looking for and reporting on the existence of rogue DHCP and/or DNS servers on a LAN. Maybe some package will do that, anyone? I guess something can just scan for ports 53/67/68.
I thought maybe snort could be used, but I dont know how snort would treat pfsense if a device is masquerading as some of the functionality provided by pfsense ie providing same interface ip address as pfsense/snort.
Think of it like an intelligent MITM attack not just for http(s) proxy but all network services/functionality provided by pfsense.
-
You are looking at completely wrong place here. This is job for switches, not pfSense. (Also, IPv6 RA, ND etc.)
The switch wouldnt help for IPv4 checking up on IPv6 though in case theres something I might have missed.
-
The switch wouldnt help for IPv4 checking up on IPv6 though in case theres something I might have missed.
Huh???
-
Hey guys would it be possible to block outbound wan for sources addresses not in pfSense DHCP leases?
If so then clients not under pfSense DHCP / DNS control would not be able to get out to the internet.
-
why don't you use Captive Portal for that ? It add another layer of security for your network.
https://forum.pfsense.org/index.php?topic=96320.msg536069#msg536069
and also in DHCP server you can mark:
Deny unknown clients
If this is checked, only the clients defined below will get DHCP leases from this server.
and
Enable Static ARP entries
Note: This option persists even if DHCP server is disabled. Only the machines listed below will be able to communicate with the firewall on this NIC. -
why don't you use Captive Portal for that ? It add another layer of security for your network.
Nice suggestion but take this further, when you dont have total oversight of the physical network ie cables or insides of a device with wifi capabilities namely a laptop or mobile plugged into synch with a computer especially in a bring your device to work scenario, there is still the situation of a device/code hijacking one or more machine(s) and off loading the network traffic via a wifi/mesh network of sorts.
In this instance only the absence of traffic at best will show up in pfsense if all traffic is rerouted via a dhcp/dns redirect, although if only off loading sensitive data you wouldnt even spot this potentially*, abit like a multi wan set up but on the device in question or would you?
- I can think of one situation which could theoretically show this up, but its not something pfsense could do and the OS'es could still potentially be the weakness.