James Kosin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
Try running "service ip6tables save" as well, and see if that
helps. Also, check the date/contents of /etc/sysconfig/iptables
to make sure your changes are being saved. If not, look for a
selinux message in the logs about it...
Mikkel
I did check the contents of /etc/sysconfig/iptables before and
did see the new rules there....
Using "service ip6tables save" seems to have "done the trick"....
is that WAD, or is that bugzilla-able :-)
Not exactly a WAG, but not based on personal experience. (I have
IP6 turned off on the local network...) It is more troubleshooting
experience that gives me ideas on what to try. Something on the
order of asking yourself what can be affecting firewall rules.
Start with the easy things - iptables, ip6 tables. Check to make
sure selinux is not blocking re-writing the rewriting of the rules.
If saving the changes to ip6tables "fixes" the problem, as it look
like it did here, then it looks like there needs to be a change so
that "service iptables save" updates ip6tables if they are going to
affect the rules as well. (And the reverse - saving ip6tables
should also save iptables.) But I am wondering why the default
rules are being restored. I am on shaky ground here, because I have
not looked at the network scripts for a while. Is it because of the
DHCP lease getting renewed, the network connection dropping, and
being restored, or something else? I can see the rules needing to
be reloaded if you get a new IP address. But not just because the
lease was renewed.
I see that you have filed a bug report, so hopefully this will be
answered by the people that really know the network scripts...
Mikkel
Mikkel,
I believe Linux actually assumes the lease renewal will change the
IP. This goes back to the DHCP specification that says that the
renewal will not guarantee the requester the same IP. Windows took
the opposite approach and all their sub-layers assume they will get
the same IP address and actually request in the renewal the same
address. If Windows is unable to get the same address then it falls
back to requesting a new address with a new lease renewal requesting a
new address.
It's been a year or so since I was working on debugging DHCP clients in
other systems, but the way it is supposed to work is that for a renewal,
the client should request (via unicast) it's current address.... the
server (after some checking) either grants or denies that request.
There should not be any "assumptions" made at all.... when T1 fires
(generally approx half way through the lease period, the client asks the
server to renew the current address.... if the client doesn't get an
answer one way or the other it may retry unicasting a few times... but
when T2 fires, the client broadcasts a request for an address from any
dhcp server...
If Linux is making weird assumptions that "oh no, my lease is about to
expire... I better reset all my firewall rules etc...." well, that's
just wrong. (TM) :-)
If people are silly enough to code dynamic addresses into their firewall
rules, they deserve what they get when/if that address changes. :-)
But... my "vanishing rules" problem APPEARS to be related to (or
coincident with) DHCP renewal, and possibly the firestarter programs....
I have not quite tracked it all down yet.
