DHCP requests across firewall
-
Here's literally everything:
There is only one client on Net B, I have isolated it for testing purposes. It is connected directly to the Net B interface and has DHCP on. It is running Windows 7.
The firewall. Three interfaces, net A and net B, and then WAN. DHCP relay is pushing from net B to 10.1.1.100. Firewall rule added to both net A and B is attached as a .png. The rule has been moved to the top of all rules and is right below block bogon networks.
The net A interface is connected to an unmanaged switch, one port on which goes to the DHCP windows server (Also running AD DS and DNS). It has a static IP. It has a proper scope (10.1.2.10-10.1.2.30).
I can't think of anything else that could be interfering.
 -
Which interface is this rule on? Also, you completely missed the part about firewall logs.
-
Where are you putting the rules – this took all of 2 seconds to setup.
You really shouldn't need any rules.. Pfsense will forward the traffic to your dhcp server, then it will send that back to the requesting client
Here is sniff on the server side, my dhcp server is 192.168.1.8, fired up a 2k12r2 vm and installed the dhcp role. Client is on my dmz segment of 192.168.3.0
Notice on the server side all traffic is from pfsense IP 192.168.1.253 and to the client side its all from pfsense IP address in that segment
-
I understand how simple this is, which is why I'm so confuzzled. Where are you seeing those logs?
-
those are not logs those are sniffs I did on pfsense.. Diag, package capture - then open them up in wireshark.
Think of the relay as man in the middle or proxy..
So you client sends out broadcast (discover) hey any dhcp servers out there I would like a lease. All the dchp servers that hear they say yes I have a lease would you like it (offer).. Client says yeah or nay - if yeah it sends a request. Server then says sure here you go ack.
With a relay, pfsense sees the discover and sends it on to the dhcp server it listed in the relay. Having the client info in the discover - see attached.
All traffic is to or from the pfsense interfaces themselves - you really should not have to worry about any rules since pfsense can talk to anything on its segments and dhcp should be allowed by default when you enable relay on that interface, etc..
Why don't you sniff and see where your problem is.. Does pfsense see the discover and send it on? The dhcp server answer the discover with offer? And then pfsense sends this on to the client?
Are you seeing blocks in you pfsense fiewall logs? If so post those - this really is simple stuff.. And should be click click..
-
@johnpoz I looked at my firewall logs and it does appear the ports are being blocked. I can't screenshot right now, but it's: If Net B-Source 0.0.0.0:68-Dest. 255.255.255.255:67-Proto UDP
Act is block.Relay is activated and configured properly.
Also, I did a sniff on net B and it is taking 0.0.0.0:68 and pushing to 255.255.255.255:67
-
Yes… So, let me ask again:
Which interface is this rule on?
This needs to be on the interface that shows your blocked DHCP requests.
-
Also, I did a sniff on net B and it is taking 0.0.0.0:68 and pushing to 255.255.255.255:67
That would be the discover from the client.. you mean you see a packet from that source to that dest, yes that is a discover packet. You should then see that discover being directly sent to your dhcp server. Where are you seeing blocks? And why is it you could not take a screenshot? You can take screen shots from your phone - so I find it hard to image what your viewing it with that you could not take a screenshot. Shoot your phone has a camera right? ;)
There is hidden rule that allows dhcp traffic to pfsense..
Look in your /temp/rules.debug
allow access to DHCP server on LAN
pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000002641 label "allow access to DHCP server"
pass in quick on $LAN proto udp from any port = 68 to 192.168.1.253 port = 67 tracker 1000002642 label "allow access to DHCP server"
pass out quick on $LAN proto udp from 192.168.1.253 port = 67 to any port = 68 tracker 1000002643 label "allow access to DHCP server"
antispoof log for $WLAN tracker 1000003670allow access to DHCP server on WLAN
pass in quick on $WLAN proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000003691 label "allow access to DHCP server"
pass in quick on $WLAN proto udp from any port = 68 to 192.168.2.253 port = 67 tracker 1000003692 label "allow access to DHCP server"
pass out quick on $WLAN proto udp from 192.168.2.253 port = 67 to any port = 68 tracker 1000003693 label "allow access to DHCP server"
antispoof log for $DMZ tracker 1000004720allow access to DHCP server on DMZ
pass in quick on $DMZ proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000004741 label "allow access to DHCP server"
pass in quick on $DMZ proto udp from any port = 68 to 192.168.3.253 port = 67 tracker 1000004742 label "allow access to DHCP server"
pass out quick on $DMZ proto udp from 192.168.3.253 port = 67 to any port = 68 tracker 1000004743 label "allow access to DHCP server"
antispoof log for $WLANGUEST tracker 1000006820allow access to DHCP server on WLANGUEST
pass in quick on $WLANGUEST proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000006841 label "allow access to DHCP server"
pass in quick on $WLANGUEST proto udp from any port = 68 to 192.168.4.253 port = 67 tracker 1000006842 label "allow access to DHCP server"
pass out quick on $WLANGUEST proto udp from 192.168.4.253 port = 67 to any port = 68 tracker 1000006843 label "allow access to DHCP server"If I turn them all off and just have relay on there is no rules that allow.. So yeah that could be your issue. So lets see your rules on netb. You would need a rule that allows the broadcast to 67 which is the discover
So not sure the lack of the hidden rules gotten over looked since they put them in when you enable dhcp or a feature ;) I would think if you enable that on interface X then they should put in the hidden rules to allow for it since they do that when you enable dhcp server.
-
So not sure the lack of the hidden rules gotten over looked since they put them in when you enable dhcp or a feature ;)
This was the same story with DHCPv6 relay… Stuff that's not so often used gets overlooked.
-
Firewall rule added to both net A and B is attached as a .png. The rule has been moved to the top of all rules and is right below block bogon networks.
Also, I had DHCP running on the interface in question, but then I change it's IP before activating the relay. Would that be the problem? Would I need to activate DHCP with the new IP?
 -
