DHCRELAY through IPTABLES Firewall

DHCRELAY through IPTABLES Firewall

[bigman]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

All,
    I am wondering if someone out there would be so kind as to help me figure out why I cannot get DHCRELAY to relay DHCP requests from one LAN segment to another LAN segment where a Windows 2000 DHCP server resides. I have verified that the requests are hitting the DHCRELAY on 67/UDP and then the DHCRELAY is trying to send back out on ETH2 (LAN2 Segment) to the DHCP Server on LAN1, but there is nothing after that. I have used Snort in sniffer mode and I can see UDP traffic on 68/UDP and 67/UDP on LAN2, but I never see any on LAN1. So my guess is that for some reason it is not routing through the firewall correctly. Any help would be greatly appreciated.


Firewall Config
RH 7.3
IPTables v1.2.5
ETH0 (Internet)
ETH1 (LAN1)
ETH2 (LAN2)

[-- Attachment #2: Type: text/html, Size: 1543 bytes --]

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Sunday 27 October 2002 4:33 am, bigman@monster-solutions.net wrote:

> All,
>     I am wondering if someone out there would be so kind as to help me
> figure out why I cannot get DHCRELAY to relay DHCP requests from one LAN
> segment to another LAN segment where a Windows 2000 DHCP server resides. I
> have verified that the requests are hitting the DHCRELAY on 67/UDP and then
> the DHCRELAY is trying to send back out on ETH2 (LAN2 Segment) to the DHCP
> Server on LAN1, but there is nothing after that. I have used Snort in
> sniffer mode and I can see UDP traffic on 68/UDP and 67/UDP on LAN2, but I
> never see any on LAN1. So my guess is that for some reason it is not
> routing through the firewall correctly. Any help would be greatly
> appreciated.

Tell us:

1. Your netfilter rules

2. Your network addresses for LAN1 and LAN2.

3. The routing table on the firewall.

4. Your dhcrelay command line.

Antony.

-- 

If at first you don't succeed, destroy all the evidence that you tried.

Re: DHCRELAY through IPTABLES Firewall

[bigman]

I am running DHCRELAY as below

dhcrelay -i eth2 192.168.1.70

192.168.1.70    DHCP Server (W2K)
LAN1 192.168.1.0
LAN2 192.168.2.0

Here is my routing tables
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth2
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
x.x.x.x (ISP Subnet)     *               255.255.252.0   U     0      0
0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         x.x.x.x (ISP Assigned IP) 0.0.0.0         UG    0      0
0 eth0

Here are my Netfilter settings

Chain INPUT (policy DROP 84 packets, 6522 bytes)
 pkts bytes target     prot opt in     out     source
destination
 2402  839K lan1-in    all  --  eth1   *       0.0.0.0/0
0.0.0.0/0
 4468  730K ext-int-in  all  --  eth0   *       0.0.0.0/0
0.0.0.0/0
 9283 1160K lan2-in    all  --  eth2   *       0.0.0.0/0
0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
67892   42M lan1-lan2-fwd  all  --  eth1   eth2    0.0.0.0/0
0.0.0.0/0
54339 7531K lan2-lan1-fwd  all  --  eth2   eth1    0.0.0.0/0
0.0.0.0/0
 133K  153M ext-int-fwd  all  --  eth0   *       0.0.0.0/0
0.0.0.0/0
50699 4126K lan1-ext-fwd  all  --  eth1   *       0.0.0.0/0
0.0.0.0/0
35220   30M lan2-ext-fwd  all  --  eth2   *       0.0.0.0/0
0.0.0.0/0

Chain OUTPUT (policy DROP 172 packets, 19408 bytes)
 pkts bytes target     prot opt in     out     source
destination
  817  133K lan1-lan2  all  --  *      eth2    0.0.0.0/0
0.0.0.0/0
 2507  381K ACCEPT     all  --  *      eth0    0.0.0.0/0
0.0.0.0/0
 1351  337K ACCEPT     all  --  *      *       192.168.1.0/24
0.0.0.0/0
   60  3600 ACCEPT     tcp  --  *      *       0.0.0.0/0            x.x.x.x
(ISP Assigned IP)

Chain ext-int-fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
    133K  153M ACCEPT     all  --  eth0   *       0.0.0.0/0
0.0.0.0/0          state RELATED,ESTABLISHED
    0     0 DROP       all  --  eth0   *       0.0.0.0/0
0.0.0.0/0

Chain ext-int-in (1 references)
 pkts bytes target     prot opt in     out     source
destination
  2681  201K ACCEPT     all  --  eth0   *       0.0.0.0/0
0.0.0.0/0          state RELATED,ESTABLISHED
    1432  483K DROP       all  --  eth0   *       0.0.0.0/0
0.0.0.0/0

Chain lan1-ext-fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
50699 4126K ACCEPT     all  --  eth1   *       0.0.0.0/0
0.0.0.0/0          state NEW,RELATED,ESTABLISHED
    0     0 DROP       all  --  eth1   *       0.0.0.0/0
0.0.0.0/0

Chain lan1-in (1 references)
 pkts bytes target     prot opt in     out     source
destination
 2387  834K ACCEPT     all  --  eth1   *       192.168.1.0/24
0.0.0.0/0
   15  4920 DROP       all  --  eth1   *       0.0.0.0/0
0.0.0.0/0

Chain lan1-lan2 (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     udp  --  *      eth2    0.0.0.0/0
0.0.0.0/0          udp dpt:68
  595 99614 ACCEPT     all  --  *      eth2    0.0.0.0/0
192.168.2.0/24     state RELATED,ESTABLISHED
  222 33821 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0

Chain lan1-lan2-fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 ACCEPT     udp  --  *      eth2    0.0.0.0/0
192.168.2.105      udp dpt:6257
    0     0 ACCEPT     tcp  --  *      eth2    0.0.0.0/0
192.168.2.105      tcp dpt:6699
67463   42M ACCEPT     all  --  *      eth2    0.0.0.0/0
192.168.2.0/24     state RELATED,ESTABLISHED
  429  385K DROP       all  --  *      eth2    0.0.0.0/0
0.0.0.0/0

Chain lan2-ext-fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
35220   30M ACCEPT     all  --  eth2   *       0.0.0.0/0
0.0.0.0/0          state NEW,RELATED,ESTABLISHED
    0     0 DROP       all  --  eth2   *       0.0.0.0/0
0.0.0.0/0

Chain lan2-in (1 references)
 pkts bytes target     prot opt in     out     source
destination
  109 37146 ACCEPT     udp  --  eth2   *       0.0.0.0/0
0.0.0.0/0          udp dpt:67
 9173 1123K ACCEPT     all  --  eth2   *       192.168.2.0/24
0.0.0.0/0
    1   328 DROP       all  --  eth2   *       0.0.0.0/0
0.0.0.0/0

Chain lan2-lan1-fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
54339 7531K ACCEPT     all  --  eth2   eth1    0.0.0.0/0
0.0.0.0/0
    0     0 DROP       all  --  eth2   eth1    0.0.0.0/0
0.0.0.0/0

----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Sunday, October 27, 2002 3:09 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Sunday 27 October 2002 4:33 am, bigman@monster-solutions.net wrote:
>
> > All,
> >     I am wondering if someone out there would be so kind as to help me
> > figure out why I cannot get DHCRELAY to relay DHCP requests from one LAN
> > segment to another LAN segment where a Windows 2000 DHCP server resides.
I
> > have verified that the requests are hitting the DHCRELAY on 67/UDP and
then
> > the DHCRELAY is trying to send back out on ETH2 (LAN2 Segment) to the
DHCP
> > Server on LAN1, but there is nothing after that. I have used Snort in
> > sniffer mode and I can see UDP traffic on 68/UDP and 67/UDP on LAN2, but
I
> > never see any on LAN1. So my guess is that for some reason it is not
> > routing through the firewall correctly. Any help would be greatly
> > appreciated.
>
> Tell us:
>
> 1. Your netfilter rules
>
> 2. Your network addresses for LAN1 and LAN2.
>
> 3. The routing table on the firewall.
>
> 4. Your dhcrelay command line.
>
> Antony.
>
> --
>
> If at first you don't succeed, destroy all the evidence that you tried.
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Sunday 27 October 2002 8:58 am, bigman@monster-solutions.net wrote:

> I am running DHCRELAY as below
>
> dhcrelay -i eth2 192.168.1.70
>
> 192.168.1.70    DHCP Server (W2K)
> LAN1 192.168.1.0
> LAN2 192.168.2.0
>
> Here is my routing tables
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.2.0     *               255.255.255.0   U     0      0        0
> eth2 192.168.1.0     *               255.255.255.0   U     0      0       
> 0 eth1 x.x.x.x (ISP Subnet)     *               255.255.252.0   U     0    
>  0 0 eth0
> 127.0.0.0       *               255.0.0.0       U     0      0        0 lo
> default         x.x.x.x (ISP Assigned IP) 0.0.0.0         UG    0      0
> 0 eth0

Okay, that all looks sensible.   By the way, just thought I'd check - I 
assume you are running dhcrelay on the firewall machine ?

> Here are my Netfilter settings

Please post the iptables commands used to set up your ruleset.

You sent the ouput of iptables -L which doesn't show all the information we 
need: even the verbose version iptables -L -v is not as informative as the 
original commands.   Thanks,

Antony.

-- 

With thanks to God,
For all that's come before,
For all that will come after,
But most of all, for this bit right here now.

Re: DHCRELAY through IPTABLES Firewall

[bigman]

yeah the DHCRELAY is running on the firewall... below is how I am setting up
these rules.

iptables -N lan1-in
iptables -N ext-int-in
iptables -N lan2-in
iptables -N lan1-lan2-fwd
iptables -N lan2-lan1-fwd
iptables -N ext-int-fwd
iptables -N lan1-ext-fwd
iptables -N lan2-ext-fwd
iptables -N lan1-lan2

iptables -A INPUT -i eth1 -j lan1-in
iptables -A INPUT -i eth0 -j ext-int-in
iptables -A INPUT -i eth2 -j lan2-in

iptables -A FORWARD -i eth1 -o eth2 -j lan1-lan2-fwd
iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
iptables -A FORWARD -i eth0 -j ext-int-fwd
iptables -A FORWARD -i eth1 -j lan1-ext-fwd
iptables -A FORWARD -i eth2 -j lan2-ext-fwd

iptables -A OUTPUT -o eth2 -j lan1-lan2
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A OUTPUT -s 192.168.1.0/24 -j ACCEPT
iptables -A OUTPUT -p tcp -d x.x.x.x (ISP Assigned IP) -j ACCEPT

iptables -A ext-int-fwd -i eth0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
iptables -A ext-int-fwd -i eth0 -j DROP

iptables -A ext-int-in -i eth0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
iptables -A ext-int-in -i eth0 -j DROP

iptables -A lan1-ext-fwd -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j
ACCEPT
iptables -A lan1-ext-fwd -i eth1 -j DROP

iptables -A lan1-in -i eth1 -s 192.168.1.0/24 -j ACCEPT
iptables -A lan1-in -i eth1 -j DROP

iptables -A lan1-lan2 -p udp -o eth2 --dport 68 -j ACCEPT
iptables -A lan1-lan2 -o eth2 -d 192.168.2.0/24 -m state --state
RELATED,ESTABLISHED -j ACCEPT
iptables -A lan1-lan2 -j DROP

iptables -A lan1-lan2-fwd -o eth2 -d 192.168.2.0/24 -m state --state
RELATED,ESTABLISHED -j ACCEPT
iptables -A lan1-lan2-fwd -o eth2 -j DROP

iptables -A lan2-ext-fwd -i eth2 -m state --state NEW,RELATED,ESTABLISHED -j
ACCEPT
iptables -A lan2-ext-fwd -i eth2 -j DROP

iptables -A lan2-in -i eth2 -p udp --dport 67 -j ACCEPT
iptables -A lan2-in -i eth2 -s 192.168.2.0/24 -j ACCEPT
iptables -A lan2-in -i eth2 -j DROP

iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j ACCEPT
iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j DROP


iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward


----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 28, 2002 3:49 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Sunday 27 October 2002 8:58 am, bigman@monster-solutions.net wrote:
>
> > I am running DHCRELAY as below
> >
> > dhcrelay -i eth2 192.168.1.70
> >
> > 192.168.1.70    DHCP Server (W2K)
> > LAN1 192.168.1.0
> > LAN2 192.168.2.0
> >
> > Here is my routing tables
> > Destination     Gateway         Genmask         Flags Metric Ref    Use
> > Iface
> > 192.168.2.0     *               255.255.255.0   U     0      0        0
> > eth2 192.168.1.0     *               255.255.255.0   U     0      0
> > 0 eth1 x.x.x.x (ISP Subnet)     *               255.255.252.0   U     0
> >  0 0 eth0
> > 127.0.0.0       *               255.0.0.0       U     0      0        0
lo
> > default         x.x.x.x (ISP Assigned IP) 0.0.0.0         UG    0      0
> > 0 eth0
>
> Okay, that all looks sensible.   By the way, just thought I'd check - I
> assume you are running dhcrelay on the firewall machine ?
>
> > Here are my Netfilter settings
>
> Please post the iptables commands used to set up your ruleset.
>
> You sent the ouput of iptables -L which doesn't show all the information
we
> need: even the verbose version iptables -L -v is not as informative as the
> original commands.   Thanks,
>
> Antony.
>
> --
>
> With thanks to God,
> For all that's come before,
> For all that will come after,
> But most of all, for this bit right here now.
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Monday 28 October 2002 10:36 am, bigman@monster-solutions.net wrote:

> iptables -N lan1-in
> iptables -N ext-int-in
> iptables -N lan2-in
> iptables -N lan1-lan2-fwd
> iptables -N lan2-lan1-fwd
> iptables -N ext-int-fwd
> iptables -N lan1-ext-fwd
> iptables -N lan2-ext-fwd
> iptables -N lan1-lan2
>
> iptables -A INPUT -i eth1 -j lan1-in
> iptables -A INPUT -i eth0 -j ext-int-in
> iptables -A INPUT -i eth2 -j lan2-in
>
> iptables -A FORWARD -i eth1 -o eth2 -j lan1-lan2-fwd
> iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd

I don't like the look of that rule !

> iptables -A FORWARD -i eth0 -j ext-int-fwd
> iptables -A FORWARD -i eth1 -j lan1-ext-fwd
> iptables -A FORWARD -i eth2 -j lan2-ext-fwd
>
> iptables -A OUTPUT -o eth2 -j lan1-lan2

That seems like a strange name to use, but okay....

> iptables -A OUTPUT -o eth0 -j ACCEPT
> iptables -A OUTPUT -s 192.168.1.0/24 -j ACCEPT

Presumably that rule is the one which allows packets from the firewall to 
eth1, since you don't have another rule specifically for that ?

> iptables -A OUTPUT -p tcp -d x.x.x.x (ISP Assigned IP) -j ACCEPT

What is this destination address ?   (No, I don't mean tell me what it is 
numerically, I mean tell me which machine it belongs to and why you might be 
sending packets there from your firewall.)

> iptables -A ext-int-fwd -i eth0 -m state --state RELATED,ESTABLISHED -j
> ACCEPT
> iptables -A ext-int-fwd -i eth0 -j DROP

Why are you specifying -i eth0 in these rules ?   If a packet didn't come in 
through eth0 it wouldn't get as far as the ext-int-fwd chain....

> iptables -A ext-int-in -i eth0 -m state --state RELATED,ESTABLISHED -j
> ACCEPT
> iptables -A ext-int-in -i eth0 -j DROP

Same comment again - why bother to specify -i eth0 ?

In fact, I'd make the same comment for virtually all the following rules.   
You've already specified the input & output interfaces when selecting the 
packets to go to these chains, so why do it all again ?

> iptables -A lan1-ext-fwd -i eth1 -m state --state NEW,RELATED,ESTABLISHED
> -j ACCEPT
> iptables -A lan1-ext-fwd -i eth1 -j DROP
>
> iptables -A lan1-in -i eth1 -s 192.168.1.0/24 -j ACCEPT
> iptables -A lan1-in -i eth1 -j DROP
>
> iptables -A lan1-lan2 -p udp -o eth2 --dport 68 -j ACCEPT
> iptables -A lan1-lan2 -o eth2 -d 192.168.2.0/24 -m state --state
> RELATED,ESTABLISHED -j ACCEPT
> iptables -A lan1-lan2 -j DROP
>
> iptables -A lan1-lan2-fwd -o eth2 -d 192.168.2.0/24 -m state --state
> RELATED,ESTABLISHED -j ACCEPT
> iptables -A lan1-lan2-fwd -o eth2 -j DROP
>
> iptables -A lan2-ext-fwd -i eth2 -m state --state NEW,RELATED,ESTABLISHED
> -j ACCEPT
> iptables -A lan2-ext-fwd -i eth2 -j DROP
>
> iptables -A lan2-in -i eth2 -p udp --dport 67 -j ACCEPT
> iptables -A lan2-in -i eth2 -s 192.168.2.0/24 -j ACCEPT
> iptables -A lan2-in -i eth2 -j DROP
>
> iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j ACCEPT
> iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j DROP
>
> iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j MASQUERADE

Well, aside from my very first comment above, I can't see anything else which 
I'd expect to cause your problem, so the best thing might be to add a LOGging 
rule just before the DROP rule in each of your lan1-lan2-fwd and 
lan2-lan1-fwd chains so you can see if anything's being blocked...
 

Antony.

-- 

Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Nobel Prizewinner in Physics

Re: DHCRELAY through IPTABLES Firewall

[bigman]

my comments for each question are in BOLD... thanks for all of the help.


----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 28, 2002 5:54 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Monday 28 October 2002 10:36 am, bigman@monster-solutions.net wrote:
>
> > iptables -N lan1-in
> > iptables -N ext-int-in
> > iptables -N lan2-in
> > iptables -N lan1-lan2-fwd
> > iptables -N lan2-lan1-fwd
> > iptables -N ext-int-fwd
> > iptables -N lan1-ext-fwd
> > iptables -N lan2-ext-fwd
> > iptables -N lan1-lan2
> >
> > iptables -A INPUT -i eth1 -j lan1-in
> > iptables -A INPUT -i eth0 -j ext-int-in
> > iptables -A INPUT -i eth2 -j lan2-in
> >
> > iptables -A FORWARD -i eth1 -o eth2 -j lan1-lan2-fwd
> > iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
>
> I don't like the look of that rule !
IT SHOULD BE -O ETH1 AND NOT -O ETH2

>
> > iptables -A FORWARD -i eth0 -j ext-int-fwd
> > iptables -A FORWARD -i eth1 -j lan1-ext-fwd
> > iptables -A FORWARD -i eth2 -j lan2-ext-fwd
> >
> > iptables -A OUTPUT -o eth2 -j lan1-lan2
>
> That seems like a strange name to use, but okay....
>
> > iptables -A OUTPUT -o eth0 -j ACCEPT
> > iptables -A OUTPUT -s 192.168.1.0/24 -j ACCEPT
>
> Presumably that rule is the one which allows packets from the firewall to
> eth1, since you don't have another rule specifically for that ?
>
> > iptables -A OUTPUT -p tcp -d x.x.x.x (ISP Assigned IP) -j ACCEPT
>
> What is this destination address ?   (No, I don't mean tell me what it is
> numerically, I mean tell me which machine it belongs to and why you might
be
> sending packets there from your firewall.)

THIS IS JUST FOR MY OWN TESTING IS ALL.....
>
> > iptables -A ext-int-fwd -i eth0 -m state --state RELATED,ESTABLISHED -j
> > ACCEPT
> > iptables -A ext-int-fwd -i eth0 -j DROP
>
> Why are you specifying -i eth0 in these rules ?   If a packet didn't come
in
> through eth0 it wouldn't get as far as the ext-int-fwd chain....

VERY VALID POINT!!!

>
> > iptables -A ext-int-in -i eth0 -m state --state RELATED,ESTABLISHED -j
> > ACCEPT
> > iptables -A ext-int-in -i eth0 -j DROP
>
> Same comment again - why bother to specify -i eth0 ?
>
> In fact, I'd make the same comment for virtually all the following rules.
> You've already specified the input & output interfaces when selecting the
> packets to go to these chains, so why do it all again ?
>
> > iptables -A lan1-ext-fwd -i eth1 -m state --state
NEW,RELATED,ESTABLISHED
> > -j ACCEPT
> > iptables -A lan1-ext-fwd -i eth1 -j DROP
> >
> > iptables -A lan1-in -i eth1 -s 192.168.1.0/24 -j ACCEPT
> > iptables -A lan1-in -i eth1 -j DROP
> >
> > iptables -A lan1-lan2 -p udp -o eth2 --dport 68 -j ACCEPT
> > iptables -A lan1-lan2 -o eth2 -d 192.168.2.0/24 -m state --state
> > RELATED,ESTABLISHED -j ACCEPT
> > iptables -A lan1-lan2 -j DROP
> >
> > iptables -A lan1-lan2-fwd -o eth2 -d 192.168.2.0/24 -m state --state
> > RELATED,ESTABLISHED -j ACCEPT
> > iptables -A lan1-lan2-fwd -o eth2 -j DROP
> >
> > iptables -A lan2-ext-fwd -i eth2 -m state --state
NEW,RELATED,ESTABLISHED
> > -j ACCEPT
> > iptables -A lan2-ext-fwd -i eth2 -j DROP
> >
> > iptables -A lan2-in -i eth2 -p udp --dport 67 -j ACCEPT
> > iptables -A lan2-in -i eth2 -s 192.168.2.0/24 -j ACCEPT
> > iptables -A lan2-in -i eth2 -j DROP
> >
> > iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j ACCEPT
> > iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j DROP
> >
> > iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j MASQUERADE
>
> Well, aside from my very first comment above, I can't see anything else
which
> I'd expect to cause your problem, so the best thing might be to add a
LOGging
> rule just before the DROP rule in each of your lan1-lan2-fwd and
> lan2-lan1-fwd chains so you can see if anything's being blocked...

SO DHCRELAY WILL USE FORWARDING INSTEAD OF OUTPUT AND INPUT FOR IT TO WORK?


>
>
> Antony.
>
> --
>
> Anything that improbable is effectively impossible.
>
>  - Murray Gell-Mann, Nobel Prizewinner in Physics
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Monday 28 October 2002 11:26 am, bigman@monster-solutions.net wrote:

> my comments for each question are in BOLD... thanks for all of the help.

> > > iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
> >
> > I don't like the look of that rule !
>
> IT SHOULD BE -O ETH1 AND NOT -O ETH2

I know.   I just thought you should check whether this was a typo in your 
email, or a typo in the original script...

> > the best thing might be to add a LOGging
> > rule just before the DROP rule in each of your lan1-lan2-fwd and
> > lan2-lan1-fwd chains so you can see if anything's being blocked...
>
> SO DHCRELAY WILL USE FORWARDING INSTEAD OF OUTPUT AND INPUT FOR IT TO WORK?

No, sorry, I should have suggested adding the LOGging rules to the chains 
lan1-in lan2-in and lan1-lan2.

You are correct that dhcrelay is supposed to pick up broadcasts on the source 
network (which will come in to the firewall via the INPUT chain) and the 
dhcrelay application then generates its own packet to send to the dhcp server 
(which will go out via the OUTPUT chain).

Replies should come back in from the dhcp server through the INPUT chain, and 
then go back out to the original client through the OUTPUT chain.

No packets are expected to be FORWARDed (routed).

Antony.

-- 

KDE 3.0.3 contains an important fix for handling SSL certificates.  Users of 
Internet Explorer, which suffers from the same problem but which
does not yet have a fix available, are also encouraged to switch to KDE 3.0.3.

http://www.kde.org/announcements/announce-3.0.3.html

Re: DHCRELAY through IPTABLES Firewall

[bigman]

here is how I ended up fixing my problem. However I have just discovered it
only works with one client. When I try to get another client to obtain an IP
it does not work. Any ideas? Is DNAT limiting me on one MAC to pass through
or something? I am lost here.


1)    turned off DHCPD and DHCRELAY on firewall
2)    iptables -t nat -A PREROUTING -i eth2 -p udp --dport 67 -j
DNAT --to-destination 192.168.1.70
3)    iptables -A FORWARD -p udp -m multiport --dport 67,68 -j ACCEPT

