Ipv6 mtu problem with microsoft skype for business/lync

dopey

I haven't been able to connect to skype for business/lync from my home network (using pfsense and 6rd for ipv6).

I did a bunch of research and digging and I'm fairly certain it's an mtu thing. pfsense appears to default the wan_stf interface to an mtu of 1280.

If I drop my clients (linux using skype for business outlook web integration, or mac os running native skype for linux client) to 1280 mtu, everything works.

I can't figure out if it's possible to do this for just ipv6.

Any thoughts on what I would want to tweak to make this work?

Any ideas why this would fail for just skype/lync?

I tested using ping from the clients and icmpv6 packet too big messages arriving, but i guess they aren't being handled properly?

JKnott

Setting the MTU affects both IPv4 & IPv6, as it indicates how much data can be placed in an Ethernet frame. As to why the problem is happening, when in doubt fire up Wireshark, to see what's happening. If you don't know what's happening on the wire, it's a lot harder to figure out what's wrong.

BTW, is Skype now using IPv6? Last I heard they were IPv4 only, but that may have changed with the new client software and web interface.

dopey

@JKnott:

Setting the MTU affects both IPv4 & IPv6, as it indicates how much data can be placed in an Ethernet frame. As to why the problem is happening, when in doubt fire up Wireshark, to see what's happening. If you don't know what's happening on the wire, it's a lot harder to figure out what's wrong.

BTW, is Skype now using IPv6? Last I heard they were IPv4 only, but that may have changed with the new client software and web interface.

Apparently they are supporting ipv6 now and have been for a while.
I did look at it in wireshark (using tcpdump for easier pasting below) and it appears that something is dropping packets on the way back in. This is the response to
'curl -k https://[2603:1037:0:1::e]`
I picked one of the ip addresses out of the list for easier filtering in tcpdump.


13:32:19.804942 IP6 <client> > 2603:1037:0:1::e.https: Flags [s], seq 582944132, win 28800, options [mss 1440,sackOK,TS val 3544364196 ecr 0,nop,wscale 7], length 0
13:32:19.844226 IP6 2603:1037:0:1::e.https > <client>: Flags [S.], seq 839382002, ack 582944133, win 8192, options [mss 1440,nop,wscale 8,sackOK,TS val 187720794 ecr 3544364196], length 0
13:32:19.844346 IP6 <client> > 2603:1037:0:1::e.https: Flags [.], ack 1, win 225, options [nop,nop,TS val 3544364235 ecr 187720794], length 0
13:32:19.878353 IP6 <client> > 2603:1037:0:1::e.https: Flags [P.], seq 1:518, ack 1, win 225, options [nop,nop,TS val 3544364269 ecr 187720794], length 517
13:32:19.920098 IP6 2603:1037:0:1::e.https > <client>: Flags [P.], seq 2857:3693, ack 518, win 256, options [nop,nop,TS val 187720800 ecr 3544364269], length 836
13:32:19.920163 IP6 <client> > 2603:1037:0:1::e.https: Flags [.], ack 1, win 239, options [nop,nop,TS val 3544364311 ecr 187720794,nop,nop,sack 1 {2857:3693}], length 0
13:32:38.979644 IP6 2603:1037:0:1::e.https > <client>: Flags [R.], seq 1429, ack 518, win 0, length 0

When I drop the mtu to 1472 (or lower)  the response packet is correct:
[code]13:37:20.770174 IP6 <client> > 2603:1037:0:1::e.https: Flags [P.], seq 1:518, ack 1, win 221, options [nop,nop,TS val 3544665160 ecr 192011522], length 517
13:37:20.814529 IP6 2603:1037:0:1::e.https > <client>: Flags [P.], seq 1:3693, ack 518, win 257, options [nop,nop,TS val 192011529 ecr 3544665160], length 3692
[/code]

I initially thought the problem was that I was sending too large packets, but looking at the wireshark it seems like they are and not handling it?
Maybe I don't understand something but how does my MTU impact their sending behavior?

or am I misinterpreting the data?[/s]</client></client></client></client></client></client></client></client></client>

dopey

Oh, in my googling I came across this:
http://seclists.org/nanog/2017/Mar/231

and this
https://social.technet.microsoft.com/Forums/windowsserver/en-US/6dc19f5d-123e-4b35-8687-a7585df38738/ipv6-and-meetlynccom-doesnt-seem-to-work?forum=olmcjm

That seem to be related to my issue.

JKnott

Maybe I don't understand something but how does my MTU impact their sending behavior?

