Ugly problem with ebtables

Ugly problem with ebtables

[Juan Antonio Rodriguez Moreno]

Hello,

excuse me about my bad english, I'll try to explain my ugly issue

I have a linux bridged machine, with eth1 and eth2 port on br0. I'm using
ebtables to up smtp traffic on routing process and iptables to mark it. I
route this traffic over openvpn tunnel tun0.

That's all right but when IP fragment a packet and send the former frame
without the PUSH flag, this frame dissapear.
I can see all traffic on the sending point of the tunel, but the frames
without the PUSH flag set don't arrive on the another side.

For example I send a mail and this is the trace

On client  #ngrep -d tun0 host 192.168.11.150 and port 25

... Traffic ....

T xxx.xxx.xxx.xxx:25 -> 192.168.11.150:2286 [AP]
  354 End data with <CR><LF>.<CR><LF>..

192.168.11.150:2286 -> xxx.xxx.xxx.xxx:25 [A]
From: "copperpot" <copperpot@xxxx.com>..To:
<jrodriguez@xxxx.com>..Subject: Prueba de correo..Date: Mon, 27 Apr 2009
11:24:21 +0200..Message-ID: <006e01c9c719$f37dfd80$da79f880$@com> [ ...
Continue .....]

T 192.168.11.150:2286 -> xxx.xxx.xxx.xxx:25 [AP]
...font-size:11.0pt;...font-family:"Calibri","sans-serif";}..a:link,
span.MsoHyperlink...{mso-style-priority:99;...color:blue; [ .... continue
.....]

... Traffic ....

On server side  #ngrep -d tun1 host 192.168.11.150 and port 25

... Traffic ....

T xxx.xxx.xxx.xxx:25 -> 192.168.11.150:2258 [AP]
  354 End data with <CR><LF>.<CR><LF>..

T 192.168.11.150:2258 -> xxx..xxx.xxx.xxx:25 [AP]
  ...font-size:11.0pt;...font-family:"Calibri","sans-serif";}..a:link [
...Coninue ... ]

... Traffic ...

Like will see the frame

192.168.11.150:2286 -> xxx.xxx.xxx.xxx:25 [A]
From: "copperpot" <copperpot@xxxx.com>..To: <jrodriguez@xxxx.com>..Subject:

dissapear so the mail proccess fail.

Thank you very much.

Re: Ugly problem with ebtables

[Pascal Hambourg]

Hello,

Juan Antonio Rodriguez Moreno a écrit :
> 
> I have a linux bridged machine, with eth1 and eth2 port on br0. I'm using
> ebtables to up smtp traffic on routing process and iptables to mark it. I
> route this traffic over openvpn tunnel tun0.
> 
> That's all right but when IP fragment a packet and send the former frame
> without the PUSH flag, this frame dissapear.

What your traces shows below is not IP fragmentation (which has nothing 
to do with PUSH which is a TCP flag) but TCP segmentation.

> I can see all traffic on the sending point of the tunel, but the frames
> without the PUSH flag set don't arrive on the another side.

IIUC, some packets enter the bridge, are routed through the tunnel and 
don't arrive at the other end. What makes you think that ebtables is 
involved ?

Couldn't it be an MTU problem in the tunnel ? AFAIK, when TCP transmits 
a message which must be segmented, it sends maximum-size segments 
without the PUSH flag and a last smaller segment with the PUSH flag set 
containing the remaining data.

Re: Ugly problem with ebtables

[Juan Antonio]

> Hello,

Hello and thanks for your reply,

>
> Juan Antonio Rodriguez Moreno a écrit :
>>
>> I have a linux bridged machine, with eth1 and eth2 port on br0. I'm
>> using
>> ebtables to up smtp traffic on routing process and iptables to mark it.
>> I
>> route this traffic over openvpn tunnel tun0.
>>
>> That's all right but when IP fragment a packet and send the former frame
>> without the PUSH flag, this frame dissapear.
>
> What your traces shows below is not IP fragmentation (which has nothing
> to do with PUSH which is a TCP flag) but TCP segmentation.

Ok. excuses the mistake.

>> I can see all traffic on the sending point of the tunel, but the frames
>> without the PUSH flag set don't arrive on the another side.
>
> IIUC, some packets enter the bridge, are routed through the tunnel and
> don't arrive at the other end. What makes you think that ebtables is
> involved ?

I was not sure wherefrom the issue was, I should have been a bit more
careful to explain the problem.

> Couldn't it be an MTU problem in the tunnel ? AFAIK, when TCP transmits
> a message which must be segmented, it sends maximum-size segments
> without the PUSH flag and a last smaller segment with the PUSH flag set
> containing the remaining data.

I know that, really this is the problem. The first segments without the
PUSH flag dissapear completely in spite of these go out for the tunnel .
The MTU is the first thing that I verified and this is 1500 in both sides.

I'm so confuse becouse the same config is in another linux box with the
same config, same version for all packages, etc ..  and this works really
good.

I have been looking for some sysctl value in /proc/sys/net/ipv4 related
but I can see anything about this.

Thank you.

> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Ugly problem with ebtables

[Pascal Hambourg]

Juan Antonio a écrit :
> 
>> Couldn't it be an MTU problem in the tunnel ? AFAIK, when TCP transmits
>> a message which must be segmented, it sends maximum-size segments
>> without the PUSH flag and a last smaller segment with the PUSH flag set
>> containing the remaining data.
> 
> I know that, really this is the problem. The first segments without the
> PUSH flag dissapear completely in spite of these go out for the tunnel .
> The MTU is the first thing that I verified and this is 1500 in both sides.

Did you check that the tunnel can actually handle packets of that size, 
for example by sending pings of various sizes up to 1500 through it ?
Tunnel encapsulation adds overhead, which might create fragmentation or 
other issues.

Re: Ugly problem with ebtables

[Juan Antonio]

> Juan Antonio a écrit :
>>
>>> Couldn't it be an MTU problem in the tunnel ? AFAIK, when TCP transmits
>>> a message which must be segmented, it sends maximum-size segments
>>> without the PUSH flag and a last smaller segment with the PUSH flag set
>>> containing the remaining data.
>>
>> I know that, really this is the problem. The first segments without the
>> PUSH flag dissapear completely in spite of these go out for the tunnel .
>> The MTU is the first thing that I verified and this is 1500 in both
>> sides.
>
> Did you check that the tunnel can actually handle packets of that size,
> for example by sending pings of various sizes up to 1500 through it ?
> Tunnel encapsulation adds overhead, which might create fragmentation or
> other issues.

Hello,

I can send pings to exactly 1370 bytes, and over 1440 bytes but I can't
ping between this interval.

ping 10.8.1.1 -c 1 -s 1450
PING 10.8.1.1 (10.8.1.1) 1450(1478) bytes of data.
1458 bytes from 10.8.1.1: icmp_seq=1 ttl=64 time=61.1 ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms

ping 10.8.1.1 -c 1 -s 1440
PING 10.8.1.1 (10.8.1.1) 1440(1468) bytes of data.
1 packets transmitted, 0 received, 100% packet loss, time 0ms

However the MTU is 1500 in both sides and I can send ping without problem
in this size.

ping 10.8.1.1 -c 1 -s 1500
PING 10.8.1.1 (10.8.1.1) 1500(1528) bytes of data.
1508 bytes from 10.8.1.1: icmp_seq=1 ttl=64 time=60.7 ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Now I'm really lost, I'll look for some parameter in openvpn config.

Thank you very much


> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>