Hi Clemens,
Sry this should have been gone to the Batman list, so here it is again:
I did this and everything works fine till I try to connect over the vpn. So the vpn is the problem I think.
Here is some output of what I tried connecting over vpn:
[floh1111@flohdesktop ~]$ ping -M do -s 1467 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1467(1495) bytes of data. 1475 bytes from 10.18.1.1: icmp_seq=1 ttl=64 time=85.6 ms
--> Works fine till package size 1467 or lower
[floh1111@flohdesktop ~]$ ping -M do -s 1468 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1468(1496) bytes of data.
--> Does not work with package size from 1468 to 1472, no error message
[floh1111@flohdesktop ~]$ ping -M do -s 1473 10.18.1.1 PING 10.18.1.1 (10.18.1.1) 1473(1501) bytes of data. From 10.18.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1500) --> Does not work too, but I get an error message trying package size 1473 or higher.
We are using OpenVPN in tap mode. Below is our server config:
mode server tls-server
port 1195 proto udp dev tap ca /etc/openvpn/ff/ca.crt cert /etc/openvpn/ff/ffsrv.crt key /etc/openvpn/ff/ffsrv.key # This file should be kept secret dh /etc/openvpn/dh1024.pem client-config-dir ccd client-to-client keepalive 10 120 comp-lzo max-clients 100 persist-key persist-tun status openvpn-status.log verb 3
I don´t know if openvpn is adding some extra headers but maybe you know?
Yep, tap mode in openvpn is adding an extra header, it encapsulates not only the ip-packet but also the ethernet frame into udp or tcp. (By the way, tun-mode also adds an extra header, but the packets are smaller - only IP packets encapsulated in UDP or TCP.)
May I ask whether you are bridging tap0 or if you are routing the packets (so having an ip address on tap0 and having according entries in your routing table)? If it's the latter, then you could just decrease the MTU on the tap0 interfaces to a fitting size and let the VPN routers do the PMTU discovery stuff automatically. But of course, then you probably wouldn't need tap-mode in this scenario, as it just adds additional overhead with the unnecessary ethernet frame in between.
I know that tinc has two little, a bit hacky features in case of bridging tap0 with tap-mode (they call it switch-mode) to inform the other machines of the lower MTU in between. But I haven't heard of OpenVPN having similar features.
So I guess the easiest step would be the first suggestion, to do routing in between and lowering the MTU on the tap interfaces for a start before starting to experiment with (experimental) features and/or more complicated setups :).
Cheers, Linus
Thanks Clemens