Am Mittwoch, den 14.09.2005, 09:09 +0200 schrieb Guido Tschakert:
> Hi,
>
> as you can see in your ifconfig, the mtu of the gif0 interface ist only
> 1280.
> The mtu of tun0 (i suppose it's your pppo[ea] interface has 1492 as mtu,
> but enc0 has 1500 as mtu. This means, that some packets have to be
> fragmented to get over the tunnel.
> What does tun1 do?
>
> There are two solutions. Use a mtu smaller then 1280 for your tun1
> interface or use pf to scrub your packets:
>
> For example, something like
>
> scrub in all no-df max-mss 1240 fragment reassemble
> scrub out all no-df max-mss 1240 fragment reassemble
>
> That works in my network for a similiar configuration.
>
> guido
>
>
Okey, i've tested the szenario with setting the mss to 1240 in pf.conf
After activating the new scrub-rules i realized that the gateways are
able to ping each other. Heurreka !
But after some particularly testing i realized that sometimes the
problem is one the client side (clients cant ping the remote
ipsec-bridge. The dump on the remote-box still displayed the "bad-hlen
0" message whereas the ipsecs-bridges are able to ping each other), or
it is still impossible that the briges cant ping each other. It gives me
the impression this issue only happened after an ip-change or after a
longer time without any traffic after the arp-caches from the clients
are flushed. In this situation the arp-request still passes the tunnel
but the bridge does't answer to this request. Is there an kernel-option
to force the bridge for arp-replies? The bridge-flag blocknonip is not
set for any interface.
Huh, sounds really incomprehensible, do you?
Okey i have experimanted whith the mtu-size of the gif0-interface. I set
it to 1240 but this didn't changed anything.
The mtu of enc0 is not changeable. It is fixed to 1536.
But changing mtu-sizes whithout any conception of the encapsulated
packet-model is not very usefull. ;-)
I know the mtu for tun0, which is connected to my isp, have to set to
1492 due to the pppoe-overhead. This is solved by my ppp-deamon. In
addition the tun1 interface is without relevance.
Ethernet uses 18 bytes and the ipv4-header is 20 byte long. There is
still an esp-header and what about the gif-iterface? Does it add
additional overhead?
My slightly dilettantish conception of this packet model looks like
this: (ipsec uses transport-mode)
+-----+-----+-----+------+-----+---------+
|ipv4 | esp | eth | ipv4 | tcp | payload |
+-----+-----+-----+------+-----+---------+
|-------------- 1492 --------------------|
|----------- 1472 -----------------|
|----------- ??? ------------|
|--------- ??? --------|
|----- ??? -----|
Does this make sense? Or can anybody give a little explanation.
Cheers, JC6rg.
