dhclient blues

I hope someone here can give me a pointer to a solution
because this has me ripping my hair.

There is a hole in the wall that brings internet connectivity
and IP addresses assigned by DHCP. No modem or anything, just
an ethernet plug. I am entitled to 5 IPs, which are assigned
to me at random and non-consecutively anywhere within a random
/26. As long as I put a switch on the wall and connect machines
to it, I have no problems.

However, I want a firewall between myself and the net. This
means a box with two interfaces, say eth0 to the ISP and
eth1 to the LAN. The machines on the LAN must, for various
reasons, remain on public IP space. Thus, NAT is ruled out.

And here comes trouble. eth0 on the firewall gets an IP from
the ISP alright. I have dhcrelay running, so the machines on
the LAN can also get their IPs from the ISP as soon as eth1
on the firewall is up. But how do I get an IP for eth1?

If I configure eth1 for dhcp, it sends its requests out on
the LAN, which is pretty useless. At the same time I can't
configure it statically because I don't have a contiguous
subnet, so whatever IP I could take at random from the
random /26 I happen to be part of, might be assigned to
someone else. And dhcrelay will relay *through* the machine,
but not *on* it.

Any ideas anyone how I could get eth1 to send its dhcp
requests out through eth0? Or how I could get eth0 to request
an extra IP and then route it through to eth1?

Z

On Sat, 10 Jul 2004 00:39:43 +0200, Zenon Panoussis scribbled:

> I hope someone here can give me a pointer to a solution
> because this has me ripping my hair.
>
> There is a hole in the wall that brings internet connectivity
> and IP addresses assigned by DHCP. No modem or anything, just
> an ethernet plug. I am entitled to 5 IPs, which are assigned
> to me at random and non-consecutively anywhere within a random
> /26. As long as I put a switch on the wall and connect machines
> to it, I have no problems.
>
> However, I want a firewall between myself and the net. This
> means a box with two interfaces, say eth0 to the ISP and
> eth1 to the LAN. The machines on the LAN must, for various
> reasons, remain on public IP space. Thus, NAT is ruled out.
>
> And here comes trouble. eth0 on the firewall gets an IP from
> the ISP alright. I have dhcrelay running, so the machines on
> the LAN can also get their IPs from the ISP as soon as eth1
> on the firewall is up. But how do I get an IP for eth1?
>
> If I configure eth1 for dhcp, it sends its requests out on
> the LAN, which is pretty useless. At the same time I can't
> configure it statically because I don't have a contiguous
> subnet, so whatever IP I could take at random from the
> random /26 I happen to be part of, might be assigned to
> someone else. And dhcrelay will relay *through* the machine,
> but not *on* it.
>
> Any ideas anyone how I could get eth1 to send its dhcp
> requests out through eth0? Or how I could get eth0 to request
> an extra IP and then route it through to eth1?
>
> Z

Basically, you want two nic's in the same box to be part of the same
subnet, which seems pretty useless. Why not activate an iptables firewall
on those machines that need protection?

What is your reason for not willing to set up your own local network behind
a firewall?

There are fine solutions for this, also one's that provide for a DMZ if
needed.

--
GerardLinux ay tee filternet dee oo tee ann el

|
\ /
.---.
'-. | | .-'
___| |___
-= [ ] =-
`---. .---'
__||__ | | __||__
'-..-' | | '-..-'
|| | | ||
||_.-| |-,_||
.-"` `"`'` `"-.
.' '.

Jesus is alive, I spoke with Him this morning!

Gerard Wassink wrote:

> Basically, you want two nic's in the same box to be part of the same
> subnet, which seems pretty useless.

When a firewall or a router or a bridge or other similar
device does not NAT, having the WAN IP on the same subnet
as the LAN IP is not useless, but normal, natural and necessary.

> Why not activate an iptables firewall
> on those machines that need protection?

Perhaps because they run Windoze? Perhaps because they
are honeypots? Perhaps for whatever other reason of my
own?