----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 28, 2002 6:39 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Monday 28 October 2002 11:26 am, bigman@monster-solutions.net wrote:
>
> > my comments for each question are in BOLD... thanks for all of the help.
>
> > > > iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
> > >
> > > I don't like the look of that rule !
> >
> > IT SHOULD BE -O ETH1 AND NOT -O ETH2
>
> I know.   I just thought you should check whether this was a typo in your
> email, or a typo in the original script...
>
> > > the best thing might be to add a LOGging
> > > rule just before the DROP rule in each of your lan1-lan2-fwd and
> > > lan2-lan1-fwd chains so you can see if anything's being blocked...
> >
> > SO DHCRELAY WILL USE FORWARDING INSTEAD OF OUTPUT AND INPUT FOR IT TO
WORK?
>
> No, sorry, I should have suggested adding the LOGging rules to the chains
> lan1-in lan2-in and lan1-lan2.
>
> You are correct that dhcrelay is supposed to pick up broadcasts on the
source
> network (which will come in to the firewall via the INPUT chain) and the
> dhcrelay application then generates its own packet to send to the dhcp
server
> (which will go out via the OUTPUT chain).
>
> Replies should come back in from the dhcp server through the INPUT chain,
and
> then go back out to the original client through the OUTPUT chain.
>
> No packets are expected to be FORWARDed (routed).
>
> Antony.
>
> --
>
> KDE 3.0.3 contains an important fix for handling SSL certificates.  Users
of
> Internet Explorer, which suffers from the same problem but which
> does not yet have a fix available, are also encouraged to switch to KDE
3.0.3.
>
> http://www.kde.org/announcements/announce-3.0.3.html
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Tuesday 29 October 2002 7:37 am, bigman@monster-solutions.net wrote:

