Packet size issue with direct UDP connections

[Etienne Dechamps]

I'm unable to reproduce. Are you using 802.1Q (VLANs) by any chance?

On 13 June 2015 at 00:15, Chris Clements <cclements at outlook.com> wrote:
> This makes it work for us:
>
>
>
> On Jun 12, 2015, at 5:02 PM, Chris Clements <cclements at outlook.com> wrote:
>
> This looks like the culprit:
>
> http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=7730d5f3ed9bd7c011dced5808130ffcbd74ea6b
>
>
> On Jun 12, 2015, at 3:51 PM, Chris Clements <cclements at outlook.com> wrote:
>
> Sure, I’ll see if we can narrow it down for you.
>
>
> On Jun 12, 2015, at 2:25 PM, Etienne Dechamps <etienne at edechamps.fr> wrote:
>
> 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 <cclements at outlook.com> 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
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
>
>
>