> What is your reason for not willing to set up your own local network behind
> a firewall?

> There are fine solutions for this, also one's that provide for a DMZ if
> needed.

I think you can gather from my posting that I am no
newbie in these matters. If then I write "the machines
on the LAN must [...] remain on public IP space",
please accept that as a fact. Questioning the premises
behind a question can indeed be useful sometimes, but
not if it appears that the person asking the question
has already examined his premises critically.

*

For the rest I should mention that I tried putting
/sbin/ip ro add 255.255.255.0/24 dev eth0
as well as (but not at the same time)
/sbin/ip ro add 255.255.255.255 dev eth0 scope host
in /etc/dhclient-exit-hooks. This gets run after eth0
has been started and before eth1 gets initialised,
but it didn't help.

Z

On Sat, 10 Jul 2004 12:48:25 +0200, Zenon Panoussis scribbled:

[SNIP]

>> Why not activate an iptables firewall
>> on those machines that need protection?
>
> Perhaps because they run Windoze? Perhaps because they
> are honeypots? Perhaps for whatever other reason of my
> own?

Pfff, looks like I pissed you off. Didn't intend to...

OK, don't use iptables then. But could not ZoneAlarm or the likes of it do
the trick for you?


>> What is your reason for not willing to set up your own local network behind
>> a firewall?
>
>> There are fine solutions for this, also one's that provide for a DMZ if
>> needed.

> I think you can gather from my posting that I am no
> newbie in these matters. If then I write "the machines
> on the LAN must [...] remain on public IP space",
> please accept that as a fact. Questioning the premises
> behind a question can indeed be useful sometimes, but
> not if it appears that the person asking the question
> has already examined his premises critically.


Oh well, I was just curious about your reasons for doing things the way you
suggested...

My reason to ask is that it seems to me so obvious to have only *one*
firewall per subnet, and according to your story, all of your machines
*are* on the same subnet.


[SNIP]


As for the rest: I'd look into starting a seperate dhcp client or process
for eth1, *after* eth0 has gotten it's ip-address...


--
GerardLinux ay tee filternet dee oo tee ann el

|
\ /
.---.
'-. | | .-'
___| |___
-= [ ] =-
`---. .---'
__||__ | | __||__
'-..-' | | '-..-'
|| | | ||
||_.-| |-,_||
.-"` `"`'` `"-.
.' '.

Jesus is alive, I spoke with Him this morning!

Gerard Wassink wrote:

> Pfff, looks like I pissed you off. Didn't intend to...

You did, but never mind. This dhcp stuff had me in a bad
mood. Sorry for lashing out.

> OK, don't use iptables then. But could not ZoneAlarm or the likes of it do
> the trick for you?

I refuse to give up that easily.

> Oh well, I was just curious about your reasons for doing things the way you
> suggested...

There's an application running on one of the LAN machines,
which reports its IP to the outside world on the application
level. Since the packet payload can't be mangled by iptables,
if I put that machine on NAT'ed private IP, that application
would end up reporting itself with one IP on the network level
and a different IP on the application level, thus confusing
its clients on the internet to the point that they would no
longer work.

> My reason to ask is that it seems to me so obvious to have only *one*
> firewall per subnet, and according to your story, all of your machines
> *are* on the same subnet.

Yes, correct, but it is not *my* subnet; it's the ISP's subnet
and, as such, part of the big evil internet.

> As for the rest: I'd look into starting a seperate dhcp client or process
> for eth1, *after* eth0 has gotten it's ip-address...

Tried that, it didn't work. I also tried routing the broadcast
address via eth0 with ip and re-routing it with iptables, to
no avail. No matter what I do, dhclient will send out the
requests on the interface that is to be configured, in this
case eth1. I think I've hit a dead end there.

