Hi. I have VPN setup through IKEv2 for a 10.10.10.0/24 network. While everything seems to be working just fine, I’m having trouble accessing Netflix. Often times it doesn’t load, or only loads content partially.
Ipsec connection is already being excluded from fassttrack. I’ve read in the forum that it has to do something with the MTU size discovery. I’ve tried multiple solutions already, such as these:
new-mss=clamp-to-pmtu makes no sense if PMTUD doesn’t work (I wonder what sense it actually makes if it does, anyone?)
The second rule only adjusts the MSS your client indicates to the server, but the real issue is most likely the sending direction (large packets from the client do not make it to the server). So instead of any action=change-mss rules, an additional IPsec policy should be the proper solution:
action=none src-address=10.10.10.0/24 dst-address=10.10.10.0/24. It has to be placed before (above) the template policy used by the /ip ipsec identity row of the IKEv2 VPN.
action=none src-address=10.10.10.0/24 dst-address=10.10.10.0/24. It has to be placed before (above) the template policy used by the /ip ipsec identity row of the IKEv2 VPN.
[/quote]
As you haven’t posted the complete configuration in the OP, I’ve made a guess, and the guess was wrong. So the policy #3 on the screenshot, which I have proposed, is useless and you can remove it; it’s policy #2 that should make the PMTUD work.
If it does, all is good and the only thing to do is to move it before current #0 (the only enabled template) so that once you disconnect and re-connect the VPN, current #4 would not be created before (above) current #2.
If it doesn’t, my assumption was wrong and something else is wrong.
I cannot see anything missing there, rather some redundant parts - I’d remove the action=mark-connection rules from mangle and the connection-mark=!local condition from the first action=fasttrack-connection rule, because the two action=accept rules matching on local=>!local and on !local=>local placed before the action=fasttrack-connection one are sufficient to prevent packets to/from 10.10.10.0/24 from making their connections fasttracked. So you can re-enable the first fasttracking rule, and remove the second one which is shadowed by the “accept established/related/untracked” one anyway. But that’s not a solution of the Netflix issue, that’s just saving a few CPU cycles per packet.
But since fasttracking is not what breaks your Netflix connections, enable the first action=change-mss rule, and add another one which will look the same except that 10.10.10.0/24 will be used as dst-address rather than src-address.
I’ve added the additional mangle rule, but it still doesn’t resolve anything.
The weirdest thing is all other streaming services work perfectly - tubi, pluto tv, hbo etc. The problem is only with Netflix.
That sounds like Netflix is checking something - the IP subnets used by popular VPN providers may be blacklisted, or Netflix may check the MTU size… Only sniffing can tell you whether there is something wrong at TCP level or whether the issue is at application level.
I don’t think the IPs are blacklisted, because partially it works - if you try opening episode/movie, 1 in maybe like 5 tries will work out, and you’ll be able to watch the episode till the end with no interruptions. However, most of the time it stucks loading or gives you different connection errors.
I’m not very mikrotik router savvy - is sniffing something I can do? If yes, can you point me to instructions?
It can be done, but it only makes sense if you can use Wireshark yourself, or have a local friend who can, to analyse the TCP session(s) between your “TV” device and the Netflix servers.
If you watch netflix on a PC, you can sniff using Wireshark directly on that PC; if you use a smart TV, the best way is to use port mirroring on the Mikrotik to copy the traffic to the Ethernet port of the PC.
It may contain sensitive information. It does not mean that it is forbidden to post it here, but you may not want to. More important, it seems that only image (picture) or text files can be attached.
Well, the actual pcap files are necessary for a serious analysis, the screenshots are useless. That’s why I was mentioning a local friend who can use Wireshark to analyse things.
What I can see from the screenshots is that your sniffing method creates duplicate packets in the resulting .pcap, what exactly does your current sniffing setup look like?
I can have a look at the .pcap if you don’t mind sharing it with me despite the eventual presence of sensitive info in it, but take into account I am a random stranger to you Your public IP will likely not be present in the capture, but hard to say what else may pop up there - some DNS queries, some visited public IPs… anyway, can you run openssl somewhere (Linux or Windows command line skills required)?
What I can see from the screenshots is that your sniffing method creates duplicate packets in the resulting .pcap, what exactly does your current sniffing setup look like?
I got the file using built-in Packet sniffer in Mikrotik router and then opened it on Wireshark app on Windows.
can you run openssl somewhere (Linux or Windows command line skills required)?
That’s still not a detailed enough description It seems you haven’t specified a particular interface to sniff at, so each packet is stored once as caught at bridgeVPN and the second time as caught at wlan3, and many other packets are stored as well although not necessary. So the capture may not contain the interesting part as it may have exceeded the reserved file size.
So if you still want me to have a look at your pcap, follow the instructions here.
That’s still not a detailed enough description > > It seems you haven’t specified a particular interface to sniff at, so each packet is stored once as caught at bridgeVPN and the second time as caught at wlan3, and many other packets are stored as well although not necessary. So the capture may not contain the interesting part as it may have exceeded the reserved file size.
That seems to be the case. I only specified the IP address to sniff and set the memory limit to 10mb. I captured around 30s of me navigating through different sections in Netflix (with content load issues) and also Netflix being stuck in video loading.
Do I have to recapture file, however, also specifying the interface now (bridge or wlan)?
Your public IP will likely not be present in the capture, but hard to say what else may pop up there - some DNS queries, some visited public IPs… anyway, can you run openssl somewhere (Linux or Windows command line skills required)?