That's interesting. I'm using a near-HEAD tinc-1.1 myself and haven't encountered this problem, but I think that's because I'm using it in router mode, as opposed to switch mode.
I'm trying to narrow this down to a recent commit, but I can't find anything obvious. Did you have a working setup with a previous tinc-1.1 version? Do you have time to try a git bisect? On 11 June 2015 at 23:17, Chris Clements <[email protected]> wrote: > Have an interesting issue that's cropped up for us. We have a switch based > vpn setup with multiple endpoints, some publicly accessible, some behind hide > NAT. What we've noticed is that every machine can reach each other's VPN > IP's up to a certain packet size. All machines can successfully ping each > other up to 297 bytes. At 298 bytes and beyond, only "forwarded" connections > succeed. Specifically, a machine behind NAT connected directly to a public > machine via UDP cannot ping it with greater than 297 bytes. In this case > ICMP pings are an example, but we see the same behavior with other services. > > Doing packet dumps on the VPN interfaces, we see that the pings >297 from > direct connections do indeed arrive at the destination, but are dropped by > the destination tinc interface as "ethertype unknown". Again, forwarded > connections show no issues at all. If directly connected public endpoints > are reconfigured to instead forward through other endpoints, they exhibit no > issues with packet sizes. There are no errors reported related to this we > can identify at any debug level. > > Examining the differences between the 297 and 298 ping packets: > > Server (public) tinc mac addr: 72:49:ef:9b:99:b9 > vm (natted) tinc mac addr: 26:ae:0d:bb:12:01 > > Works: > server pinging the vm with 'ping -s 297 12.12.0.55' > -------------------------------------------------------------------- > vm mac | gw mac | start of ip header > 26ae 0dbb 1201 | 7249 ef9b 99b9 | 0800 4500 > > > Doesn't Work: > server pinging the vm with 'ping -s 298 12.12.0.55' > -------------------------------------------------------------------- > ? | vm mac | gw mac | start of ip header > 0024 | 26ae 0dbb 1201 | 7249 ef9b 99b9 | 0800 > ==================================================================== > > > So it appears that extra data "0024" is being pre-pended to packets larger > than 297 bytes and this offset is why the kernel drops it as an unknown > ethertype. > > > Any thoughts on this? We are using tinc version 1.1pre11-143-gbfe231b at all > points. We can share more config info if it would be helpful. We will only > have access to this env for another week if there are any troubleshooting > suggestions. > > > Chris > > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
