# [SOLVED] Kernel upgrade 2.6.23-r9 > 2.6.25-r7 - iptables cha

## libertytrek

Hi everyone,

Is there a decent guide to how to configure the iptables stuff for the new kernels? It seems to be getting more and more complicated, and I don't understand this stuff much anyway.

I don't need NAT, all I need is a firewall that will filter traffic to my box, and only allow the traffic I explicitly allow...

So, what kernel config options do I need to enable to allow my firewall to start?

I copied the .config from my 2.6.23-r9 kernel to 2.6.25-r7, ran make menuconfig, saved and compiled the new kernel, but I must have missed something because iptables won't start (again - this is the second time in the last year or so that a change in the way iptables is configured in the kernel caused iptables to fail to start)...

When I boot to the 2.6.25-r7, everything works fine, except iptables fails to start, saying there's an error on line 2.

Googling shows that there are apparently a lot of changes (again) in how iptables is configured... but I honestly don't know which options I need to enable...

Thanks for any pointers for dummies as to the minimum needed to be enabled just to do basic firewall filtering.

ThanksLast edited by libertytrek on Fri Oct 24, 2008 1:12 pm; edited 1 time in total

----------

## snIP3r

hi libertytrek!

i would suggest these steps to get your iptables work again:

1. because you installed a new kernel already i would suggest to to a 'make mrproper' in your new kernel directory (this cleans your kernel config completely)

2. copy your old .config to the new kernel directory

3. change into new kernel directory and do a 'make oldconfig' (normally all the old settings including iptalbes support will be set as the old config)

4. setup any new options you want in the new kernel 

5. make and install the new kernel

6. before you reboot reinstall iptables again

7. reboot your machine.

perhaps you have to reboot and then re-emerge iptables...

i remember having similar problems and this procedure fixed it for me, so i think this will make it work again for you too. if not, please post your old and new kernel config so we can check the differences or missing settings.

HTH

snIP3r

----------

## baeksu

I believe the iptables rules are saved in /var/lib/iptables/rules-save. An error on line 2 means that iptables cannot perform the function on line 2 of that file, probably because the appropriate function is not available as a module or built into the kernel.

Please re-configure, rebuild and reboot the kernel as snIP3r suggested, and if there's still an error, post the rules-save file, so we can see where it fails.

----------

## libertytrek

thanks for the replies, but...

If you read my post, you'll see that it has nothing to do with bad rules...

The problem is that the kernel config options changed dramatically between 2.6.23 and 2.6.25...

> 3. change into new kernel directory and do a 'make oldconfig' (normally all the old settings

> including iptalbes support will be set as the old config) 

You can safely do this between MINOR version bumps (ie, 2.6.23-r3 > 2.6.23-r9), but my understanding is you should NEVER use 'make oldconfig' when upgrading between MAJOR versions (ie, 2.6.23-r9 > 2.6.25-r7)...

> I believe the iptables rules are saved in /var/lib/iptables/rules-save.

Maybe, but I saved them manually, and have tested a restore... again:

iptables works fine on the 2.6.23 kernel, but fails to start when booting from the 2.6.25 kernel.

> Please re-configure, rebuild and reboot the kernel as snIP3r suggested,

It is the 'reconfigure' part that has me stumped, and is why I posted...

I am unsure which new kernel config options are needed to duplicate my old functionality... I don't want/need NAT, I just use t he firewall to protect the system (its a mail/web server)...

Thanks for the attempts to help...

----------

## snIP3r

ok, then try to reemerge iptables after the new kernel booted...

----------

## libertytrek

I'm pretty sure I tried that, but its worth a try... but regardless, I've read enough to know that they did make major changes to the way iptables is configured.

I'm just looking for some help in understanding what all of those are, and what are the minimal necessary to support basic tcp filtering to protect a server...

----------

## baeksu

 *Quote:*   

> > 3. change into new kernel directory and do a 'make oldconfig' (normally all the old settings
> 
> > including iptalbes support will be set as the old config)
> 
> You can safely do this between MINOR version bumps (ie, 2.6.23-r3 > 2.6.23-r9), but my understanding is you should NEVER use 'make oldconfig' when upgrading between MAJOR versions (ie, 2.6.23-r9 > 2.6.25-r7)... 

 

I don't think this is true. I've been using 'make oldconfig' since 2.6.17, and have never had any problems, nor have I heard of other people having problems.

