go558a83nk

I don't use dd-wrt but it looks as though it has policy routing built into the openvpn client GUI.

yeah, I was going to ask how they plan to get MAC addresses.

for the stability of the connection perhaps try other ports/protocols. regarding the policy routing, I see the problem. if your subnet is 192.168.25.xx, then to catch all LAN clients you need to use 192.168.25.0/24 as a policy routing rule.

are ISPs there using only IPv6?

sorry for the late reply. my internet was out yesterday after a storm. 1) you say you installed merlin after a factory reset. The factory reset needs to happen *after* you do the firmware upgrade. 2) if you added your computer's LAN IP for all destinations through VPN then I would say your VPN isn't connecting. please check out the system log. first things first - do a factory reset *after* firmware upgrade.

does it have an openvpn client?

Merlin firmware modifies the stock asus firmware. So, benefit to that is that you're getting a firmware that's made specifically for your hardware. I'm not sure but I think the NAT acceleration capability is only available with asus or merlin asus firmware. You'll also get other asus firmware things like the trendmicro protections. The late versions of merlin firmware have policy routing mode for the openvpn client so you can control which LAN clients go through the VPN tunnel.

just to make sure, try this speedtest or some others besides just Air's http://www.dslreports.com/speedtest

I would encourage you to switch to the latest Merlin firmware. However, when you do it you MUST do a factory reset of the router coming from the stock firmware. http://www.snbforums.com/forums/asuswrt-merlin.42/ latest is 378.54_2

looks like your internet connection is dying at those times. do you really mean "I can no longer connect to the internet" or do you mean you can no longer connect to AirVPN? when you're getting the problems with openvpn does internet work fine outside the VPN?

need to wait to hear back from him/her after the router switch. it does sound like a router was being used for VPN. in that case there are some questions re how DNS resolution was implemented. I've seen some policy routing setups where LAN clients were routed through the VPN tunnel created by the openvpn client on the router but DNS queries were sent to the router which was in turn querying DNS outside the tunnel. It's better to push to LAN clients via DHCP the actual DNS to use. That way you can be sure their DNS queries are going through the tunnel.

valuable tool there. I use the addon for firefox called SSleuth. https://github.com/sibiantony/ssleuth/ I am wondering how SSL Labs is getting their data for gmail. When I visit gmail site SSleuth reports Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Key exchange: Elliptic curve Diffie-Hellman. Authentication: ECDSA. Bulk cipher: AES GCM 128 bits. HMAC: SHA-256. Perfect Forward Secrecy: Yes SSL/TLS Version: TLSv1.2 Connection status: Secure Certificate Extended validation: No Signature: SHA-256/RSA Key: 256 bits ECDSA Common name: mail.google.com Issued to: Google Inc Issued by: Google Inc Validity: 5/6/2015 12:05:46 PM -- 8/4/2015 0:00:00 AM Fingerprint: 57:53:78:A6:01:EF:98:DF:6A:56: 35:4F:94:9E:C9:77:FA: :E0:1B which seems to contradict. I wonder why the discrepancy? Posteo.de info from SSleuth for comparison Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Key exchange: Elliptic curve Diffie-Hellman. Authentication: RSA. Bulk cipher: AES GCM 128 bits. HMAC: SHA-256. Perfect Forward Secrecy: Yes SSL/TLS Version: TLSv1.2 Connection status: Secure Certificate Extended validation: Yes Signature: SHA-256/RSA Key: 2048 bits RSA Common name: www.posteo.de Issued to: Posteo e.K. Issued by: StartCom Ltd. StartCom Certification Authority Validity: 4/16/2014 13:03:06 PM -- 4/16/2016 16:23:04 PM Fingerprint: 3A:89:D8:AD:DC:A7:23:5C:8F:44: E9:DD:2E:85:6A:31:D2:D3:C9:70

are you using the browser extension noscript?

where I'm at 35mbit/s is no problem. but, I'd be lying if I said everybody had no problems. that said, I think a high percentage of problems are out of Air's hands. our devices and all the internet between us and them are the problem makers.

OK, maybe I misunderstood what you were trying to say.