I'm trying an alternative solution now by turning the firewall
into a bridge. That means that the interfaces on the firewall
don't get an IP at all (man brctl), so the entire dhcp problem
goes away. It remains to be seen though how well packet filtering
works on a bridge; it seems to have a lot of limitations.

Z

On Sat, 10 Jul 2004 16:59:00 +0200, Zenon Panoussis scribbled:

> Gerard Wassink wrote:
>
>> Pfff, looks like I pissed you off. Didn't intend to...
>
> You did, but never mind. This dhcp stuff had me in a bad
> mood. Sorry for lashing out.

Okay, no problem, just glad we sorted it out... :-D

>> OK, don't use iptables then. But could not ZoneAlarm or the likes of it do
>> the trick for you?
>
> I refuse to give up that easily.

And I salute you for that! (when I think of something, most of the time I
go on untill it works that way, or untill it grows over my head, whichever
comes first).

>> Oh well, I was just curious about your reasons for doing things the way you
>> suggested...
>
> There's an application running on one of the LAN machines,
> which reports its IP to the outside world on the application
> level. Since the packet payload can't be mangled by iptables,
> if I put that machine on NAT'ed private IP, that application
> would end up reporting itself with one IP on the network level
> and a different IP on the application level, thus confusing
> its clients on the internet to the point that they would no
> longer work.

Bridging is the first thing that comes to mind, as you yourself describe
further on...

[snip]

>> As for the rest: I'd look into starting a seperate dhcp client or process
>> for eth1, *after* eth0 has gotten it's ip-address...
>
> Tried that, it didn't work. I also tried routing the broadcast
> address via eth0 with ip and re-routing it with iptables, to
> no avail. No matter what I do, dhclient will send out the
> requests on the interface that is to be configured, in this
> case eth1. I think I've hit a dead end there.
>
> I'm trying an alternative solution now by turning the firewall
> into a bridge. That means that the interfaces on the firewall
> don't get an IP at all (man brctl), so the entire dhcp problem
> goes away. It remains to be seen though how well packet filtering
> works on a bridge; it seems to have a lot of limitations.
>

I'm out of suggestions.

Hope 4 u that anyone else knows...

success.

--
GerardLinux ay tee filternet dee oo tee ann el

|
\ /
.---.
'-. | | .-'
___| |___
-= [ ] =-
`---. .---'
__||__ | | __||__
'-..-' | | '-..-'
|| | | ||
||_.-| |-,_||
.-"` `"`'` `"-.
.' '.

Jesus is alive, I spoke with Him this morning!

The OTHER Kevin in San Diego wrote:

> I've been battling dhclient for the past 4 days... I'm beginning to
> think it hates me.

It's because you're not kind to it. It thinks you hate it (and
it's probably right), so it reacts by getting over-defensive and
you get this escalating situation. Let things cool down for a
while, then start all over again and talk *nicely* to it. Or post
the exact problem here and someone might be able to mediate ;)

