go558a83nk

Connect to entry 3 or 4, that's tls-crypt. I think you need the experimental version but I might be wrong on that.

so they block https? or do they work as MITM?

I agree. airpvn.org is one of the slowest loading web sites I've ever used when I have to login. It's not bad when everything is cached.

Linux, as Untangle is based on Debian.

I can get 400+ mbit/s with my pfsense machine. With servers being 1gbps a single user can't expect much more because the server has limits - inbound + outbound = bandwidth limit.

Well, the first thing to try is TCP instead of UDP to see if that fixes it.

That sort of inactivity is not what causes disconnects. Something is causing the tunnel to not be able to send/receive data at all.

Isn't SSL and SSH still a more effective method of bypassing blocks? As i understand it, a SSL connection is less likely to be blocked than a standard OpenVPN connection with the packet headers scrambled. tls-crypt has so far been good for people who need to bypass state firewalls and since it can use UDP it performs better than SSL or SSH.

Sorry, I meant to reply to your post from a couple days ago and somehow it was marked as read and I forgot to. Yeah, I've noticed that servers will say the settings don't match if I'm asking for GCM. But, it'll connect with a GCM cipher as you've seen. I don't know about your CPU but mine is fastest with GCM so I'm glad to have it.

So, I did a little test. I connected to two different servers but at the same port. So, both had a 10.30.0.x virtual address. Sure enough, in the routing table of the web GUI only "ovpnc 1" showed under the netif column even though two clients were running according to "ifconfig" at the command line. However, when I looked at what my exit IP was according to web sites, machines that were supposed to use server "A" were reported as having server A's exit IP. And machines supposed to use the server "B" were reported as having the exit IP of server B. Could this just a bug in routing table display?

Congratulations!

I'm no expert. There's way too much I don't understand. The OP may be on to something but I also figured if this were an inevitable problem it would be discussed a lot more in pfsense openvpn topics. Here's my routing table with two clients up and running. The subnets aren't the same since one of them is to a tls-crypt server now.

I currently only use "don't pull" but I tested both and each one separately, and also the topology. Nothing changes what the server pushes to the client. Much of my pfsense setup is following the excellent guide that's here on the forums. In that don't pull and don't add/remove are selected and therefore you don't have problems of subnets overlapping. And perhaps there are some other settings that affect this too that I don't recall. Anyway, I've never had problems running multiple clients. What the server pushes doesn't change but it's that pfsense ignores it. The guide is indeed excellent, and I use it for my base config too. Have you read this? The issue I describe here is not new, and Air VPN support is aware of this issue. Couple of years ago they moved from a /30 topology to a /16. I am not making this up. If you are using multiple VPN client connections from the same machine (pfsense or router), please take your time to check your routing table. Go to pfSense, Status, OpenVPN, and record the Virtual Address of each connection. Do any of them share the same 2nd octet, like multiple in the 10.4 or 10.30 range? Look at your routing table, go to pfSense, Diagnostics, Routes. Check that you see all your OpenVPN clients under the "netif" collumn, or just paste both here and let me have a look. To which ports did you setup your connections? I've definitely run multiple openvpn clients where the subnets overlapped. yet, I've never had trouble with getting the traffic I wanted through the tunnel I wanted via NAT and firewall rules.

I currently only use "don't pull" but I tested both and each one separately, and also the topology. Nothing changes what the server pushes to the client. Much of my pfsense setup is following the excellent guide that's here on the forums. In that don't pull and don't add/remove are selected and therefore you don't have problems of subnets overlapping. And perhaps there are some other settings that affect this too that I don't recall. Anyway, I've never had problems running multiple clients. What the server pushes doesn't change but it's that pfsense ignores it.

I'm curious. What's the purpose of this?

Are you using the options in the openvpn client setup "don't pull routes" and "don't add/remove routes"?

To check for leaks I've always looked at the state table to make sure no connections are being made that I don't want, filtering it to see what I want. Is that a flawed method?

