"Deny unknown clients" enabled, getting an IP anyway…
-
Hi again!
Have here a box with 2.2.6 32bit full-install (no vga). Setup WAN (fiber modem), LAN and OPT1, both DHCP enabled. For the sake of completeness: The client has no wireless card, all RJ45-cable-bound…
I connected a computer (Dell notebook with opensuse 12.3 32bit) to OPT1, DHCP is on (config see pic no. 1), "Deny unknown clients is ENABLED (tried it with "Enable Static ARP entries" both checked and unchecked, makes no difference, by the way).
Was surprised to get an IP and could start networking :-O
The DHCP protocol is attached (pic no. 2).
Rebooted, tried again, same result.
Changed the HDD to an installation of Win7 pro 32 bit, same Dell notebook. Same trick works there, just the protocol looks a little different (pic no. 3).
What did I get wrong with this "Deny unknown clients" feature? Thought it keep unknown clients out of my network, first hand? Not?
Kind regards
chemlud
 -
Hi,
Interface re0 is OP1 ?
What are all these errors that are listed in your dhcp log ? I have none of that. Something is going very wrong …..
I just activated "Deny unknown clients" and removed one of my 'fixed leases' from the list.
This PC couldn't get a IP anymore from pfSense ....01-11-2016 09:53:47 Local7.Info 192.168.1.1 Jan 11 09:54:01 dhcpd: DHCPREQUEST for 192.168.1.7 from b8:ac:6f:47:2d:b2 via fxp0: unknown lease 192.168.1.7.
01-11-2016 09:53:38 Local7.Info 192.168.1.1 Jan 11 09:53:53 dhcpd: DHCPREQUEST for 192.168.1.7 from b8:ac:6f:47:2d:b2 via fxp0: unknown lease 192.168.1.7.
01-11-2016 09:53:35 Local7.Info 192.168.1.1 Jan 11 09:53:50 dhcpd: DHCPREQUEST for 192.168.1.7 from b8:ac:6f:47:2d:b2 via fxp0: unknown lease 192.168.1.7.
01-11-2016 09:53:19 Local7.Info 192.168.1.1 Jan 11 09:53:34 dhcpd: DHCPREQUEST for 192.168.1.7 from b8:ac:6f:47:2d:b2 via fxp0: unknown lease 192.168.1.7.
01-11-2016 09:53:11 Local7.Info 192.168.1.1 Jan 11 09:53:26 dhcpd: DHCPREQUEST for 192.168.1.7 from b8:ac:6f:47:2d:b2 via fxp0: unknown lease 192.168.1.7.192.168.1.1 = LAN pfSEnse DHCP server
192.168.1.7 = The PC (Windows)
fxp0 = The LAN interface on which I activated the "Deny unknown clients" option ...As soon as I removed the "Deny unknown clients" option (the DHCP server restarted), the PC got an IP again ....
-
Hi!
re0 is OPT1, yes.
Errors? No idea! I set up DHCP at pfSense, connected some small dumb switches, plugged in the RJ45 cables, clients set to DHCP, that's is. What can go wrong with DHCP? I have no idea!
Regards
chemlud
-
"connected some small dumb switches"
How do you have them connected - do you have both lan and opt1 connected to the same dumb switch?
-
Nope! The very basics of networking I have allready understood. ;-)
The IP the client obtained (10.0.2.2) is from the OPT1 network (one of the two IPs to be delivered by DHCP to clients without "Static mappings", if "Deny unknown clients" is not enabled).
The LAN is 10.0.0.0/26, btw…
-
Ok, just to be sure I don't miss anything, I rebooted the box tried again with the Win 7 HDD, boot, get same IP.
But now there is an "unexpected ICMP Echo Reply" from my Gateway at my ISP (!) in the DHCP log (see below).
I don't get this, really… :-\
 -
Its time that you detail these interface and dhcp settings.
Btw : why a 10.0.0.0/26 and the declare a lease range that … well : complicated.
A gateway issue (one is set that shouldn't) ?
-
What do you wanna know?
WAN: set to DHCP, a Cisco fiber router in modem mode attached. Set as the only gateway.
LAN: DHCP 10.0.0.0/26, clients with static mapping, "Deny unknown" enabled, as on OPT1
OPT1: DHCP config see above, anything missing?
The lease range is for "learning" new clients for the respective network (once or twice a year), I disable "Deny unknown", an IP is issued, I pick the MAC and make a static mapping for this MAC, afterwards enable "Deny unknown". Mission accomplished.
Is that not a valid use of this function? What should I change in the DHCP setup? :-)
I rebooted the client again after obtaining a new IP from my ISP, same result in protocol for DHCP:
dhcpd: unexpected ICMP Echo Reply from 8xx.2xx.xxx.xxx (IP of ISP Gateway)
wuuuahh!
-
Update:
For the LAN interface (!!!) I found in the DHCP setup the following option checked
"Enable registration of DHCP client names in DNS"
but no server or credentials added. I never checked this, I swear!
Unchecked, reboot, the ICMP message from my ISP gateway is gone now, but the client still gets this IP on OPT1 (10.0.2.2), but apparently it's not actively OFFERED by pfSense, but the client ACTIVELY REQUESTS this IP. As if the clients interface config was stored somewhere (BIOS? network adapter? Why should it otherwise survive a switch of the harddisk to a totally different OS?) and recovered after reboot. NIGHTMARE!
 -
