iptables has amnesia :-)

[Don Russell]

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.