Re: [SLE] Solved, Re: [SLE] Firewall oddity

• Previous message: Steven T. Hatton: "Re: [SLE] Clearing up the FUD on CLI/Mono"
• In reply to: Simon Roberts: "[SLE] Solved, Re: [SLE] Firewall oddity"
• Next in thread: Simon Roberts: "Re: [SLE] Solved, Re: [SLE] Firewall oddity"
• Reply: Simon Roberts: "Re: [SLE] Solved, Re: [SLE] Firewall oddity"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 12 Nov 2005 18:16:30 -0600
To: suse-linux-e@suse.com

On 11/12/2005 10:48 AM, Simon Roberts wrote:
>Thanks Darryl for the pointers, I finally worked out what's going on
>(with a little more help from ethereal and by setting the "log
>everything" mode on the firewall).
>
>The problem was that for some reason setting dhcp as an allowed service
>doesn't quite do the job. You have to add bootpc and bootps to the
>"allowed broadcast" field too.
>
>I'm not sure how this ever worked, given that the broadcast field in
>Yast's firewall wizard isn't something I'd played with before, and I'm
>also unsure why Yast isn't smart enough to set that field when I told
>it that I wanted to allow dhcp. Maybe 10.0 is smarter, or maybe I did
>something unimaginably fiendish to confuse it :)
>
>Anyway, now, with bootpc and bootps as allowed broadcasts, it works
>again.
Apologies for not getting back to you sooner, but it's good to see you
were able to resolve this on your own. I doubt my "pointers" had much
bearing on that; perhaps I got you to focus your attention on the
firewall a bit more, but nothing more than that. My previous message
said nothing about initial broadcast messages, which I mistakenly
thought were actually working -- I thought you were saying that renewal
requests weren't getting through. Yes, it is strange that your dhcp
worked before, without that broadcast service being specifically allowed
(are you certain the internal interface wasn't previously open to *all*
broadcast messages?). But I've seen stranger things reported in here
before :)

The following explanation should help future readers with the same
problem understand what has happened here:

At first, a system usually has no idea where any dhcp server is, so it
has to use a broadcast message to find one (it will also obtain a first
IP lease at this time). When the time comes to renew the initial lease,
it does know of a dhcp server, so a unicast message is possible.

On the dhcp server (which is what Simon is configuring here), the DMZ
and/or INT interfaces must therefore be opened for INPUT on port bootps
(67) for both types of messages. The lines in the firewall config for
FW_SERVICES_INT_TCP, etc only pertain to unicast messages, with a
separate set used for broadcast. It makes no sense to combine the two
sets of variables, because very few services need to use broadcast; you
would have to write exceptions into the script for those that did. It's
far simpler to use separate config variables, one set for unicast
messages and another for broadcast.

-- 
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@suse.com
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@suse.com

• Previous message: Steven T. Hatton: "Re: [SLE] Clearing up the FUD on CLI/Mono"
• In reply to: Simon Roberts: "[SLE] Solved, Re: [SLE] Firewall oddity"
• Next in thread: Simon Roberts: "Re: [SLE] Solved, Re: [SLE] Firewall oddity"
• Reply: Simon Roberts: "Re: [SLE] Solved, Re: [SLE] Firewall oddity"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]