[SOLVED] how does the dhcp offer get through this iptables configuration?

doru · 06-05-2011, 12:20 PM

eth0 is configured through a dhcp server connected directly to it.
http://en.wikipedia.org/wiki/Dhcp#DHCP_offer is very clear: the answer of the server is a UDP to 255.255.255.255. Please tell me how can it pass through this iptables configuration, because it does.

Code:

iptables -nvL INPUT
(policy DROP)
 3281  201K ACCEPT     all  --  eth1   *       192.168.69.0/24      0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       192.168.69.1         0.0.0.0/0
    0     0 ACCEPT     all  --  lo     *       93.114.xx.xx         0.0.0.0/0
 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED
  108  5388 tcp_packets  tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0         
 2724  258K udp_packets  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0         
    1    56 icmp_packets  icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0        
   56  1568 DROP       all  --  eth0   *       0.0.0.0/0            224.0.0.0/8

iptables -nvL udp_packets
    0     0 DROP       udp  --  eth0   *       0.0.0.0/0            93.114.xx.xx        udp dpts:135:139
   18  5923 DROP       udp  --  eth0   *       0.0.0.0/0            255.255.255.255     udp dpts:67:68

Maybe iptables is started after eth0 is configured, in spite of my pre-up iptables-restore [...] in eth0 configuration?

smoker · 06-05-2011, 12:26 PM

Because the firewall is designed to block / direct unsolicited packets from outside. You said yourself that the DHCP server is sending an answer, so your system must have requested that answer, and so the firewall does not block it.

doru · 06-05-2011, 12:31 PM

Quote:

Originally Posted by smoker

Because the firewall is designed to block / direct unsolicited packets from outside. You said yourself that the DHCP server is sending an answer, so your system must have requested that answer, and so the firewall does not block it.

If you refer to this line:

Code:

 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED

then you should explain why is a package accepted even though it has a destination of 255.255.255.255, when the required destination is 93.114.xx.xx.

acid_kewpie · 06-05-2011, 12:32 PM

Have you actually looked at the response? Just checking mine, it's actually addressed to the address in the offer itself.

Code:

18:30:51.778759 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:26:c7:34:f5:76, length 300, xid 0x91295062, Flags [none]
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Requested-IP Option 50, length 4: 192.168.0.6
	    Hostname Option 12, length 8: "thinkpad"
	    Parameter-Request Option 55, length 17: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
	      NTP