I am assuming you're using pfSense ... The way to catch LAN DNS queries, regardless of whatever server they have configured, is by making sure a client default gateway is set to pfSense and creating a port forward and associated firewall rule. The steps are outlined in Step 6 in this guide. I tested this extensively and I can set my DNS server to 1.2.3.4 (doesn't exist!) and DNS simply works. Never do I see packets fly out over port 53 on my WAN. The NAT+rule above will catch ALL packets on port 53 that wants to go OUT, will get caught and redirected to pfSense. Then, if pfSense is configured as I described above, no one will ever be able to see your queries, except Cloudflare DNS server, but they guarantee they don't keep personal logs (anonimized only). As I describe above, in my situation, this still randomly leaks DNS info to your ISP over WAN. No. The NAT + Rules redirect all DNS traffic. The procedure I describe above only makes sure that DNS Resolver from pfSense sends its queries to 1.1.1.1. I think you misunderstand how things work (or I misunderstand your question). When your browser requests a webpage using a domain name (and not an IP address directly), your PC first queries whatever DNS server it has configured for that domain. It will get an IP address back, and will do a handshake with that IP address over HTTP/HTTPS. This handshake is sent over the VPN tunnel. Your URL is sent along with some other information, so that the server accessing knows which domain and URL you are trying to access. The communication from the handshake and following, runs over your VPN tunnel. Whether the initial DNS query is sent over VPN, depends on your configuration. In my config I describe above, it is NOT sent over VPN, but that doesn't matter because its TLS encrypted traffic to the DNS server. So, it doesn't matter where the VPN server is, or where your webserver or CDN is located. The DNS query is always done by your client whether you're using a VPN or not. Your client cannot communicate with a domain name or URL directly, the internet does not "talk" in domain names or URL's, only in IP addresses. DNS resolution is always the first step done by your client. Yes, I'm using pfsense. Maybe I'll have to keep a closer eye on things but whenever I've looked I don't see any leaks out the WAN for DNS queries...though I did realize that if the VPN tunnel went down my firewall rules were allowing non-VPN devices to send their DNS requests out the WAN. But, I fixed that. My point in the second question is this basically: Say you're connected to a Netherlands VPN server but you physically reside in the USA. With your setup your DNS queries will resolve to a physically nearby youtube CDN. However, you'd want your VPN tunneled devices to access a Netherlands youtube CDN for best performance of youtube. The only way to make that happen is for DNS queries of VPN tunneled devices to go through the VPN tunnel as well.

One thing I like to make sure is that my devices (streaming media devices like Shield TV) don't use some other DNS that's coded into its OS or whatever app I'm using. I often see them trying to use google DNS. Anyway, I've gone the way of assigning whatever DNS server I want to use to DHCP clients, forcing them to use only that via firewall rules, and also forcing all those requests through a VPN tunnel so it can't be seen by my ISP. Your way sounds pretty cool but I have a couple questions off the top of my head. 1) does the forward "all" as you say really mean that attempts to use other DNS as I wrote about are re-written, so to say, to go instead to 1.1.1.1? 2) what if you're using a VPN server quite far away and want your DNS queries to resolve to CDN close to that server? It seems that your way here would resolve to CDN close to your real location. right?

Your title is misleading. TLS 1.2 has been in use for some time. tls-crypt is what's new. Paste in the tls-crypt.key info into the key field, and then below it select the option for authentication and encryption. Then also change the auth digest to SHA512. that should be what you need to connect. If you aren't already doing it, you should also see performance improvement using AES-256-GCM as data cipher vs CBC

1 and 2 are tls-auth, 3 and 4 are tls-crypt. The reason for having two of each is in case one is blocked by .... ISP or something. If you resolve a server name, for example, "nslookup leo.airvpn.org", it'll resolve to its #1 IP.

try a tls-crypt config.

Oh, that was with resolved hosts enabled. With resolved hosts disabled the config has no remote server at all.

# -------------------------------------------------------- # Air VPN | https://airvpn.org | Wednesday 16th of May 2018 07:06:42 PM # OpenVPN Client Configuration # AirVPN_CA-Toronto-Ontario_Rana_UDP-443-Entry3 # -------------------------------------------------------- client dev tun remote h.root-servers.net. 443 remote a.root-servers.net. 443 remote g.root-servers.net. 443 remote j.root-servers.net. 443 remote k.root-servers.net. 443 remote b.root-servers.net. 443 remote d.root-servers.net. 443 remote c.root-servers.net. 443 remote i.root-servers.net. 443 remote m.root-servers.net. 443 remote f.root-servers.net. 443 remote e.root-servers.net. 443 remote l.root-servers.net. 443 remote-random

Been using Chamaeleon with tls-crypt but this evening am noticing a problem but the status page isn't showing anything wrong. What I see is intermittent packet loss in my pfsense gateway monitoring, and traffic at random intervals goes to zero for a very short time then starts up again. When I tried to connect to Chamaeleon at entry 1 (not tls-crypt) but it wouldn't connect at all. I did, of course, change the static key to the proper one for the attempt. So, I switched back to tls-crypt and it connected just fine. But, I'm still getting packet loss. Something amiss with that server I'm afraid.