ipchains blocking port 65535

ipchains blocking port 65535

[Jussi Hamalainen]

There seems to be a bug in ipchains. Matching port 65535 seems to
always fail. If I set the chain policy to REJECT or DENY and then
add a rule that accepts TCP to/from ports 0:65535, packets going to
port 65535 will still be caught by the kernel. Is there a fix for
this? It's driving me nuts. The firewall box is a 486 with 3 NICs and
is running kernel 2.2.18 vanilla.

Here is a piece of the kernel log:

Jan 17 15:13:03 galileo kernel: Packet log: forward REJECT eth0
PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
I=16815 F=0x00B6 T=56 (#25)
Jan 17 15:15:03 galileo kernel: Packet log: forward REJECT eth0
PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
I=19969 F=0x00B6 T=56 (#25)
Jan 17 15:17:03 galileo kernel: Packet log: forward REJECT eth0
PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
I=21869 F=0x00B6 T=56 (#25)

And here a piece of my forward chain:

ACCEPT     tcp  ------  anywhere              myhomenet/27
any ->   1024:65535
ACCEPT     udp  ------  anywhere              myhomenet/27
any ->   1024:65535

-- 
-=[ Count Zero / TBH - Jussi Hämäläinen - email count@theblah.org ]=-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: ipchains blocking port 65535

[Tony Gale]

It looks like this is due to the odd way in which ipchains handles
fragments. Try:

echo 1 > /proc/sys/net/ipv4/ip_always_defrag

-tony


On 17-Jan-2001 Jussi Hamalainen wrote:
> There seems to be a bug in ipchains. Matching port 65535 seems to
> always fail. If I set the chain policy to REJECT or DENY and then
> add a rule that accepts TCP to/from ports 0:65535, packets going to
> port 65535 will still be caught by the kernel. Is there a fix for
> this? It's driving me nuts. The firewall box is a 486 with 3 NICs
> and
> is running kernel 2.2.18 vanilla.
> 
> Here is a piece of the kernel log:
> 
> Jan 17 15:13:03 galileo kernel: Packet log: forward REJECT eth0
> PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
> I=16815 F=0x00B6 T=56 (#25)
> Jan 17 15:15:03 galileo kernel: Packet log: forward REJECT eth0
> PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
> I=19969 F=0x00B6 T=56 (#25)
> Jan 17 15:17:03 galileo kernel: Packet log: forward REJECT eth0
> PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00
> I=21869 F=0x00B6 T=56 (#25)
> 
> And here a piece of my forward chain:
> 
> ACCEPT     tcp  ------  anywhere              myhomenet/27
> any ->   1024:65535
> ACCEPT     udp  ------  anywhere              myhomenet/27
> any ->   1024:65535
> 
> -- 
> -=[ Count Zero / TBH - Jussi Hämäläinen - email count@theblah.org
> ]=-
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Never trust anybody whose arm is bigger than your leg.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: ipchains blocking port 65535

[Jussi Hamalainen]

On Wed, 17 Jan 2001, Tony Gale wrote:

> It looks like this is due to the odd way in which ipchains handles
> fragments. Try:
>
> echo 1 > /proc/sys/net/ipv4/ip_always_defrag

Thanks, this seems to do the trick. Does this oddity still exist
in 2.4?

-- 
-=[ Count Zero / TBH - Jussi Hämäläinen - email count@theblah.org ]=-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

IP defrag (was RE: ipchains blocking port 65535)

[Tony Gale]

On 17-Jan-2001 Jussi Hamalainen wrote:
> On Wed, 17 Jan 2001, Tony Gale wrote:
> 
>> It looks like this is due to the odd way in which ipchains handles
>> fragments. Try:
>>
>> echo 1 > /proc/sys/net/ipv4/ip_always_defrag
> 
> Thanks, this seems to do the trick. Does this oddity still exist
> in 2.4?
> 

Well, I haven't found it, but there is
/proc/sys/net/ipv4/ipfrag_high_thresh
/proc/sys/net/ipv4/ipfrag_low_thresh
/proc/sys/net/ipv4/ipfrag_time

Perhaps 2.4 always defrags packets by default. Anyone confirm? This
is pretty much needed for any kind of firewall/masquerading system.

-tony



---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
The great merit of society is to make one appreciate solitude.
		-- Charles Chincholles, "Reflections on the Art of Life"

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IP defrag (was RE: ipchains blocking port 65535)

[Andi Kleen]

On Wed, Jan 17, 2001 at 05:15:54PM -0000, Tony Gale wrote:
> 
> On 17-Jan-2001 Jussi Hamalainen wrote:
> > On Wed, 17 Jan 2001, Tony Gale wrote:
> > 
> >> It looks like this is due to the odd way in which ipchains handles
> >> fragments. Try:
> >>
> >> echo 1 > /proc/sys/net/ipv4/ip_always_defrag
> > 
> > Thanks, this seems to do the trick. Does this oddity still exist
> > in 2.4?
> > 
> 
> Well, I haven't found it, but there is
> /proc/sys/net/ipv4/ipfrag_high_thresh
> /proc/sys/net/ipv4/ipfrag_low_thresh
> /proc/sys/net/ipv4/ipfrag_time
> 
> Perhaps 2.4 always defrags packets by default. Anyone confirm? This
> is pretty much needed for any kind of firewall/masquerading system.

Connection tracking always defrags as needed. masquerading/NAT/iptables 
with connection tracking uses that.

This means that if any of these are enabled and your machine acts as a 
router lots of CPU could get burned in defragmentation, and packets
will not forwarded until all fragments arrived.

All very nasty, but unfortunately there is no alternative.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IP defrag (was RE: ipchains blocking port 65535)

[Tony Gale]

On 17-Jan-2001 Andi Kleen wrote:
> 
> Connection tracking always defrags as needed.
> masquerading/NAT/iptables 
> with connection tracking uses that.
> 
> This means that if any of these are enabled and your machine acts
> as a 
> router lots of CPU could get burned in defragmentation, and packets
> will not forwarded until all fragments arrived.

Hmm... ok, what if I'm on a single nic system using ipchains on the
input and want to always defrag before they hit the ipchains
filter, what settings would I need? No masq., no NAT. (bearing in
mind that ipchains differentiates between SYN+frag and noSYN+frag.

> 
> All very nasty, but unfortunately there is no alternative.
> 

Nasty but necessary. Such is life.

-tony


---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Isn't it nice that people who prefer Los Angeles to San Francisco live there?
		-- Herb Caen

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: IP defrag (was RE: ipchains blocking port 65535)

[Andi Kleen]

On Wed, Jan 17, 2001 at 05:44:30PM -0000, Tony Gale wrote:
> 
> On 17-Jan-2001 Andi Kleen wrote:
> > 
> > Connection tracking always defrags as needed.
> > masquerading/NAT/iptables 
> > with connection tracking uses that.
> > 
> > This means that if any of these are enabled and your machine acts
> > as a 
> > router lots of CPU could get burned in defragmentation, and packets
> > will not forwarded until all fragments arrived.
> 
> Hmm... ok, what if I'm on a single nic system using ipchains on the
> input and want to always defrag before they hit the ipchains
> filter, what settings would I need? No masq., no NAT. (bearing in
> mind that ipchains differentiates between SYN+frag and noSYN+frag.

You probably need to just load ip_conntrack_standalone and make sure it runs.
It has a higher priority than ipchains in the prerouting chain and should just defragment 
things. 

Better would it be to just write a small netfilter module with a higher
priority than ipchains that always defrags. 

Actually I thought I've once seen such a beast, but it doesn't seem to
be included in the main kernel now that I look for it.  It's all only a few 
lines of code anyways.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/