WAN: set to DHCP, a Cisco fiber router in modem mode attached. Set as the only gateway.
Can you print-copie these settings ? What do you mean by "Set as the only gateway" ?
LAN: DHCP 10.0.0.0/26, clients with static mapping, "Deny unknown" enabled, as on OPT1
OPT1: DHCP config see above, anything missing?
To easy.
I'd like to see something like (my scenario):
LAN = 192.168.1.1 / 24 - DHCP range lease 192.168.1.30 -> 192.168.1.254 (some static leases between 192.168.1.2 and 192.168.1.29)
OPT1 = 192.168.2.1 / 24 - DHCP range lease 192.168.2.10 -> 192.168.2.254 -
WAN config: see attached :-)
Under "System" -> "Routing" this WAN is the only gateway.
LAN: 10.0.0.0/26 DHCP lease range: 10.0.0.10 to 10.0.0.11 (statics starting from 10.0.0.12 to 10.0.0.40)
OPT1: 10.0.2.0/28 DHCP lease range: 10.0.2.2 to 10.0.2.3 (static leases from 10.0.2.6 to 10.0.2.14)
My DHCP setup is the same as yours, only that my static mappings are at the UPPER end of the possible IP range, yours at the lower end…
Why should that make any difference? (can't change that anyways, would take days, with all configs, firewall rules , links on desktops etc. pp.)
How can I erase the IP-config of my computer, so that it doesn't actively request this 10.0.2.2 when booting (btw getting the IP lease long before login at the OS level)?
-
Next try:
Client shutdown. Added a pcmcia network interface and rebooted to Win 7 (delete temporary lease for 10.0.2.2 at pfSense in advance). Connected this new interface via RJ45 to the OPT1.
Same result, get the 10.0.2.2 IP and even worse: The ICMP from my ISP gateway is back!
I don't really understand what's going on here…
-
Ok, I have an idea what's going wrong here:
I recognized that both the fixed network interface of the client notebook AND the pcmcia network interface have a DHCP Static Mapping on the LAN (!!), but not on the OPT1 interface. But apparently pfSense does not differentiate between the interfaces w.r.t. static mappings and provides an IP even when the network interface is added to the WRONG network (here: OPT1 instead of LAN)
Proof of concept:
Took a pcmcia network adapter without static mapping, result: No IP was leased to the client(as to be expected), see pic 1
Next, take another client with a static mapping for LAN (but not OPT1) and connect it to OPT1, result: Get an IP lease (10.0.2.2, as usual) at the wrong interface, see pic 2.
Can anybody reproduce this?
-
yes this is know thing… The dhcp server shares this database.. So if it knows about a client, its know no matter what interface it connects on.
There have been many threads about this, would have dig up a few.
-
From security point of view this is eeehhhm sub-optimal. Not?
Did anybody file a bug for that?
-
Why would it be a security bug… The client is KNOWN to pfsense and the dhcp server.. Just because you move it to a different segment, still known - so why should it not get an IP? Or why would it not be able to talk to pfsense?
Look through the bug list, dok is the bug king he like knows them all off the top of his head ;)
here
https://redmine.pfsense.org/issues/4584 -
Hi John!
I highly appreciate your competent comments from the first day I joined this forum, but at certain points we will never share the same opinion.
Look, I have different networks at the same pfSense to strictly separate certain resources from each other. These networks have normally no way to communicate with each other BY DESIGN. I don'T want any clients from the dirty network to be active in the other network, to keep it simple.
So it definitely IS a security bug if a client not authorized for this network gets an IP and can browse arround .
But I guess you see this as "security by obscurity".
Let's see it the other way arround: Why has the GUI a static mapping tab for each DHCP server, as this suggests that you can manage access for each network SEPARATELY? Then scrap that and say to the user: "Only one tab here, as there is no way to limit access. Anybody having access to ANY network here has access to ALL networks."
That would be fair. But hard so sell for a "security appliance"….
-
I am just saying that your security appliance KNOWS about this client, the wording in the setting should be changed for sure. But its an issue with the wording, and the fact that the known clients is shared in one listing..
See the bug.. From 9 months ago..
There are many people that might say, hey I know this client - he can connect to any network he wants. Maybe he changes wifi networks, maybe he plugs into the conf room, and his desk with this laptop, etc.
The wording should reflect this issue that its a shared database for known clients, and that if it moves to network B, he would get an IP there if dhcp is on that network since he is known from network A static settings, etc.
I don't really see it as a security issue that the wording of static arp and deny "unknown" needs more clarification.
And to be honest not sure I would classify security as not giving a client dhcp.. Your firewall rules should prevent what you don't want from any client talking on the network.. MACs can be spoofed for sure.. Limiting communication based on mac is not really good security if you ask me.
-
…had a look now at the bug report, two things come to my mind:
1. Thanx to Phil that he gave me the chance to reproduce this and find the same things as he did ;-)
2. Typical pfSense: Nobody has taken the slightest notice of this bug report within 9 months... wuuuaaaa. All busy brushing up the GUI, which will not help to improve network security (but has to be done someday, I know)
Someday soon I will get Parkinsons from all the head shaking day in and day out...
-
Your more than welcome to jump in and fix it ;)
I would say the move to 2.3 and yes a new gui is a bit more involved than cosmetics..