> here is how I ended up fixing my problem. However I have just discovered it
> only works with one client. When I try to get another client to obtain an
> IP it does not work. Any ideas? Is DNAT limiting me on one MAC to pass
> through or something? I am lost here.

Please can you confirm whether this works at all for a client which does not 
have an IP address to start with (ie it's not a renewal, or a request for the 
last IP address it had).   I don't see how it can work for a totally clean 
client.

> 1)    turned off DHCPD and DHCRELAY on firewall
> 2)    iptables -t nat -A PREROUTING -i eth2 -p udp --dport 67 -j
> DNAT --to-destination 192.168.1.70
> 3)    iptables -A FORWARD -p udp -m multiport --dport 67,68 -j ACCEPT

Okay, what this is doing is taking the original client's DHCP request, which 
has the following characteristics:
Source IP address = 0.0.0.0
Destination IP address = 0.0.0.0
Source MAC address = client's mac address
Destinaton MAC address = FF:FF:FF:FF:FF:FF

The broadcast MAC address means it gets to your firewall.

The PREROUTING rule then sets a destination IP address, and the normal 
routing system of Linux gives it a source MAC address = your Firewall, and a 
destination MAC address = the DHCP server.

The request gets to the server, it allocates an IP address based on the MAC 
address of your firewall (because that's where the local packet came from; 
remember MAC addresses only work within physical subnets), and sends the 
response back again.