Even if 'make oldconfig' was unsafe between major versions, just copying the config and doing 'make menuconfig' is not going to be any better.

If you really are concerned about this, just enable all iptables/netfilter components as modules to ensure you have everything necessary.

 *Quote:*   

> > I believe the iptables rules are saved in /var/lib/iptables/rules-save.
> 
> Maybe, but I saved them manually, and have tested a restore... again:
> 
> iptables works fine on the 2.6.23 kernel, but fails to start when booting from the 2.6.25 kernel.
> ...

 

If you posted your manually saved iptables rules, we would be able to see what's missing in your current kernel configuration, and maybe suggested what to enable to make iptables work.

 *Quote:*   

> I'm pretty sure I tried that, but its worth a try... but regardless, I've read enough to know that they did make major changes to the way iptables is configured. 

 

According to kernelnewbies.org, following were changed between .24 and .25:

 *Quote:*   

> #
> 
> Add CONFIG_NETFILTER_ADVANCED option. (commit)
> 
> #
> ...

 

Between .23 and .24, the only change was:

 *Quote:*   

> Netfilter: Add xt_time match: a "time" match, which allows you to match based on the packet arrival time (at the machine which netfilter is running) or departure time/date (for locally generated packets) (commit)

 

----------

## Hu

 *libertytrek wrote:*   

> 
> 
> If you read my post, you'll see that it has nothing to do with bad rules...

 

For the purpose of loading iptables rules with iptables-restore, any rule that cannot be fully satisfied by the kernel is a "bad" rule.  If you have a rule that uses an extended match and that extended match is not available in the running kernel, the restore will fail.  By seeing the rules that you are trying to load, we may be able to identify any missing features.

It could also be instructive to take the Netfilter related sections of your working and non-working kernel configurations and compare them.  Obviously, any reorganization in the kernel code will cause a textual mismatch between the configurations, but it could still be helpful to check which values in the old configuration have no obvious counterpart in the new configuration.

----------

## libertytrek

 *baeksu wrote:*   

>  *Quote:*    *Quote:*   3. change into new kernel directory and do a 'make oldconfig' (normally all the old settings including iptalbes support will be set as the old config) 
> 
> You can safely do this between MINOR version bumps (ie, 2.6.23-r3 > 2.6.23-r9), but my understanding is you should NEVER use 'make oldconfig' when upgrading between MAJOR versions (ie, 2.6.23-r9 > 2.6.25-r7)...  
> 
> I don't think this is true. I've been using 'make oldconfig' since 2.6.17, and have never had any problems, nor have I heard of other people having problems.

 

Well, admittedly, I'm only saying that - and been doing it that way - because thats what the Genoo Linux Kernel Upgrade Guide says - specifically:

"It is sometimes possible to save time by re-using the configuration file from your old kernel when configuring the new one. Note that this is generally unsafe -- too many changes between every kernel release for this to be a reliable upgrade path."

Thats enough of a warning for me to believe that it is, in fact, 'generally unsafe'.

 *Quote:*   

> Even if 'make oldconfig' was unsafe between major versions, just copying the config and doing 'make menuconfig' is not going to be any better.

 

Again, the Gentoo Guide says otherwise - more from the above link:

"A much safer upgrading method is to copy your config as previously shown, and then simply run make menuconfig. This avoids the problems of make oldconfig mentioned previously, as make menuconfig will load up your previous configuration as much as possible into the menu."

If it is wrong, maybe it should be updated?

 *Quote:*   

> If you really are concerned about this, just enable all iptables/netfilter components as modules to ensure you have everything necessary.

 

Two problems with that...

1. this is a server, so no X, and no modules, I compile everything required by my system into the kernel, and

2. I really don't like the shotgun approach.

I don't feel it necessary to understand all of the details of every kernel option I enable, but I do like to know why I am enabling it, and I also like to not enable anything that is not necessary, if at all possible - hence my opening this thread...

 *Quote:*   

>  *Quote:*    *Quote:*   I believe the iptables rules are saved in /var/lib/iptables/rules-save. 
> 
> Maybe, but I saved them manually, and have tested a restore... again:
> 
> iptables works fine on the 2.6.23 kernel, but fails to start when booting from the 2.6.25 kernel.
> ...

 