Your MTU also affects how large of packet you can receive. With TCP, the 2 ends exchange the Maximum Segment Size (MSS) which is determined by the MTU. This allows the 2 ends to agree on a size that both can handle. However, it appears Skype might be ignoring that.

dopey

Huh. I thought that mss/mtu was only relevant between hops and, especially with ipv6, that path mtu discovery should be used.

Still, yeah either way it looks like MS' end is broken. Even if they aren't acknowledging a "negotiated" mtu/mss, they should be handling an icmpv6 packet too big response shouldn't they?

yay for big nebulous enterprise solutions. Microsoft doesn't provide end-user support for their lync/skype for business service, and my company's IT response is "we don't support ipv6 so stop using it".

JKnott

MSS is used to set the packet size at the ends only. It doesn't know what intermediate hops can support. If intermediate hops can't support the packet size, then an ICMP too big message is sent, which the source should respond to.

dopey

Huh. I'm definitely a little confused here. I just set my client (macos) to an mtu of 1480 and it works. That seems to be the cut-off point. Anything higher than 1480 doesn't work.

I understand the significance of 1480 for 6rd but i wonder why that makes a difference? Isn't that just to prevent the ipv4 fragmentation? That's still feasible with 6rd isn't it? Not ideal but should function right?

JKnott

1480 or 1280? 1280 is commonly used for MTU on tunnels such as 6rd. I don't know what the reason for that is, though the IPv6 MTU must allow for the IPv4 header within whatever the LAN MTU is.

dopey

wan_stf on pfsense has mtu set to 1280.
But in order for skype/lync to work I just have to set the interface mtu to no higher than 1480 (checked with mac os and linux):
2: wlp58s0: <broadcast,multicast,up,lower_up>mtu 1480 qdisc mq state UP mode DORMANT group default qlen 1000

i was under the impression the reason for 1480 (1472 if you're using pppoe) is for the 1500byte packet to handle the 20 ipv4 headers and the 8 byte ppp headers.
So I'm really confused why 1480 works (centurylink uses pppoe and 6rd, so i was expecting 1472 to work). If wan_stf is only 1280, it would seem that even 1480 would still be aproblem right?

The wireshark capture (From the mac) shows a 1494 length ethernet frame and 1440 IP frame for the successful response from webdir.online.lync.com. I couldn't figure out how to disable tso with the ath10k wireless device on my linux laptop.</broadcast,multicast,up,lower_up>

JKnott

Setting the interface MTU to 1500 will result in a 1480 maximum IPv6 packet size, after allowing 20 bytes for IPv4, because the IPv6 packet is just data to IPv4. Regardless, for some reason tunnels are often set to the minimum IPv6 MTU of 1280, as was the case with the tunnel I used to use. I don't know what 6rd uses though. What's the tunnel MTU?

dopey

@JKnott:

I don't know what 6rd uses though. What's the tunnel MTU?

I don't know. How do I tell?
I coudl only tell that the wan_stf interface has an mtu of 1280. Not sure what other mtu there is.

JKnott

@dopey:

@JKnott:

I don't know what 6rd uses though. What's the tunnel MTU?

I don't know. How do I tell?
I coudl only tell that the wan_stf interface has an mtu of 1280. Not sure what other mtu there is.

Is that wan_stf your 6rd tunnel? I haven't used a tunnel with pfSense, so I don't know what to look for there. Netstat -r should show the prefix, but I see it's truncated when displayed. I'll have to figure out how to see the entire line.

dopey

https://www.freebsd.org/cgi/man.cgi?query=stf

Looks like the stf interface is the tunnel interface, and
https://redmine.pfsense.org/issues/6377

It appears to be hardcoded for 1280
the default gateway for Internet6 is out the wan_stf interface.

But back to my point, the purpose of setting a lower MTU for ipv6 in a tunnel enviroment is to ensure that the encapsulation doesn't result in ipv4 packet fragmentation. So in proper settings, the actual internal ipv6 mtu shouldn't matter, and since the 1280 is being enforced my the ipv6 tunnel, my guess is if I tried to send a larger packet than 1280 (tested with ping) i get an icmpv6 packet too big response that would normally be handled. So on my transmit side, everything works fine.
But on my receive side something microsoft is transmitting too, between them and my network has a lower mtu than 1500, and they aren't properly handling packet too big, likely causing the problem right?

The reason why setting my mtu lower makes this work is because it negotiates an initially smaller transmit size on the MS end that doesn't appear to run into a packet too big problem on the network? Maybe they have a 6to4 tunnel in between somewhere :)

dopey

Let's see if I get any traction with this post:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_mac-mso_o365b/skype-for-businesslync-services-dont-appear-to/c204b511-8b0b-4338-924e-729603627413