I did some pretty extensive research on the dhcp protocols and I never found were the DISCOVERY was an Ethernet Broadcast so I assumed there might have been a mistake. :) All the documentary I read ,including the manual to the actual protocol, said it was an IP/UDP broadcast on port 67/68. Even if it was the fact that it was an Ethernet broadcast it should have worked on the bridge without the option blocknonip as the bridge is really just a hub with filtering capabilities. I don't know why Darren said I would need a relay. During my research, I saw a few statements that led me to believe that a relay was not even required in corporate networks where you have many segments and one dhcp server. I guess they can tell the client to use a particular server ip address and therefore it does not have to use udp broadcast to find one. Anyways the following in my research allowed me to fix it: http://www.isc.org/products/DHCP/dhcpv3-README.html#config
USING THE DHCP DISTRIBUTION FIREWALL RULES If you are running the DHCP server or client on a computer that's also acting as a firewall, you must be sure to allow DHCP packets through the firewall. In particular, your firewall rules _must_ allow packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68 to UDP port 67 through. They must also allow packets from your local firewall's IP address and UDP port 67 through to any address your DHCP server might serve on UDP port 68. Finally, packets from relay agents on port 67 to the DHCP server on port 67, and vice versa, must be permitted. We have noticed that on some systems where we are using a packet filter, if you set up a firewall that blocks UDP port 67 and 68 entirely, packets sent through the packet filter will not be blocked. However, unicast packets will be blocked. This can result in strange behaviour, particularly on DHCP clients, where the initial packet exchange is broadcast, but renewals are unicast - the client will appear to be unable to renew until it starts broadcasting its renewals, and then suddenly it'll work. The fix is to fix the firewall rules as described above. Isp---(sis1)-bdrg-(sis0)---(xl1)-ipf/nat-(xl2)---LAN I simply changed my rules on the bridge as follows: #Allow DHCP Discoveries & Renews# #comming from the internet, this allows my isp's server to renew the lease# pass out quick on sis0 proto udp from 12.242.18.34/32 port = 67 to any port = 68 #comming in from the lan side which is the ipf/nat rtr# pass in quick on sis0 proto udp from 0.0.0.0 to 255.255.255.255 port = 67 keep state On my bridge only the sis0 interface is filtered this is why I have bi-directional on the sis0 interface as sis1 is unfiltered because this is my snort interface; if I want to see all the attacks at my network I need to leave this open. Of course on the PNAT box I have to allow for the same protocols on the xl1 interface. I just love it; I can filter data before it even gets to my IP, undetectably, and then filter again with even more granular rules. Anyways maybe this will help someone. Would be good to put into the faq: -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of James A. Robbins Sent: Wednesday, August 14, 2002 11:05 AM To: [EMAIL PROTECTED]; taproot420 Cc: [EMAIL PROTECTED] Subject: Re: cant get dhcp to pass through bridge. ! please help ----- Original Message ----- From: "Crist J. Clark" <[EMAIL PROTECTED]> To: "taproot420" <[EMAIL PROTECTED]> Cc: "'James A. Robbins'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, August 14, 2002 1:19 AM Subject: Re: cant get dhcp to pass through bridge. ! please help > On Mon, Aug 12, 2002 at 03:29:00PM -0500, taproot420 wrote: > > Already present on the bridge. > > > > # cat bridgename.bridge0 > > add sis0 add sis1 blocknonip sis0 blocknonip sis1 up > > > > I thought dhcp used ip to handshake. > > It does. It uses UDP riding on IP. Ports 68 and 69 to be > exact. Nothing about DHCP is specific to Ethernet either. It's IP all > the way. My bad, you right. I just double checked another firewall that we set up to pass DHCP and found that we had to include rules to pass packets with a destination address of 255.255.255.255 in both directions to allow DHCP to work. The requests are sent to the ultimate broadcast address to try to contact any DHCP server within hearing range. I assume that 255.255.255.255 is blocked by a router up the line somewhere so that the entire Internet doesn't get these requests. -- James A. Robbins Network Engineer The Ohio State University Chemistry Department