The response has:
Source IP address = 192.168.1.70
Destination IP address = assigned DHCP address
Source MAC address = DHCP server
Destination MAC address = Firewall

Therefore the firewall receives the packet (because of the destination MAC 
address), forwards the packet on to the destination IP address (because of 
your rule 3), and the client gets an IP address.

The bit which I don't think can work unless the client already had an IP 
address (and the request was just a renewal, or a check that it could have 
the last IP address it had used again), is when the firewall sends the 
response back to the client, because unless the client responds to an ARP 
request from the firewall, how does the firewall know which MAC address to 
send the answer back to ?

I can say that this is definitely not the asnwer to your problem, because 
DHCP requests & responses with definitely break across a router (such as a 
netfilter firewall) simply because of what happens to the MAC addresses.

If you want to allocate addresses on one subnet from a DHCP server on another 
subnet you must use DHCRELAY.

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

Re: DHCRELAY through IPTABLES Firewall

[bigman]

below is what gets logged when using DHCRELAY. It looks like it will work
but then I never see the request from the 192.168.2.69 (firewall) hit the
DHCP server which I am running a sniffer on. I must be making this harder
then it should be. Can you provide me with the steps to get DHCRELAY working
across different subnets. I really appreciate all of the help.

Oct 29 07:13:12 firewall kernel: IN=eth2 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8523 PROTO=UDP
SPT=68 DPT=67 LEN=308
Oct 29 07:13:12 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=67
DPT=67 LEN=308
Oct 29 07:13:27 firewall kernel: IN=eth2 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8537 PROTO=UDP
SPT=68 DPT=67 LEN=308
Oct 29 07:13:27 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=67
DPT=67 LEN=308