Awesome screenshot. We STILL do NOT know WHICH interface you did put that on. Grrrrrrrrrrrrrrrr. Enough time wasted here. Good luck. >:( >:( >:(
Would I need to activate DHCP with the new IP?
What? Not really sure what you mean by "activate"?
-
I think I've said which interfaces I put that rule on three times. If you look at the quote and the previous commments, Net A and B.
I don't think I'd be putting it on WAN. Since WAN has nothing to do with this.
Sorry, I mean turn on pfSense's DHCP server to get the rules readded with the new IP.
-
I assume it'd be way too much work to post the logs of what exactly you get blocked where, right? Especially since you have not been able to get an absolutely trivial thing working for multiple days and since we've been praying for information repeatedly. So far we got one screenshot without context and some generic "oh noes, it won't work" and "it's blocked" moaning.
Good luck.
Sorry, I mean turn on pfSense's DHCP server to get the rules readded with the new IP.
Why the heck would you be doing that when you already have another DHCP server on your network!? (Plus it's impossible to have both the relay and DHCP server enabled at the same time.) Plus, there are no rules there for the relay. I already linked the bug.
-
I'm not in a position where I'm able to be taking screenshots and cropping them left and right. If you would simply read the comments I've posted, then you wouldn't need to pray.
Also, I don't think I've been moaning. I believe I've been more than compliant with your requests, even though I'm in a high stress environment.
-
No those rules go away as soon as you disable dhcp server and turn on the relay.
I don't think the any rule includes broadcast maybe but that would seem very strange?? If your still seeing it blocked in your firewall. Could you please just post ALL your rules for netb WTF could you be hiding.. Here are mine on my dmz.. For all I know you have something specifically blocking right above that.. Without a full picture its very difficult to help you. In your firewall log if you click the red X it will tell you what rule blocked, etc..
As to posting your relay settings posting - please post that as well. It would not be the first time user said X when it was really Y.. Pics or it didn't happen if you will ;)
-
I'm not in a position where I'm able to be taking screenshots and cropping them left and right.
So take more comfortable position. Or get some working tools. Or hire a full time screenshotter if too much work for you. ROFL. :o ::)
-
As to cropping them? Huh?? what OS are you on? Windows 7 and above comes with free snipping tool that allows for simple cropping.. Same with linux has multiple screentaking tools. I use faststone capture – best little piece of software ever ;) Shoot even if took a screenshot with my phone allows for cropping.. Clearly your shot of your 1 freaking rule was cropped!!
Again without info its impossible to help you!
-
There's NetB.
As for the relay, it's configured correctly. You've said how to do it 5 times.
-
And there you go - why and the F would you be blocking bogon on your own segment?
0.0.0.0/8 is listed in bogon.. What is the source of the broadcasts in dhcp discover. Clicking the little X in the firewall log wold of told you it was blocked by bogon
-
And there you go - why and the F would you be blocking bogon on your own segment?
Could have been worse. He might have blocked the RFC1918 as well. Nice waste of time, this… ::)