Sure... here they are... but first understand, as I have said earlier, I don't really understand iptables, and I had help setting these up from a consultant, and there are a few things I'd like to change (like, for example, get it to stop logging all of the UDP/Windows DHCP and SMB traffic):

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*raw

:PREROUTING ACCEPT [222633286:130337506706]

:OUTPUT ACCEPT [186475744:266358392165]

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*nat

:PREROUTING ACCEPT [3310784:561609823]

:POSTROUTING ACCEPT [289167:19127565]

:OUTPUT ACCEPT [300907:21670186]

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*mangle

:PREROUTING ACCEPT [621778831:356231181731]

:INPUT ACCEPT [621741184:356222148032]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [510767123:743977057165]

:POSTROUTING ACCEPT [510654750:743968032926]

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*filter

:INPUT DROP [1492298:264275398]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [21460:2536934]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -p udp -m udp --dport 123 -j ACCEPT

-A INPUT -p udp -m udp --dport 138 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT

-A INPUT -s 127.0.0.1 -j ACCEPT

-A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

-A INPUT -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 587 -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 783 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT

-A OUTPUT -d 127.0.0.1 -j ACCEPT

-A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

 *Quote:*   

>  *Quote:*   but regardless, I've read enough to know that they did make major changes to the way iptables is configured.  
> 
> According to kernelnewbies.org, following were changed between .24 and .25:
> 
>  *Quote:*   #
> ...

 

Well, now I can't find where I read that... and it is entirely possible I misunderstood... so...

 *Quote:*   

> It could also be instructive to take the Netfilter related sections of your working and non-working kernel configurations and compare them. Obviously, any reorganization in the kernel code will cause a textual mismatch between the configurations, but it could still be helpful to check which values in the old configuration have no obvious counterpart in the new configuration.

 

Good idea... but I've never done that before. Is there an easy way to output just certain sections (I'm not much of a scripter) - easier than just scrolling through .config?

Thanks for your help, I think I'll learn something from this exercise...  :Smile: 

----------

## Hu

My first guess would be that you no longer have the raw table in your kernel.  Your rules are not making use of it, so you could remove the reference to it.  You need NETFILTER_XT_MATCH_STATE for your -m state match and IP_NF_TARGET_LOG for your -j LOG lines.  You can silence the unwanted Windows noise by adding rules to DROP that traffic before it reaches the rule that would LOG it.

----------

## libertytrek

 *Hu wrote:*   

> My first guess would be that you no longer have the raw table in your kernel.  Your rules are not making use of it, so you could remove the reference to it.

 

Ok, thanks...

I am not supposed to be doing any NAT translation either (this is not a router, the firewall is just to protect the server) - so can I remove the reference to *nat too?

 *Quote:*   

> You need NETFILTER_XT_MATCH_STATE for your -m state match and IP_NF_TARGET_LOG for your -j LOG lines.  You can silence the unwanted Windows noise by adding rules to DROP that traffic before it reaches the rule that would LOG it.

 

----------

## richard.scott

I never bothered learning IP tables since finding Shorewall.

```
# emerge -pv shorewall

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] net-firewall/shorewall-3.4.8  USE="-doc" 228 kB

Total: 1 package (1 reinstall), Size of downloads: 228 kB
```

It does it all for me   :Very Happy: 

----------

## Hu

 *libertytrek wrote:*   

> 
> 
> I am not supposed to be doing any NAT translation either (this is not a router, the firewall is just to protect the server) - so can I remove the reference to *nat too?

 

Yes, you can delete it from your saved rules.  However, doing so does not affect runtime performance, since it only skips setting the NAT table in the kernel.  You could compile the NAT table out of the kernel, though.

----------

## libertytrek

 *Quote:*   

>  *Quote:*   It could also be instructive to take the Netfilter related sections of your working and non-working kernel configurations and compare them. Obviously, any reorganization in the kernel code will cause a textual mismatch between the configurations, but it could still be helpful to check which values in the old configuration have no obvious counterpart in the new configuration. 
> 
> Good idea... but I've never done that before. Is there an easy way to output just certain sections (I'm not much of a scripter) - easier than just scrolling through .config?

 

Hi Hu...

Well, you're clusticks were enough for me to get this working... I copied over my old config and did make menuconfig, but for some reason iptables wasn't enabled... this isn't the first time I've missed it, so it was obviously my fault...

Sorry for the noise...

----------