----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Tuesday, October 29, 2002 4:15 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Tuesday 29 October 2002 7:37 am, bigman@monster-solutions.net wrote:
>
> > here is how I ended up fixing my problem. However I have just discovered
it
> > only works with one client. When I try to get another client to obtain
an
> > IP it does not work. Any ideas? Is DNAT limiting me on one MAC to pass
> > through or something? I am lost here.
>
> Please can you confirm whether this works at all for a client which does
not
> have an IP address to start with (ie it's not a renewal, or a request for
the
> last IP address it had).   I don't see how it can work for a totally clean
> client.
>
> > 1)    turned off DHCPD and DHCRELAY on firewall
> > 2)    iptables -t nat -A PREROUTING -i eth2 -p udp --dport 67 -j
> > DNAT --to-destination 192.168.1.70
> > 3)    iptables -A FORWARD -p udp -m multiport --dport 67,68 -j ACCEPT
>
> Okay, what this is doing is taking the original client's DHCP request,
which
> has the following characteristics:
> Source IP address = 0.0.0.0
> Destination IP address = 0.0.0.0
> Source MAC address = client's mac address
> Destinaton MAC address = FF:FF:FF:FF:FF:FF
>
> The broadcast MAC address means it gets to your firewall.
>
> The PREROUTING rule then sets a destination IP address, and the normal
> routing system of Linux gives it a source MAC address = your Firewall, and
a
> destination MAC address = the DHCP server.
>
> The request gets to the server, it allocates an IP address based on the
MAC
> address of your firewall (because that's where the local packet came from;
> remember MAC addresses only work within physical subnets), and sends the
> response back again.
>
> The response has:
> Source IP address = 192.168.1.70
> Destination IP address = assigned DHCP address
> Source MAC address = DHCP server
> Destination MAC address = Firewall
>
> Therefore the firewall receives the packet (because of the destination MAC
> address), forwards the packet on to the destination IP address (because of
> your rule 3), and the client gets an IP address.
>
> The bit which I don't think can work unless the client already had an IP
> address (and the request was just a renewal, or a check that it could have
> the last IP address it had used again), is when the firewall sends the
> response back to the client, because unless the client responds to an ARP
> request from the firewall, how does the firewall know which MAC address to
> send the answer back to ?
>
> I can say that this is definitely not the asnwer to your problem, because
> DHCP requests & responses with definitely break across a router (such as a
> netfilter firewall) simply because of what happens to the MAC addresses.
>
> If you want to allocate addresses on one subnet from a DHCP server on
another
> subnet you must use DHCRELAY.
>
> Antony.
>
> --
>
> It is also possible that putting the birds in a laboratory setting
> inadvertently renders them relatively incompetent.
>
>  - Daniel C Dennett
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Tuesday 29 October 2002 11:20 am, bigman@monster-solutions.net wrote:

> below is what gets logged when using DHCRELAY. It looks like it will work
> but then I never see the request from the 192.168.2.69 (firewall) hit the
> DHCP server which I am running a sniffer on. I must be making this harder
> then it should be. Can you provide me with the steps to get DHCRELAY
> working across different subnets. I really appreciate all of the help.
>
> Oct 29 07:13:12 firewall kernel: IN=eth2 OUT=
> MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8523 PROTO=UDP
> SPT=68 DPT=67 LEN=308

Packet comes in on eth2 with broadcast destination IP and MAC adresses, 
source IP address = 0.0.0.0

> Oct 29 07:13:12 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
> DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=67
> DPT=67 LEN=308

The the firewall sends a packet from its own IP address 192.168.2.69 to the 
DHCP server 192.168.1.70 on *eth2* !!!

Why ?

> Oct 29 07:13:27 firewall kernel: IN=eth2 OUT=
> MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8537 PROTO=UDP
> SPT=68 DPT=67 LEN=308

DHCP client hasn't had an answer within 15 seconds so it asks again.

> Oct 29 07:13:27 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
> DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=67
> DPT=67 LEN=308

Firewall sends the request to 192.168.1.70 out of the wrong interface again.

Antony.

-- 

Normal people think "if it ain't broke, don't fix it".
Engineers think "if it ain't broke, it doesn't have enough features yet".