> (and I'm really getting annoyed with iptables as
> well.. (How come RPM doesn't REALLY uninstall the thing? It's like a
> friggin' virus....)

If you do 'rpm -e iptables' you only uninstall the utility. To get
completely rid if iptables you need to unload the kernel modules
too. Try
# for i in `lsmod |grep ipt | awk '{ print $1 }'`; do rmmod $i; done
and then check to see what loads them in the first place
and/or go the really brutal way and do
# rm -f /lib/modules/`uname -`/kernel/net/ipv4/netfilter/ip*; reboot

But why would you want to get rid of iptables?

Z

Zenon Panoussis wrote:
>
> I hope someone here can give me a pointer to a solution
> because this has me ripping my hair.
>
> There is a hole in the wall that brings internet connectivity
> and IP addresses assigned by DHCP. No modem or anything, just
> an ethernet plug. I am entitled to 5 IPs, which are assigned
> to me at random and non-consecutively anywhere within a random
> /26. As long as I put a switch on the wall and connect machines
> to it, I have no problems.
>
> However, I want a firewall between myself and the net. This
> means a box with two interfaces, say eth0 to the ISP and
> eth1 to the LAN. The machines on the LAN must, for various
> reasons, remain on public IP space. Thus, NAT is ruled out.
>
> And here comes trouble. eth0 on the firewall gets an IP from
> the ISP alright. I have dhcrelay running, so the machines on
> the LAN can also get their IPs from the ISP as soon as eth1
> on the firewall is up. But how do I get an IP for eth1?
>
> If I configure eth1 for dhcp, it sends its requests out on
> the LAN, which is pretty useless. At the same time I can't
> configure it statically because I don't have a contiguous
> subnet, so whatever IP I could take at random from the
> random /26 I happen to be part of, might be assigned to
> someone else. And dhcrelay will relay *through* the machine,
> but not *on* it.
>
> Any ideas anyone how I could get eth1 to send its dhcp
> requests out through eth0? Or how I could get eth0 to request
> an extra IP and then route it through to eth1?
>
> Z
>
>


The way mine is set is E0 gets an IP from the ISP, E1 acts as the inside
DHCP with IP range 192.168.0.1--192.168.0.100 192.168.0.40 is the
gateway so that is the IP of E1 (staticly set through the CLI) and all
computers that have internet access are NATed.
Here is my show run.
show run
Building configuration...

Current configuration : 2637 bytes
!
version 12.3
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname NOVA2
!
boot-start-marker
boot-end-marker
!
logging buffered 52000 debugging
logging console critical
enable secret 5 $1$hljq$spSoKKsmqyDm.1FBehCcP0
!
username xxx privilege 15 password 7 0305F060F0
clock timezone America/Chicago -6
clock summer-time America/Chicago date Apr 6 2003 2:00 Oct 26 2003 2:00
no aaa new-model
ip subnet-zero
no ip source-route
ip tcp synwait-time 10
no ip domain lookup
ip dhcp excluded-address 192.168.0.1 192.168.0.9
ip dhcp excluded-address 192.168.0.101 192.168.0.254
ip dhcp excluded-address 192.168.0.40
!
ip dhcp pool sdm-pool1
network 192.168.0.0 255.255.255.0
default-router 192.168.0.40
lease infinite
!
!
no ip bootp server
ip cef
ip inspect name DEFAULT100 smtp
ip inspect name DEFAULT100 tcp
ip inspect name DEFAULT100 tftp
ip inspect name DEFAULT100 udp
ip inspect name web http
ip audit notify log
ip audit po max-events 100
ip ssh time-out 60
ip ssh authentication-retries 2
no ftp-server write-enable
!
!
!
no crypto isakmp enable
!
!
!
!
interface Ethernet0
description $FW_INSIDE$$ETH-LAN$
ip address 192.168.0.40 255.255.255.0
ip access-group 100 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip route-cache flow
no cdp enable
!
interface Ethernet1
description $FW_OUTSIDE$$ETH-WAN$
ip address dhcp client-id Ethernet1
ip access-group 102 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip inspect DEFAULT100 out
ip route-cache flow
duplex auto
no cdp enable
!
ip classless
ip http server
ip http authentication local
ip http secure-server
!
!
logging trap debugging
access-list 100 remark auto generated by SDM firewall configuration
access-list 100 remark SDM_ACL Category=1
access-list 100 permit ip any any
access-list 102 remark auto generated by SDM firewall configuration
access-list 102 remark SDM_ACL Category=1
access-list 102 permit ip any any log
no cdp run
!
control-plane
!
banner login ^CAuthorized access only!
Disconnect IMMEDIATELY if you are not an authorized user!^C
!
line con 0
login local
no modem enable
transport preferred all
transport output telnet
line aux 0
login local
transport preferred all
transport output telnet
line vty 0 4
privilege level 15
login local
transport preferred all
transport input telnet ssh
transport output all
!
scheduler max-task-time 5000
scheduler interval 500
!
end

NOVA2#