Mipam <mipam@ibb.net> writes:

> It's solved now, i just turned on the logging on the blocks with ipf
> and saw that the dhcp machine tried to send a packet from port 67 udp
> to my machine port 68 udp.
> I allowed that for these specific machines to happen with keep state
> (dont know if keep state if such a good idea, it only seems to happen once
> so perhaps it keep state of that until it expires hmmm anyway).

I'm surprised that "keep state" is working with dhcp packets. keep
state only allows packets with exactly mirrored ports and IP
addresses, which isn't the case for dhcp. For example, if this packet:

        src ip: 10.0.0.1 port: 1000
        dst ip: 10.0.0.2 port: 2000

matches a keep state rule, a new (temporary) rule will be created
which matches both the original packet, as well as this packet:

        src ip: 10.0.0.2 port: 2000
        dst ip: 10.0.0.1 port: 1000

In the case of dhcp, however, you usually have something like this (in
this example, the dhcp server's IP address is 10.0.0.1):

  request packet:

        src ip: 0.0.0.0         port: 68
        dst ip: 255.255.255.255 port: 67

  response packet:

        src ip: 10.0.0.1        port: 67
        dst ip: 255.255.255.255 port: 68

But if the request packet matched a "keep state", a rule would be
created that would match:

        src ip: 255.255.255.255 port: 67
        dst ip: 0.0.0.0         port: 68
        
Not quite the same ;-) There are also cases where the client thinks it
knows its IP address, so the src ip of the request is something other
than 0.0.0.0 (but the response packet still may not be an exact mirror
of the request). In my experience, the best way to make sure dhcp
always works through ipf is just to allow everything in both
directions explicitly, with no keep state.