Re: [Openvpn-users] Tun interface and mtu issues

[Nikita K. <kos...@gm...>]

On Tue, 31 Aug 2010 14:35:31 +0200
Jan Just Keijser wrote:

> Hi Nikita,
> 
> Nikita Koshikov wrote:
> > On Sun, 29 Aug 2010 12:04:34 +0100
> > Timothy Baldwin wrote:
> >
> > Thanks for reply, Timothy
> >
> >   
> >> In message <20100828222407.388b1242@jimbo>, Nikita Koshikov 
> >> <kos...@gm...> wrote:
> >>
> >>     
> >>> Setup:
> >>>
> >>> openvpn-client	-->	openvpn-server	-->	local-net
> >>> tun0(mtu 1500)		tun0(mtu 1300)		eth0(mtu1500)
> >>> eth0(mtu 1500)
> >>>
> >>> I set mtu manually on openvpn server by 'ip link set tun0 mtu 1300'.
> >>>       
> >> MTU = Maximum Transmission Unit
> >>
> >>     
> >>> Then I'm trying to ping machines from openvpn-client to local-net with
> >>> command:
> >>>       
> >>> ping -M do -s 1400 192.168.1.1
> >>> ^^
> >>> DF bit is on!
> >>> And I still got fragmented replies. However, I must got icmp(Frag needed
> >>> and DF set).
> >>>       
> >> It's working as it should, your ICMP echo request packets are not being 
> >> affected by the MTU setting on tun0 on openvpn-server, as they are not being 
> >> transmitted on that interface, they are received on it.
> >>
> >>     
> >
> > Quick testing on ethernet environment:
> >
> > Client	-->	Server
> > eth0		eth0
> > mtu 1500	mtu 1300
> >
> > Pings with packet size 1400. From client machines packets sending, but they don't appear on destination wire. I use tcpdump to check this.
> > Also, I have tried with 2 real servers, different OS-es - both behave the same(packets not appear) and with one virtual machine - it acts  like openvpn-server in 1 post(1 echo request and 2 fragmented replies). Between client and server few 3Com switches. Can someone test such scheme on your side ?
> >
> >   
> a 'tun' device is not the same as a 'tap' device ; if you change your 
> openvpn setup to use 'tap' then you will see the same behaviour as for 
> 'eth' . A 'tap' device is the equivalent of an ethernet adapter and is 
> treated as such by the kernel. This means that packets are larger than 
> the MTU are simply not accepted.
> 
Not sure if you got my respond, but I tried both tun and tap drivers - and they both acts the same. To be clear - tap also receives packets > mtu, opposite real ethernet cards - they drop packets > mtu and frames even don't appear in tcpdump output.

> The 'tun' device is different in that it can *receive* packets which are 
> larger than the MTU but it cannot send them. This is similar to the 
> 'ppp' device, for which you can specify an MRU and an MTU . There's no 
> such thing as an 'mru' for the tun device, however.
> 
> Hope this clears things up,

Thanks for pointing this out.