Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
Why are the new rules not remembered?
You probably have IPTABLES_SAVE_ON_STOP="no" IPTABLES_SAVE_ON_RESTART="no" in /etc/sysconfig/iptables-config and losing current rules on reboot/shutdown?
HTH, Sasha
Don Russell wrote:
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
Mikkel L. Ellertson wrote:
Don Russell wrote:
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Are you using DHCP on any of your interfaces?
- -James
James Kosin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Are you using DHCP on any of your interfaces?
The FC7 box has one interface, yes, it uses DHCP to get an address from my (Cisco) router.... it always gets the same IP address because I have a specific "dhcp pool" defined in Cisco IOS for that one MAC address.
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it - there should be advice about changing 2 variables, but there is the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
To quote Alice.... "Curiouser and curiouser..."
This morning I can't connect to webmin again.... when I connect to my FC7 box via ssh and use iptables -L... sure enough, the two rules are gone again.... and this is AFTER I did a "'service iptables save", when I added the two rules yesterday.
#iptables -I INBOUND 13 -p tcp --dport 10000 -j ACCEPT #iptables -I INBOUND 14 -p tcp --dport 20000 -j ACCEPT #service iptables save Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
The good news is... when I can't connect to webmin, I know what to look for right away and it's solved (temporarily) in a minute....
On Tue, 2007-08-21 at 06:56 -0700, Don Russell wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
To quote Alice.... "Curiouser and curiouser..."
This morning I can't connect to webmin again.... when I connect to my FC7 box via ssh and use iptables -L... sure enough, the two rules are gone again.... and this is AFTER I did a "'service iptables save", when I added the two rules yesterday.
#iptables -I INBOUND 13 -p tcp --dport 10000 -j ACCEPT #iptables -I INBOUND 14 -p tcp --dport 20000 -j ACCEPT #service iptables save Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
The good news is... when I can't connect to webmin, I know what to look for right away and it's solved (temporarily) in a minute....
Are you sure you don't have a rootkit on there? I don't know of a way for the iptables to get changed except by a command being run. If you're not doing it, it's either a cron job somewhere or a lurking hacker. You might want to try doing an nmap scan against the machine and see which ports are open to see if there's a back door that someone's using.
---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@internap.com - - CDN Systems, Internap, Inc. http://www.internap.com - - - - Programmers often confuse Halloween and Christmas. - - After all, 31 Oct is the same as 25 Dec! - ----------------------------------------------------------------------
Rick Stevens wrote:
On Tue, 2007-08-21 at 06:56 -0700, Don Russell wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
To quote Alice.... "Curiouser and curiouser..."
This morning I can't connect to webmin again.... when I connect to my FC7 box via ssh and use iptables -L... sure enough, the two rules are gone again.... and this is AFTER I did a "'service iptables save", when I added the two rules yesterday.
#iptables -I INBOUND 13 -p tcp --dport 10000 -j ACCEPT #iptables -I INBOUND 14 -p tcp --dport 20000 -j ACCEPT #service iptables save Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
The good news is... when I can't connect to webmin, I know what to look for right away and it's solved (temporarily) in a minute....
Are you sure you don't have a rootkit on there? I don't know of a way for the iptables to get changed except by a command being run. If you're not doing it, it's either a cron job somewhere or a lurking hacker. You might want to try doing an nmap scan against the machine and see which ports are open to see if there's a back door that someone's using.
Well.... I "yum remove webmin" and "yum remove usermin" and my iptables rules seem pretty permanent once again.
I'll assume I did some brain-dead thing when installing webmin.... :-)
Don Russell wrote:
Rick Stevens wrote:
On Tue, 2007-08-21 at 06:56 -0700, Don Russell wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
> If you are talking about the rules not surviving a reboot, try > running "service iptables save" and/or "service ip6tables save". If > you want the changes saved automatically, edit > /etc/sysconfig/iptables.conf and change > IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do > the same for /etc/sysconfig/ip6tables.conf. > > Mikkel >
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
To quote Alice.... "Curiouser and curiouser..."
This morning I can't connect to webmin again.... when I connect to my FC7 box via ssh and use iptables -L... sure enough, the two rules are gone again.... and this is AFTER I did a "'service iptables save", when I added the two rules yesterday.
#iptables -I INBOUND 13 -p tcp --dport 10000 -j ACCEPT #iptables -I INBOUND 14 -p tcp --dport 20000 -j ACCEPT #service iptables save Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
The good news is... when I can't connect to webmin, I know what to look for right away and it's solved (temporarily) in a minute....
Are you sure you don't have a rootkit on there? I don't know of a way for the iptables to get changed except by a command being run. If you're not doing it, it's either a cron job somewhere or a lurking hacker. You might want to try doing an nmap scan against the machine and see which ports are open to see if there's a back door that someone's using.
Well.... I "yum remove webmin" and "yum remove usermin" and my iptables rules seem pretty permanent once again.
I'll assume I did some brain-dead thing when installing webmin.... :-)
DAMN! That was a red-herring......
I just ended my ssh session, logged back in that way, and lo and behold, the new rules were gone again. So, I guess I'll install webmin/usermin again.. those are pretty cool apps. :-)
So, it appears that the sequence of - connect from remote machine via ssh - su - - iptables -I ... - service iptables save - exit - logout
Does not make the new iptables rules permanent.... :-( sigh
Don Russell wrote:
I just ended my ssh session, logged back in that way, and lo and behold, the new rules were gone again. So, I guess I'll install webmin/usermin again.. those are pretty cool apps. :-)
So, it appears that the sequence of
- connect from remote machine via ssh
- su -
- iptables -I ...
- service iptables save
- exit
- logout
Does not make the new iptables rules permanent.... :-( sigh
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
Mikkel L. Ellertson wrote:
Don Russell wrote:
I just ended my ssh session, logged back in that way, and lo and behold, the new rules were gone again. So, I guess I'll install webmin/usermin again.. those are pretty cool apps. :-)
So, it appears that the sequence of
- connect from remote machine via ssh
- su -
- iptables -I ...
- service iptables save
- exit
- logout
Does not make the new iptables rules permanent.... :-( sigh
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 :-)
Thank you. :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Don Russell wrote:
<<--snip-->>
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 :-)
Thank you. :-)
That should be bugzilla-able. The ip6tables should have no effect on changing your ip4tables. If they do; then there should be a nice clean way to merge the two into a single save.
- -James
James Kosin wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Don Russell wrote:
<<--snip-->>
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 :-)
Thank you. :-)
That should be bugzilla-able. The ip6tables should have no effect on changing your ip4tables. If they do; then there should be a nice clean way to merge the two into a single save.
Bugzilla'd ... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253877
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
-----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.
- -James
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.
iptables is the userland configuration utility for netfilter in the kernel. It does not delete rules without beeing told to do so.
Thomas
Don Russell wrote:
Mikkel L. Ellertson wrote:
Don Russell wrote:
Mikkel L. Ellertson wrote:
If you are talking about the rules not surviving a reboot, try running "service iptables save" and/or "service ip6tables save". If you want the changes saved automatically, edit /etc/sysconfig/iptables.conf and change IPTABLES_SAVE_ON_RESTART="no" to IPTABLES_SAVE_ON_STOP="yes". Do the same for /etc/sysconfig/ip6tables.conf.
Mikkel
I must have deleted a section of my message somehow before I sent it
- there should be advice about changing 2 variables, but there is
the default state of one, and the needed state of the other...
ah... that's good to know... BUT.... in neither case have I restarted the system....
I'll have a look at that config file though and see if there are any clues. :-)
Maybe what I need to do (as you suggest) is "service iptables save" after adding the rules and verifying they work correctly.
(I looked at the webmin method specifically for some form of "save these rules", but there is only "apply thse rules", which I did need to do)
Please post back what you find, as this seams to be a strange one - the rules should not vanish on a normally running system. Are logging out and logging back in at the console, or bringing down an interface, and bringing it back up between setting the rules, and then vanishing?
Mikkel
IPTABLES_SAVE_ON_RESTART and IPTABLES_SAVE_ON_STOP are both set to the default value of "no".
So, I guess my question becomes, when does the firewall stop or restart?
I log on to a non-root user via ssh, then "su -"/"exit" to make the iptables changes.... I have not restarted the whole machine, nor have I restarted the iptables service.... does it restart periodically for some reason? I haven't added anything to cron etc to make that happen...
I'm not restarting the interface....
I don't see what I could have done that cause d the firewall to stop/restart....
Don Russell wrote:
Twice now, I've applied new rules using iptables -I... to accept specific traffic, and each time those rules "disappeared" a little while later...
I don't see anything in "man iptables" like "... and don't you forget it!" (Of course maybe I missed it...)
This is FC7.... using the cli iptables commands from root.... I also used webmin with the same effect.
Why are the new rules not remembered?
Thanks
For anybody following this saga.... the problem is not with "iptables", but with "firestarter", or the combination of the two.
A new bug is born: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=254147 (It is cross-referenced with the original bug I filed against iptables, and the iptables one closed)
Don Russell (OP)