Re: DHCRELAY through IPTABLES Firewall

[bigman]

when I run DHCRELAY -i eth2 it tells me that it is listening on eth2 and
sending on eth2. I assume this is wrong? how do I fix it? is it my routing
table?

----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Tuesday, October 29, 2002 8:03 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Tuesday 29 October 2002 11:20 am, bigman@monster-solutions.net wrote:
>
> > below is what gets logged when using DHCRELAY. It looks like it will
work
> > but then I never see the request from the 192.168.2.69 (firewall) hit
the
> > DHCP server which I am running a sniffer on. I must be making this
harder
> > then it should be. Can you provide me with the steps to get DHCRELAY
> > working across different subnets. I really appreciate all of the help.
> >
> > Oct 29 07:13:12 firewall kernel: IN=eth2 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
> > DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8523 PROTO=UDP
> > SPT=68 DPT=67 LEN=308
>
> Packet comes in on eth2 with broadcast destination IP and MAC adresses,
> source IP address = 0.0.0.0
>
> > Oct 29 07:13:12 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
> > DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=67
> > DPT=67 LEN=308
>
> The the firewall sends a packet from its own IP address 192.168.2.69 to
the
> DHCP server 192.168.1.70 on *eth2* !!!
>
> Why ?
>
> > Oct 29 07:13:27 firewall kernel: IN=eth2 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:08:00:09:f1:b2:ba:08:00 SRC=0.0.0.0
> > DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=8537 PROTO=UDP
> > SPT=68 DPT=67 LEN=308
>
> DHCP client hasn't had an answer within 15 seconds so it asks again.
>
> > Oct 29 07:13:27 firewall kernel: IN= OUT=eth2 SRC=192.168.2.69
> > DST=192.168.1.70 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=67
> > DPT=67 LEN=308
>
> Firewall sends the request to 192.168.1.70 out of the wrong interface
again.
>
> Antony.
>
> --
>
> Normal people think "if it ain't broke, don't fix it".
> Engineers think "if it ain't broke, it doesn't have enough features yet".
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Wednesday 30 October 2002 12:30 am, bigman@monster-solutions.net wrote:

> when I run DHCRELAY -i eth2 it tells me that it is listening on eth2 and
> sending on eth2. I assume this is wrong?

Sounds wrong to me.   Sounds kinda pointless to me.   If you wanted the 
requests to go out on the same network they came in on, you wouldn't need a 
relay....

> how do I fix it? is it my routing table?

Could be - what does your routing table say ?

My copy of "man dhcrelay" says:

dhcrelay [ -p port ] [ -d ] [ -q ] [ -i if0 [ ...  -i ifN ] ] server0
    [ ...serverN ]

The DHCP Relay Agent listens for DHCP requests on all interfaces attached to 
a host, unless one or more  interfaces  are specified on the command line 
with the -i flag.

When a query is received, dhcrelay forwards it to the list of DHCP servers 
specified on the command line.   When a reply is received, it is broadcast or 
unicast on the network from whence the original request came.

Therefore I think your command should be:

dhcrelay -i eth2 192.168.1.70

If this sends packets to 192.168.1.70 out of eth2, try pinging 192.168.1.70 
and see where the packets come out of then.

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Re: DHCRELAY through IPTABLES Firewall

[bigman]

I fixed my problem. I downloaded the newest source code and compiled it and
ran DHCRELAY -i eth1 -i eth2 192.168.1.70 and now it is working. Thanks for
all of the help.

----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Tuesday, October 29, 2002 7:41 PM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Wednesday 30 October 2002 12:30 am, bigman@monster-solutions.net wrote:
>
> > when I run DHCRELAY -i eth2 it tells me that it is listening on eth2 and
> > sending on eth2. I assume this is wrong?
>
> Sounds wrong to me.   Sounds kinda pointless to me.   If you wanted the
> requests to go out on the same network they came in on, you wouldn't need
a
> relay....
>
> > how do I fix it? is it my routing table?
>
> Could be - what does your routing table say ?
>
> My copy of "man dhcrelay" says:
>
> dhcrelay [ -p port ] [ -d ] [ -q ] [ -i if0 [ ...  -i ifN ] ] server0
>     [ ...serverN ]
>
> The DHCP Relay Agent listens for DHCP requests on all interfaces attached
to
> a host, unless one or more  interfaces  are specified on the command line
> with the -i flag.
>
> When a query is received, dhcrelay forwards it to the list of DHCP servers
> specified on the command line.   When a reply is received, it is broadcast
or
> unicast on the network from whence the original request came.
>
> Therefore I think your command should be:
>
> dhcrelay -i eth2 192.168.1.70
>
> If this sends packets to 192.168.1.70 out of eth2, try pinging
192.168.1.70
> and see where the packets come out of then.
>
> Antony.
>
> --
>
> In science, one tries to tell people
> in such a way as to be understood by everyone
> something that no-one ever knew before.
>
> In poetry, it is the exact opposite.
>
>  - Paul Dirac
>

