go558a83nk

that's more evidence that it's your ISP shaping bandwidth.

sounds like the route to the server your using gets relegated to limited bandwidth and non-priority at times. your ISP at fault. See if it happens when you use servers that use different routes.

point 2 will be the hardest to meet. all combined I know of no router that does all you require.

I said in step 2, point 8 how to see logs for stunnel. But you said above "there is no where to find logs either". But there is. Please make sure stunnel is or is not running. Then you must edit your openvpn config to suit. It's all in the steps I outlined above.

I edited my post to confirm you create a stunnel tunnel in services>stunnel. Once that's running you can edit your openvpn config to connect to the listening stunnel daemon, which is step 3.

it could be that the route is overloaded or your ISP has poor bandwidth to whatever intermediate network(s) is used.

quit trying the same NL datacenter. obviously your route is poor and is especially congested during peak hours (evening). try other datacenters.

you don't need to import any cert for stunnel to work. 1) install stunnel package from package manager 2) Create the stunnel tunnel here in services>stunnel. /pkg.php?xml=stunnel.xml Select client mode use 127.0.0.1 as listening IP listen on port doesn't matter but you'll just use whatever you put here in the openvpn client setup certificate is default redirect IP is found in the .ssl file that you can download for stunnel in the config generator redirect port is also found in that ssl file (in the name of the file too) save the stunnel tunnel your status_logs.php should show stunnel activity to let you know it's running 3) Create or edit an openvpn config for AirVPN keeping everything the same as usual but changing the following protocol is TCP only interface is any server address is 127.0.0.1 server port is what you setup as listening port for the stunnel tunnel in the custom options box input route <server IP address> 255.255.255.255 net_gateway; where <server IP address> is the same as in point 5 above Now in my experience it'll connect then disconnect, perhaps a few times before finally staying connected. Just be patient.

router CPU can't do openvpn very fast at all. only a few can, if they have the proper firmware and an AES-NI CPU.

No, it's not more secure for the actual data. It's more resistant to hostile networks. It doesn't take appreciably more power to use and performance might be a little better depending on the network used. They may not throttle it like they might other openvpn connections. It's not the default because some old devices may not support tls-crypt? I'm not sure.

tls-crypt means that the control channel of openvpn is encrypted from the start. all servers support this at entry IP 3 or 4.

you need to try different datacenters for different routes. all the NL servers are in the same datacenter I think. Does your CPU support AES-NI?

my ISP too

48 per year is pretty cheap.

you can create gateway groups and have multiple tiers within the gateway group. the rule for the group can be such that when one tier is down it falls back to the next tier. the only problem, last I tested, is that once the higher tier gateway is back up it won't automatically fall "up" to it.

html5 geolocation. it can be disabled in browser. about:config

destination IP is your camera IP. if you used just the built in port forwarding of the router that forwards from WAN to LAN. You need to forward from TUN to LAN. If port forwarding was working then it wasn't working through the VPN.

if you are running the openvpn client on your router then you do need to use iptables such as the above. Just make sure to correct the tun device number

https://www.speedtest.net/result/c/2b63a577-e5a5-4205-98db-bb25ab01c371 There are a lot of places where slowness comes from but speed can happen. I use a pfsense box to run openvpn for the whole house. The speedtest machine is my laptop on wifi, which is an area of slowness itself.

Horrible routing to these new servers.. 4 [19108] [SUDDE] 173-219-233-235.suddenlink.net (173.219.233.235) 27.6ms 5 [19108] [SUDDE] 173-219-233-250.suddenlink.net (173.219.233.250) 26.9ms ** [neglected] no reply packets received from TTL 6 7 [6461] [ABOVENET] ae3.cs2.dfw2.us.zip.zayo.com (64.125.26.204) 33.0ms 8 [6461] [ABOVENET] ae28.er1.dfw2.us.zip.zayo.com (64.125.26.15) 28.2ms 9 [6461] [ABOVENET] zayo-comcast.dfw2.us.zip.zayo.com (64.125.13.186) 128.5ms 10 [7922] [COMCAST-16] be-12495-cr02.dallas.tx.ibone.comcast.net (68.86.85.193) 125.1ms 11 [7922] [COMCAST-16] be-12124-cr02.1601milehigh.co.ibone.comcast.net (68.86.84.229) 144.7ms 12 [7922] [COMCAST-16] be-10521-cr02.350ecermak.il.ibone.comcast.net (68.86.85.169) 160.7ms 13 [7922] [CABLE-1] be-1302-cs03.350ecermak.il.ibone.comcast.net (96.110.36.105) 163.0ms 14 [7922] [CABLE-1] be-2311-pe11.350ecermak.il.ibone.comcast.net (96.110.33.202) 163.9ms 15 [46844] [ST-CHI] comcast-100ge.3-2.19.chi.il.sharktech.net (208.98.0.37) 160.0ms ** [neglected] no reply packets received from TTLs 16 through 17 18 [11878] [TZULO] [target] static-68-235-48-107.cust.tzulo.com (68.235.48.107) 159.8ms

Usually the temporary fix is to disable the route checking in settings. The real fix would be to find out why that's happening. Since are running a beta it could be that you need to report this in the beta thread as a bug.

UDP connects just fine but something goes wrong with checking route.

Is this necessary if there are no logs kept anyway?

UDP entry IP 3 or 4 don't work? Have you tried all the ports? Is this a restricted network you're on?

Well, I'd try UDP entry IP 3 or 4 first. If that doesn't work like it should then try TCP entry IP 3 or 4. If that doesn't then resort to stunnel. I'll be glad to try to help should it come to that. But it's a last resort because it's just not going to have much speed either. I'm really surprised you saw more than 200mbps with the SSL tunnel. What OS was doing the testing back then?