18:30:52.785070 IP (tos 0x0, ttl 128, id 57005, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.1.bootps > 192.168.0.6.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x91295062, Flags [none]
	  Your-IP 192.168.0.6
	  Server-IP 192.168.0.1
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Time-Zone Option 2, length 4: 0
	    Default-Gateway Option 3, length 4: 192.168.0.1
	    TTL Option 23, length 1: 64
	    Lease-Time Option 51, length 4: 3600
	    Server-ID Option 54, length 4: 192.168.0.1
	    Domain-Name-Server Option 6, length 8: 194.168.4.100,194.168.8.100

Mind you that is requesting that IP from an existing lease. How many combinations have you actually tried?

acid_kewpie · 06-05-2011, 12:34 PM

Quote:

Originally Posted by doru

If you refer to this line:

Code:

 1253 93310 ACCEPT     all  --  *      *       0.0.0.0/0            93.114.xx.xx        state RELATED,ESTABLISHED

then you should explain why is a package accepted even though it has a destination of 255.255.255.255, when the required destination is 93.114.xx.xx.

Yeah that was confusing me a little, however the starting point for the request is that there is no address on the interface, and in those circumstances I'm not clear how the rules are supposed to be interpreted anyway.

doru · 06-05-2011, 12:55 PM

Quote:

Originally Posted by acid_kewpie

Have you actually looked at the response? Just checking mine, it's actually addressed to the address in the offer itself.

Code:

18:30:51.778759 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:26:c7:34:f5:76, length 300, xid 0x91295062, Flags [none]
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Requested-IP Option 50, length 4: 192.168.0.6
	    Hostname Option 12, length 8: "thinkpad"
	    Parameter-Request Option 55, length 17: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
	      NTP
18:30:52.785070 IP (tos 0x0, ttl 128, id 57005, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.1.bootps > 192.168.0.6.bootpc: BOOTP/DHCP, Reply, length 300, xid 0x91295062, Flags [none]
	  Your-IP 192.168.0.6
	  Server-IP 192.168.0.1
	  Client-Ethernet-Address 00:26:c7:34:f5:76
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Time-Zone Option 2, length 4: 0
	    Default-Gateway Option 3, length 4: 192.168.0.1
	    TTL Option 23, length 1: 64
	    Lease-Time Option 51, length 4: 3600
	    Server-ID Option 54, length 4: 192.168.0.1
	    Domain-Name-Server Option 6, length 8: 194.168.4.100,194.168.8.100

Mind you that is requesting that IP from an existing lease. How many combinations have you actually tried?

Please tell me how did you obtain that record. I start tcpdump and then I do dhclient eth0 in another terminal, but I can't see that.

What combinations are you refering to?

acid_kewpie · 06-05-2011, 12:58 PM

well I mean how extensive is your testing? I don't know what address i'd expect if it didn't have an IP to request already etc. I'm only testing this against my noddy cable router, not isc dhcpd etc...

I just ran "tcpdump -vn -i wlan0"

doru · 06-05-2011, 01:27 PM

Quote:

Originally Posted by acid_kewpie

well I mean how extensive is your testing? I don't know what address i'd expect if it didn't have an IP to request already etc. I'm only testing this against my noddy cable router, not isc dhcpd etc...

I just ran "tcpdump -vn -i wlan0"

Thank you for your answer. It is clear that dhcp does not follow Wikipedia's description. I did not try many combinations, I have the same address allocated every time through dhcp, and I am connected to a relatively large LAN which is flooding my tcpdump. This is what I got:

Code:

tcpdump -vvn | grep -i dhcp
21:16:47.401380 IP6 (hlim 1, next-header UDP (17) payload length: 99) fe80::c4a4:c1a2:596c:20d7.546 > ff02::1:2.547: dhcp6 solicit (xid=728da8 (elapsed time 6300) (client ID hwaddr/time type 1 time 357520540 6cf04957e2d8)[|dhcp6ext])
21:16:49.003227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:a1:b0:f0:xx:xx, length 300, xid 0x37453e6a, Flags [none] (0x0000)
21:16:49.004430 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328) 93.114.xx.1.67 > 93.114.xx.xx.68: BOOTP/DHCP, Reply, length 300, xid 0x37453e6a, Flags [none] (0x0000)

# The other terminal: 
dhclient3 eth0

There should have been four packets, two out and two in, but we both see only two (I am not sure that the first one is mine; plus, tcpdump only catches what it can.) So this should clarify it all: "And the chaos, who created the chaos? The programmers did." Thanks again.

acid_kewpie · 06-05-2011, 01:33 PM

Flicking around briefly I think you're interpreting things incorrectly. As the exchanges we're both seeing are renewals not initial requests, therefore it is a different scenario. The full handshake not appropriate as it already has the information it wants, and just needs to confirm it. So once the server confirms the requested details it doesn't need to hear back again as it's been asked to confirm, not asked for new information.

doru · 06-05-2011, 01:53 PM

Quote:

Originally Posted by acid_kewpie

Flicking around briefly I think you're interpreting things incorrectly. As the exchanges we're both seeing are renewals not initial requests, therefore it is a different scenario. The full handshake not appropriate as it already has the information it wants, and just needs to confirm it. So once the server confirms the requested details it doesn't need to hear back again as it's been asked to confirm, not asked for new information.

Right, it can be a completely different standard for renewal.

I did this:

Code:

ifdown eth0
ifconfig eth0 up
#now the other terminal
tcpdump -vvn | grep -i dhcp
#now back to the first terminal
dhclient3 eth0
#and I got this: 
tcpdump -vvn | grep -i dhcp
tcpdump: WARNING: eth0: no IPv4 address assigned
21:46:58.003515 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:a1:b0:f0:xx:xx, length 300, xid 0x71534c7f, Flags [none] (0x0000)
21:46:58.004386 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto UDP (17), length 328) 93.114.xx.1.67 > 93.114.xx.xx.68: BOOTP/DHCP, Reply, length 300, xid 0x71534c7f, Flags [none] (0x0000)

It is pretty clear that it does not follow the standard. It could not pass through iptables if it did.

Or maybe they use a different standard, for the case of one single dhcp server in the lan.

Thanks for this.