My suggestion is that in the route checking page there be an option to actually see the route trace from a server we select to the IP address we've asked to be tested. Sometimes I have problems where latency is low but the actual route used is through routers that are not optimal. However, I don't see what route is used until I connect to the VPN server then trace the route back to my IP. I know many will say I can trace the route to the server from my computer. The problem is that routes are often NOT symmetric. Since download speed would be affected by the route from server to me, I'd like to see that route easier. Thanks

if running a client on NO. If you're running *any openvpn client* on a machine in your LAN do NOT open ports on your router. All the router sees is a tunnel (whatever port and protocol you chose for the tunnel) and cannot at all affect any changes on that tunnel as it's encrypted. Trying to open ports within that tunnel would be impossible. With this kind of setup if you do open ports you're opening them to "clear" internet and that's not what you want. If running VPN on the router then you have to create some DNAT iptables to forward from the TUN device to the IP of the machine on your LAN. Soup123 was not detailed enough in his/her post for us to say much. TACD simply didn't have the daemon listening when testing if the port was open.

the Air speed test always seems to give low speeds to me. what does this http://www.dslreports.com/speedtest say?

The following tests on Asus AC68 with Merlin firmware 378.54alpha4. This version uses openvpn 2.3.6 with openssl 1.0.2a. Connected to Singapore server. My line speed is 35mbit/s. All speed tests done from same server in Singapore and with UDP 443 tunnel. Note that the system seems to have a narrow range of possible buffers - it won't go low or high, ignoring the custom options I input. Also, there may be something interesting with using 0 (zero), though it's not as fast as the larger buffer. no buffer options input send/receive as shown in log 131072 speed 19.34/5.26 mbit/s buffers set to "0" send/receive as shown in log 122880 speed 23.49/5.28 mbit/s buffers set to 65536 actual buffer used as shown in log 131072 no tested because duplicate buffers set to 262144 actual used as shown in log 245760 speed 27.85/5.25 mbit/s buffers set to 524288 actual used as shown in log 245760 not tested because duplicate edited to add more info up top.

easiest way is to run VPN on a router so that clients to that router (Wii U) go through the VPN.

*** egrep <egrep!~egrepnix@gateway/vpn/privateinternetaccess/egrepnix> has quit IRC (Ping timeout: 256 seconds) 04:01 *** egrepnix <egrepnix!~egrepnix@108.61.68.155> has joined #sailfishos-porters 04:02 *** egrepnix is now known as egrep 04:02*** egrep <egrep!~egrepnix@108.61.68.155> has quit IRC (Quit: Brb... switching to wired interwebs.) 108.61.68.155 - Vultr, the VPS provider from my above. If you want to trust a provider that relies on managed infrastructure of other small companies, this is totally your choice. That IP is in the range 108.61.64.0/19 the description of which is Choopa, LLC, not vultr http://bgp.he.net/AS20473#_prefixes

One point about the client area showing the client's real IP that must be made is in relation to tor. If the user wants to make sure that Air does NOT see his/her real IP it's VERY nice to have that client area page so that the user can confirm that Air sees a tor IP. Related to that, if a user connects with SSH or SSL tunnel (which PIA does not have) there is no IP address shown on the client area page. I assume this is because the VPN server sees the connection coming from another Air IP but staff will have to correct me if I'm wrong.

the test is coming from that server, but outside the tunnel. the point is to prove that the tunnel isn't degrading your speed (much) more than what encryption overhead necessitates. the path to you can be vastly different server to server. so, no, you should not expect out tunnel speed to be the same for every server.

@zhang888, check out http://bgp.he.net/AS20473#_prefixes and look for london trust media. those are PIA servers in choopa London. vultr is indeed in the description for other IP ranges. http://bgp.he.net/AS60485#_prefixes and http://bgp.he.net/AS57858#_prefixes Seems there are different AS for some of the IPs to which sweden resolves. 185.3.135.x are still shown in AS57858 in Estonia, description netroute. Could that be an error? The 5.157.38.0/24 range does say virtual in description To propose that PIA moved in 1 day their servers to Leaseweb's datacenter in Germany just because of this thread is silly.

whoer.net/extended ?? which line shows your real IP, webRTC?