Re: DHCRELAY through IPTABLES Firewall

[bigman]

and I have also looked into this further by putting a sniffer on my DHCP
server. I see the request come in from the system that is getting an IP
successfully, but I never see a request from the system that is failing.
Both systems are on the same subnet so they should be using the same
netfilter rules.

----- Original Message -----
From: <bigman@monster-solutions.net>
To: "Antony Stone" <Antony@Soft-Solutions.co.uk>;
<netfilter@lists.netfilter.org>
Sent: Tuesday, October 29, 2002 2:37 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> here is how I ended up fixing my problem. However I have just discovered
it
> only works with one client. When I try to get another client to obtain an
IP
> it does not work. Any ideas? Is DNAT limiting me on one MAC to pass
through
> or something? I am lost here.
>
>
> 1)    turned off DHCPD and DHCRELAY on firewall
> 2)    iptables -t nat -A PREROUTING -i eth2 -p udp --dport 67 -j
> DNAT --to-destination 192.168.1.70
> 3)    iptables -A FORWARD -p udp -m multiport --dport 67,68 -j ACCEPT
>
> ----- Original Message -----
> From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> To: <netfilter@lists.netfilter.org>
> Sent: Monday, October 28, 2002 6:39 AM
> Subject: Re: DHCRELAY through IPTABLES Firewall
>
>
> > On Monday 28 October 2002 11:26 am, bigman@monster-solutions.net wrote:
> >
> > > my comments for each question are in BOLD... thanks for all of the
help.
> >
> > > > > iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
> > > >
> > > > I don't like the look of that rule !
> > >
> > > IT SHOULD BE -O ETH1 AND NOT -O ETH2
> >
> > I know.   I just thought you should check whether this was a typo in
your
> > email, or a typo in the original script...
> >
> > > > the best thing might be to add a LOGging
> > > > rule just before the DROP rule in each of your lan1-lan2-fwd and
> > > > lan2-lan1-fwd chains so you can see if anything's being blocked...
> > >
> > > SO DHCRELAY WILL USE FORWARDING INSTEAD OF OUTPUT AND INPUT FOR IT TO
> WORK?
> >
> > No, sorry, I should have suggested adding the LOGging rules to the
chains
> > lan1-in lan2-in and lan1-lan2.
> >
> > You are correct that dhcrelay is supposed to pick up broadcasts on the
> source
> > network (which will come in to the firewall via the INPUT chain) and the
> > dhcrelay application then generates its own packet to send to the dhcp
> server
> > (which will go out via the OUTPUT chain).
> >
> > Replies should come back in from the dhcp server through the INPUT
chain,
> and
> > then go back out to the original client through the OUTPUT chain.
> >
> > No packets are expected to be FORWARDed (routed).
> >
> > Antony.
> >
> > --
> >
> > KDE 3.0.3 contains an important fix for handling SSL certificates.
Users
> of
> > Internet Explorer, which suffers from the same problem but which
> > does not yet have a fix available, are also encouraged to switch to KDE
> 3.0.3.
> >
> > http://www.kde.org/announcements/announce-3.0.3.html
> >
>
>

Re: DHCRELAY through IPTABLES Firewall

[Antony Stone]

On Tuesday 29 October 2002 10:02 am, bigman@monster-solutions.net wrote:

> and I have also looked into this further by putting a sniffer on my DHCP
> server. I see the request come in from the system that is getting an IP
> successfully, but I never see a request from the system that is failing.
> Both systems are on the same subnet so they should be using the same
> netfilter rules.

Would I be right in guessing that the system which works already has a DHCP 
address, and is either renewing it (before its lease runs out) or is 
requesting the same address again (after the lease has run out), whereas the 
system which fails has never had a DHCP address and is trying to get one for 
the first time ?

Antony.

-- 

If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.

Re: DHCRELAY through IPTABLES Firewall

[bigman]

i have removed the DNAT rule and started DHCRELAY -i eth2 192.168.1.70 and
rebooted the system that was able to get an IP via DHCP with the DNAT rule
and it was not successful after the reboot. For some reason after DHCRELAY
gets the request and tries to forward to the DHCP server it is not making
it.

----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Tuesday, October 29, 2002 5:29 AM
Subject: Re: DHCRELAY through IPTABLES Firewall


> On Tuesday 29 October 2002 10:02 am, bigman@monster-solutions.net wrote:
>
> > and I have also looked into this further by putting a sniffer on my DHCP
> > server. I see the request come in from the system that is getting an IP
> > successfully, but I never see a request from the system that is failing.
> > Both systems are on the same subnet so they should be using the same
> > netfilter rules.
>
> Would I be right in guessing that the system which works already has a
DHCP
> address, and is either renewing it (before its lease runs out) or is
> requesting the same address again (after the lease has run out), whereas
the
> system which fails has never had a DHCP address and is trying to get one
for
> the first time ?
>
> Antony.
>
> --
>
> If the human brain were so simple that we could understand it,
> we'd be so simple that we couldn't.
>