LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   how does the dhcp offer get through this iptables configuration? (http://www.linuxquestions.org/questions/linux-networking-3/how-does-the-dhcp-offer-get-through-this-iptables-configuration-884684/)

doru 06-05-2011 12:20 PM

how does the dhcp offer get through this iptables configuration?
 
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 (Post 4377053)
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 (Post 4377058)
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 (Post 4377060)
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 (Post 4377079)
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 (Post 4377110)
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.


All times are GMT -5. The time now is 05:05 AM.