Community discussions

MikroTik App
 
jdub88
just joined
Topic Author
Posts: 15
Joined: Fri Sep 25, 2020 1:35 pm

Certain devices not working via hAP Lite & VPN

Sun Oct 18, 2020 3:27 pm

Hi :) I have my hAP Lite set up and all traffic goes via VPN. This has been working just fine.

I'm running into an issue however where I get 0mbps upload (download is fine) with certain devices. For example my Android media hub, when connecting to YouTube, it loads the listings OK and can search (though its slow) but I can't play back. Speed test shows 0mbps up so this is the issue. It is fine when I don't go over VPN, so I've narrowed it down to at least that degree.

When I had this issue before, I addressed it with disabling fasttrack but this feels like the same issue, though this time I am a little stuck as there is nothing terribly obvious as to what may be different about this

What should I be looking at here? The device is on the same LAN segment as devices that work just fine. I have tried searching specifically around this and can't find anything. Any ideas on why this would be down to the device? I am using wifi, though a cable did not fix the issue (though I got a solid download boost..)

Thanks!
 
jdub88
just joined
Topic Author
Posts: 15
Joined: Fri Sep 25, 2020 1:35 pm

Re: Certain devices not working via hAP Lite & VPN

Mon Oct 19, 2020 1:45 am

Just to update here. In digging more it seemed to be tcp traffic with the problem. I tested NordVPN app in wireguard mode on the android box and with the vpn still connected on the hAP (it’s IKEv2 mode) the issue is fixed. So vpn through vpn but most key I think is the udp tunnelling

However, my bedroom tv has the same symptoms and I can’t install apps there.

This feels like an MTU issue but in scouring the forums for values I only seemed to make things worse.

Always curious to get to the bottom of things so any hints on where to look would be cool.
 
sindy
Forum Guru
Forum Guru
Posts: 5919
Joined: Mon Dec 04, 2017 9:19 pm

Re: Certain devices not working via hAP Lite & VPN

Mon Oct 19, 2020 9:31 am

Have you seen (and tried) this?

Since you say you have a problem with sending from the local devices (if I got you right), it is a likely cause and solution.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
jdub88
just joined
Topic Author
Posts: 15
Joined: Fri Sep 25, 2020 1:35 pm

Re: Certain devices not working via hAP Lite & VPN

Mon Oct 19, 2020 8:46 pm

Thanks for this. Yeah so for some (but not all) devices, they seem to be struggling with uploads/outbound. I thought my double-vpn solution was good, but it's proving unreliable

I currently use the src-address-list in the mode-config for ipsec:
/ip ipsec mode-config
add name=NordVPN responder=no src-address-list=local
If I add the rule as you noted in the other thread, I don't see any changes to my NAT but presumably that's because that's applicable to the connection-mark method?
 
sindy
Forum Guru
Forum Guru
Posts: 5919
Joined: Mon Dec 04, 2017 9:19 pm

Re: Certain devices not working via hAP Lite & VPN

Tue Oct 20, 2020 8:36 am

If I add the rule as you noted in the other thread, I don't see any changes to my NAT ...
If you mean the policy as I noted in the other thread, it won't change the dynamically added NAT rule no matter whether that rule matches on the connection-mark or the src-address-list as set on the mode-config row.

The thing is that if the IPsec transport packet doesn't fit to the uplink's MTU, because already the payload packet is large enough and the IPsec headers make it even larger, the router itself sends an ICMP notification "the packet is too large to fit without fragmentation, the maximum size is ..." to the sender of the payload packet (and the sender then sends a smaller portion of the TCP buffer i a new packet). The router sends this ICMP notification from its own IP address; in this particular case, it is quite likely that it uses the one in the LAN subnet. Since you have placed the whole LAN subnet to the address-list you've put to the mode-config, the dynamically added action=src-nat rule matches also on this packet, as it doesn't check for any out-interface so the fact that the packet should leave via LAN interface is not important. And once the rule changes the packet's source address, the IPsec policy redirects it and sends it down the tunnel so the sender never receives it.

So it may be sufficient to change the address in the address-list local from a prefix (such as 192.168.0.0/24) to a range (such as 192.168.0.2-192.168.0.254) which doesn't include the router's own address in the LAN subnet. With connection-mark, the situation differs, as the ICMP notifications related to a connection inherit the connection-mark from that connection.

So the use of the exceptional policy with action=none is generic - it prevents packets from any src-address (0.0.0.0/0) to the destination addresses in LAN (dst-address=192.168.0.0/24 in the example above) from reaching the dynamically generated action=encrypt policy no matter for what reason they've suffered the NAT treatment. What is important is that it was placed before (above) the policy template from which the actual encryption policy is dynamically generated.

From what you wrote it is not clear whether you have tried it and it didn't help or whether you are still at theoretical stage. So please be clear, and if adding the action=none policy doesn't help, post the output of /ip ipsec policy print detail (after obfuscating any public addresses).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: Baidu [Spider], fredcom, Kickoleg, lpoonyx, sindy and 107 guests