nat problem: What's so special with traffic from audibank.de?

nat problem: What's so special with traffic from audibank.de?

[Lars Täuber]

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

Hi there.

Since some years I have experience with the firewall systems inside linux.
But now I have a case where I don't know how to debug this.

I exchanged my hand written firewall rules with rules generated from fwbuilder 3.0.5. The kernel used is the one from ubuntu 8.04 (2.6.24-25-server).

$ iptables -V
iptables v1.3.8

Maybe it's an already known bug in iptables from this old kernel?

All http(s) traffic works exept the one from audibank.de. The start side doesn't show up when called from a computer on the natted side of the local network. When called from the computer doing the firewall/nat it just works.

The phenomenon on a natted computer:

============================== snip ========================
$ LANG=C wget -d audibank.de
DEBUG output created by Wget 1.11.4 on linux-gnu.
[...]
---request end---
HTTP request sent, awaiting response...
============================== snip ========================

All other online banking sides just work.

Here are (hapefully all) the relevant rules that are generated from fwbuilder (using iptables-restore):

echo :INPUT DROP   [0:0]
echo :FORWARD DROP [0:0]
echo :OUTPUT DROP  [0:0]
echo "-A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT"
echo "-A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT"
echo "-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT"

echo "-A OUTPUT   -m state --state INVALID  -j DROP"
echo "-A INPUT    -m state --state INVALID  -j DROP"
echo "-A FORWARD  -m state --state INVALID  -j DROP"

echo ":In_RULE_0 - [0:0]"
echo "-A INPUT    -i ppp0  -s 192.168.4.0/24  -m state --state NEW  -j In_RULE_0 "
echo "-A FORWARD  -i ppp0  -s 192.168.4.0/24  -m state --state NEW  -j In_RULE_0 "
echo "-A In_RULE_0  -j DROP "

echo "-A OUTPUT  -o ppp0 -p tcp -m tcp  -m multiport  --dports 53,80,443,22  -m state --state NEW  -j ACCEPT "
echo "-A OUTPUT  -o ppp0 -p udp -m udp  --dport 53  -m state --state NEW  -j ACCEPT "

echo "-A INPUT    -s 192.168.4.0/24  -m state --state NEW  -j ACCEPT "
echo "-A OUTPUT   -s 192.168.4.0/24  -m state --state NEW  -j ACCEPT "
echo "-A FORWARD  -s 192.168.4.0/24  -m state --state NEW  -j ACCEPT "

echo "-A POSTROUTING -o ppp0  -s 192.168.4.0/24 -j MASQUERADE  "

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




Attached is the tcpdump of the http traffic related to audibank.de

What's wrong? Can someone enlighten me please?
Best regards.
Lars

[-- Attachment #2: ppp1.dump --]
[-- Type: application/octet-stream, Size: 2857 bytes --]

Re: nat problem: What's so special with traffic from audibank.de?

[Mattias Rönnblom]

Lars Täuber <lars.taeuber@gmx.net> writes:

> Hi there.
>
> Since some years I have experience with the firewall systems inside linux.
> But now I have a case where I don't know how to debug this.
>
> I exchanged my hand written firewall rules with rules generated from fwbuilder 3.0.5. The kernel used is the one from ubuntu 8.04 (2.6.24-25-server).
>
> $ iptables -V
> iptables v1.3.8
>
> Maybe it's an already known bug in iptables from this old kernel?
>
> All http(s) traffic works exept the one from audibank.de. The start side doesn't show up when called from a computer on the natted side of the local network. When called from the computer doing the firewall/nat it just works.
>>

/../

> Attached is the tcpdump of the http traffic related to audibank.de
>
> What's wrong? Can someone enlighten me please?
>

I'll do some guessing here. It looks like the first large (MSS-sized)
segment is lost. I've seen this happening in networks where Path MTU
Discovery didn't work (because ICMP Fragmentation Needed was
filtered).

What I would try is to "clamp" the advertised MSS for upstream TCP
segments to something low (like 300 bytes), to see if that solves your
problem. See iptables(8) for details on how to do that.

(Low MSS will increase protocol overhead, so you probably don't want
to clamp MMSes for all outgoing traffic.)

Best regards,
     Mattias

Re: nat problem: What's so special with traffic from audibank.de?

[Lars Täuber]

Hi Mattias,

On Thu, 03 Dec 2009 23:22:47 +0100 Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> I'll do some guessing here. It looks like the first large (MSS-sized)
> segment is lost. I've seen this happening in networks where Path MTU
> Discovery didn't work (because ICMP Fragmentation Needed was
> filtered).

you're absolutely right.
I could solve my problem with either allow any icmp traffic from outside to any destination or use the clamp-to-pmtu in the server settings for the firewall. This is a switch in fwbuilder.

Why is such an ICMP message not RELATED in the meaning of
   echo "-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT"
with a _related_ tcp connection?

Thanks a lot anyway!!
Lars

Re: nat problem: What's so special with traffic from audibank.de?

[Patrick McHardy]

Lars Täuber wrote:
> Hi Mattias,
> 
> On Thu, 03 Dec 2009 23:22:47 +0100 Mattias Rönnblom <hofors@lysator.liu.se> wrote:
>> I'll do some guessing here. It looks like the first large (MSS-sized)
>> segment is lost. I've seen this happening in networks where Path MTU
>> Discovery didn't work (because ICMP Fragmentation Needed was
>> filtered).
> 
> you're absolutely right.
> I could solve my problem with either allow any icmp traffic from outside to any destination or use the clamp-to-pmtu in the server settings for the firewall. This is a switch in fwbuilder.
> 
> Why is such an ICMP message not RELATED in the meaning of
>    echo "-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT"
> with a _related_ tcp connection?

It should be. Please post a dump of the relevant ICMP message
and the connection tuples from /proc/net/nf_conntrack for the
original TCP connection.

Re: nat problem: What's so special with traffic from audibank.de?

[Lars Täuber]

Hallo Patrick,

On Fri, 04 Dec 2009 07:14:44 +0100 Patrick McHardy <kaber@trash.net> wrote:
> > I could solve my problem with either allow any icmp traffic from outside to any destination or use the clamp-to-pmtu in the server settings for the firewall. This is a switch in fwbuilder.

sorry i was wrong.
At first i tried the »clamp-to-pmtu« setting and it worked. After removing this setting and inserting a gloabl rule to accept every icmp traffic it still worked.
But I didn't realized that this global rule had no effect at all.


> > 
> > Why is such an ICMP message not RELATED in the meaning of
> >    echo "-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT"
> > with a _related_ tcp connection?
> 
> It should be. Please post a dump of the relevant ICMP message
> and the connection tuples from /proc/net/nf_conntrack for the
> original TCP connection.

No such icmp message ever reached my firewall though I tryed hard to record such an icmp message. My guess is that it must have been filtered out on the way.
The clamp-to-pmtu seemed to have a lasting success.

What I'm wondering is why it just works on the firewall itself but not with the natted computers in the private network?

Sorry for replying so late.
Lars

Re: nat problem: What's so special with traffic from audibank.de?

[Lars Täuber]

On Sat, 5 Dec 2009 23:19:11 +0100 Lars Täuber <lars.taeuber@gmx.net> wrote:
> No such icmp message ever reached my firewall though I tryed hard to record such an icmp message. My guess is that it must have been filtered out on the way.

Or am I doing something wrong trying to record such a message? My command line:
tcpdump -i ppp0 -w /tmp/icmp2.dump icmp

Lars