[DEPRECATED] VPN Leaks (gufw)

[Anonymous Writer 2]

The Graphical Uncomplicated Firewall configuration for VPN Leaks is on the website. For any comments or questions, you can contact me at the website on the contact page or leave a comment on the website. Please ignore the untrusted certificate warning. The certificate is valid. Add a permanent exception.

https://www.sovereignpress.org/vpn-leaks/

Thank you.

EDIT by pj: it appears that this method does not prevent all leaks, please see here:

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5663&limit=6&limitstart=12&Itemid=142#5735

Please check.

[Staff 9770]

Thank you!

Since the certificate is not emitted by a CA, can you please publish the SH1 and MD5 fingerprints of the certificate to allow verification to everyone?

Kind regards

[Guest rbj]

I guessing that this only handles leaks? Is there maybe a way to have gufw stop all internet programs in the event that VPN is dropped?

[Anonymous Writer 2]

I guessing that this only handles leaks? Is there maybe a way to have gufw stop all internet programs in the event that VPN is dropped?

Nay. It is configured in such a way as to stop all Interent connections. For example, say you allow an IP to AirVPN and block all other traffic, then if the VPN disconnects, it is not possible to connect to the Internet apart from connecting to the Air IP first. No Internet works.

Think about it.

You are telling you computer to allow only certain connections and to block all other traffic. If you try making a direct connection, it will be blocked; if the VPN disconnects, all Internet connections will be blocked.

I called it VPN Leaks but in truth it is applicable to proxies and all Interent connections. In my book, the context was about VPN leaks, as the intro states.

It is a complete and utterly simple method to secure the Internet.

[Anonymous Writer 2]

Thank you!

Since the certificate is not emitted by a CA, can you please publish the SH1 and MD5 fingerprints of the certificate to allow verification to everyone?

Kind regards

Yes, I generated it and it is self signed, as the website states. There are many issues I take with Certification Authorities. And, in fact, I use Convergence, which removes the whole spurious CA issue. The certificate is trusted by default in Convergence.

I have thought about implementing something similar to your suggestion. I have not decided yet but it is possible--to avoid scaring off people.

[Guest rbj]

I understand!!! Thank you so much, Anonymous Writer, for the explanation.

[Staff 9770]

Thank you!

Since the certificate is not emitted by a CA, can you please publish the SH1 and MD5 fingerprints of the certificate to allow verification to everyone?

Kind regards

Yes, I generated it and it is self signed, as the website states. There are many issues I take with Certification Authorities. And, in fact, I use Convergence, which removes the whole spurious CA issue. The certificate is trusted by default in Convergence.

I have thought about implementing something similar to your suggestion. I have not decided yet but it is possible--to avoid scaring off people.

Hello!

A confirmation from you of the following would be enough atm:

SHA-1 fingerprint: 5E 1B EA F4 B3 76 E0 01 E0 3D 51 21 0C 9F FC 77 00 E3 5C 85

SHA-256 fingerprint: 7B 5F A0 F0 18 49 13 B4 8E 06 F5 A6 B4 2F 94 FF 59 9B B2 A2 5D 4F B4 AB 86 7A 6B E6 26 61 0A B2

This is the certificate we can see from the Air network. Since it's the same from all the Air servers, the probability of an hijacking can be considered practically zero if you confirm the above. This manual verification may be irrelevant in several countries, but might be important in some other countries.

Kind regards

[Guest rbj]

I followed the directions exactly except that I had to substitute 192.168.1.1 for x.x.0.0. Every time I disconnect the VPN Firefox still works. Does the connection have to be dropped from the VPN end for all internet activity to cease? I'm just guessing because I'm inexperienced. I do hope I can get this work for me. Thanks

[Staff 9770]

I followed the directions exactly except that I had to substitute 192.168.1.1 for x.x.0.0. Every time I disconnect the VPN Firefox still works. Does the connection have to be dropped from the VPN end for all internet activity to cease? I'm just guessing because I'm inexperienced. I do hope I can get this work for me. Thanks

Hello!

There's probably something wrong in your rules, Firefox must be unable to send data when the VPN connection drops. Can you post your rules?

Kind regards

[Guest rbj]

I'd be glad to, but I'm not really sure what it is that you want. Sure I know iptables, but I don't know where they are to send them. Yeah, I'm that dumb, but I really want to do this as I can see the importance of it. I definitely see the importance. And thanks for all your help. You've been great.

[Staff 9770]

I'd be glad to, but I'm not really sure what it is that you want. Sure I know iptables, but I don't know where they are to send them. Yeah, I'm that dumb, but I really want to do this as I can see the importance of it. I definitely see the importance. And thanks for all your help. You've been great.

Hello!

Did you create a script to flush rules and add the rules showed in https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 ? If so, can you publish it?

Kind regards

[Guest rbj]

It's been a long Thanksgiving day here. I will look at that in the morn. I really do want to get gufw set up correctly. But my brain is saying I must stop while I can still make it to the bathroom and bed.

Thank you so much for your help. I'll be back in about 8.

rbj

[Staff 9770]

It's been a long Thanksgiving day here. I will look at that in the morn. I really do want to get gufw set up correctly. But my brain is saying I must stop while I can still make it to the bathroom and bed.

Thank you so much for your help. I'll be back in about 8.

rbj

Hello!

Uh, sorry, when you talked of iptables this admin assumed that you were trying to implement the iptables rules without graphical iptables frontends. If you use gufw, just send the gufw rules, don't bother about the underlying iptables rules.

Kind regards

[Guest rbj]

I've looked everywhere for those gufw rules and I don't know where to find them. I searched for "gufw" and "ufw" and checked every file but no gufw rules. Help?

[Guest rbj]

Found the rules!!! And here's what I currently have:

*filter

:ufw-user-input - [0:0]

:ufw-user-output - [0:0]

:ufw-user-forward - [0:0]

:ufw-before-logging-input - [0:0]

:ufw-before-logging-output - [0:0]

:ufw-before-logging-forward - [0:0]

:ufw-user-logging-input - [0:0]

:ufw-user-logging-output - [0:0]

:ufw-user-logging-forward - [0:0]

:ufw-after-logging-input - [0:0]

:ufw-after-logging-output - [0:0]

:ufw-after-logging-forward - [0:0]

:ufw-logging-deny - [0:0]

:ufw-logging-allow - [0:0]

:ufw-user-limit - [0:0]

:ufw-user-limit-accept - [0:0]

### RULES ###

### tuple ### allow any 443 0.0.0.0/0 any 192.168.1.1 out

-A ufw-user-output -p tcp --dport 443 -s 192.168.1.1 -j ACCEPT

-A ufw-user-output -p udp --dport 443 -s 192.168.1.1 -j ACCEPT

### tuple ### deny any any 0.0.0.0/0 any 192.168.1.1 out

-A ufw-user-output -s 192.168.1.1 -j DROP

### END RULES ###

### LOGGING ###

-A ufw-after-logging-input -j LOG --log-prefix "[uFW BLOCK] "

-A ufw-after-logging-output -j LOG --log-prefix "[uFW ALLOW] "

-A ufw-after-logging-forward -j LOG --log-prefix "[uFW BLOCK] "

-A ufw-logging-deny -m state --state INVALID -j LOG --log-prefix "[uFW AUDIT INVALID] "

-A ufw-logging-deny -j LOG --log-prefix "[uFW BLOCK] "

-A ufw-logging-allow -j LOG --log-prefix "[uFW ALLOW] "

-I ufw-before-logging-input -j LOG --log-prefix "[uFW AUDIT] "

-I ufw-before-logging-output -j LOG --log-prefix "[uFW AUDIT] "

-I ufw-before-logging-forward -j LOG --log-prefix "[uFW AUDIT] "

### END LOGGING ###

### RATE LIMITING ###

-A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[uFW LIMIT BLOCK] "

-A ufw-user-limit -j REJECT

-A ufw-user-limit-accept -j ACCEPT

### END RATE LIMITING ###

COMMIT

[Staff 9770]

Found the rules!!! And here's what I currently have:

-A ufw-user-output -p tcp --dport 443 -s 192.168.1.1 -j ACCEPT

-A ufw-user-output -p udp --dport 443 -s 192.168.1.1 -j ACCEPT

Hello!

Excellent. You made no mistake, it's the proposed method by Anonymous Writer that does not really prevent all the leaks.

As you can see, packets to outbound ports 443 TCP and UDP are allowed from your physical interface. It means that when the VPN disconnects, Firefox (or any other browser) can still connect to https websites (in almost all cases, web servers listen to port 443 for https, and browsers by default send packets to port 443), and that's exactly what you report.

DNS resolution is not possible (because packets to port 53 are dropped) but the system, before sending out a DNS query, will use the DNS resolver cache to resolve the domain name, making the DNS block totally useless in this case.

This is dangerous, because if you're surfing an https website and you lose the connection, then refresh a page or access another page of the same website, you still have the same session cookies in your browser, thus that site will see you real IP address and will also be able (if the admins wish so) to correlate all your previous activity and account behind the VPN with your real IP address, potentially destroying your anonymity layer.

In order to solve the problem:

- if you always connect to our VPN to port 443 UDP, do not allow packets to port 443 TCP, i.e. delete the rule -user-output -p tcp --dport 443 -s 192.168.1.1 -j ACCEPT.

If you wish to connect to port 443 TCP as well, you will have to rely on a different approach to solve the vulnerability, an approach not based on ports. See for example instructions for iptables, pf or ipfw to get an idea. Approaches not based on ports will also allow you to connect to other ports our OpenVPN servers listen to (53 TCP/UDP and 80 TCP/UDP) without risking leaks in case of unexpected VPN disconnection.

Kind regards

[Anonymous Writer 2]

Excellent. You made no mistake, it's the proposed method by Anonymous Writer that does not really prevent all the leaks.

Actually, no, he has made error upon error. And your statement is not fair or correct.

First off:

The NAT Address listed on the screen shot is fake--it is an example.

The port listed is real but an example.

If you connect to a VPN, then you should only connect to the IP and leave the port blank. This way you only allow a direct connection from the NAT to specific IPs--there is no leak, nor can there be. In particular, if the VPN you use is limited to "UDP," then you configure a direct connection to that IP and protocol (UDP) only; you do not allow a port as well, since this would be illogical. You only allow out the IP and the protocol--not the port!

If you connect to a port only, then, yes, there can be leaks on that port--this is common sense. You are telling your computer to allow all connections on a specific port (i.e. 443), so yeah, it is possible. I have used Tor thus and have done a wireshark analysis in the past, and witnessed some leaks.

The port is not perfect--it is meant only for dynamic IPs that cannot be all configured or if you use multiple services, all of which are on 443, and you are too lazy to configure individual IPs.

As for the leaks on port 443...I have never, in my tests, been able to connect to any HTTPS service apart from a proxy or VPN. Try connecting to Thunderbird or HTTPS webpage when the VPN is off--it will be blocked.

This is all common sense. To "depreciate" the tutorial because some people do not understand basic concepts is not right.

[Staff 9770]

@Anonymous Writer

Thank you very much for the explanation.

Kind regards

[Guest rbj]

Hello Admin!

I made the changes you suggested. Started Air, then Firefox. Disconnected Air and Firefox still worked. Guess it's time to get in and really learn what I'm working with instead of expecting the easy way out.

Thank you for your help.

[Anonymous Writer 2]

Hello Admin!

I made the changes you suggested. Started Air, then Firefox. Disconnected Air and Firefox still worked. Guess it's time to get in and really learn what I'm working with instead of expecting the easy way out.

Thank you for your help.

I'm scratching my head in bewilderment...but the Admin is not the one who can help you. If you are having problems, you should have contacted me on my contact page. You cannot copy and paste everything without learning. You have to think and learn, not copy and paste.

Recognize the following:

1) Every network has its NAT Address. My NAT Address may not be the same as yours. To find out your NAT Address, check your "connection information." Or check your router. You make an Internet connection from your NAT Address. So this is the fount.

2). Remove all the rules you have made on ufw or gufw.

3). Restart the computer.

Now:

Before you turn on the VPN, add the following rules:

Allow out from your NAT Address "TCP" or "UDP" and a list of VPN IPs. For example, "95.110.200.16." Remember, if you are using a UDP certificate, then allow out "UDP."

Block out "Both" from your NAT Address to everything. Leave the IP and port empty. Do not fill in any information.

You should have two rules. The Firewall should be on.

Now connect to the Crucis VPN--"95.110.200.16."

Connection should be made. Browse on the Internet.

Turn the VPN off. You will not be able to make any Internet connection.

Recognize:

You are telling your computer to only connect to specific IPs (VPN IPs, proxy IPs, et al) and to block all other connections. Without the Firewall, your computer can connect to any IP or port, unless the ISP censors some content. The Firewall restricts how you make Internet connections with certain rules.

If you allow a "port," you are telling your computer to connect to any "IP" on that port. Although this has its uses and is secure, it is not as secure as a direct IP connection. Consider, for example, if you want to use Tor but avoid IP leaks, then you would allow a "port" because to find all the Tor entry IPs is not easy and you would have a very messy Firewall. By allowing a port connection with Tor, you recognize that there can be some minor leaks and that such a setup is meant for an inclusive and not an exclusive connection.

Static IP addresses--IP addresses that do not change automatically--should be configured with a direct IP connection.

There is no need to add a port to such a setup, because you want an exclusive connection to an IP, not a list of IPs on a port.

[worric 12]

Guys, what do you think about my network interface approach, written a few days ago..?

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5586&limit=6&limitstart=12&Itemid=142#5642

IMO it has quite a few benefits like allowing LAN traffic to continue functioning, and it's just a cleaner approach as opposed to specifying ports and protocols and whatnot.

[Staff 9770]

Guys, what do you think about my network interface approach, written a few days ago..?

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5586&limit=6&limitstart=12&Itemid=142#5642

IMO it has quite a few benefits like allowing LAN traffic to continue functioning, and it's just a cleaner approach as opposed to specifying ports and protocols and whatnot.

Hello!

The approach is very good and clean.

You can make it even better by allowing communications from any interface to the single IP 255.255.255.255 to allow initial communications with a DHCP server. 255.255.255.255 is the broadcast address of 0.0.0.0 (the zero network, i.e. the local network), so it's necessary to NOT drop the packets to it in order to establish a packet flow with a DHCP server. No worries about it, in IPv4 no packets toward 255.255.255.255 can ever leave the local network.

For those using a DHCP server, probably the vast majority of people, the addition will make unnecessary to turn off and then on the firewall at the bootstrap and in every other circumstance where a DHCP negotiation is needed.

With iptables something like:

iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server

iptables -A INPUT -s 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server

Another circumstance to think about (and we'll have to address it even in the iptables guide) is when a user does not have the resolvconf package installed (so the client has no way to process a DNS push from our servers) AND uses his/her router as a DNS server. In this case the DNS queries will be sent to the router and then sent out by the router itself unencrypted. Mutatis mutandis, the same problem has been already addressed and solved in Windows and in the Comodo rules.

Linux users without resolvconf will have to change manually their DNS server in /etc/resolv.conf (any DNS except the local router DNS will be tunneled), but to make them aware of their problem we could add a rule which prevents any communication toward their router (or even inside their whole LAN/WAN) if the destination port is 53 UDP. This rule will not harm communications inside the LAN/WAN but will make impossible to resolve names through the router (actually blocking DNS resolution if the primary nameserver is "misconfigured" and therefore alerting the user).

[EDIT] Finally, you can allow communications from/to the loopback interface (lo in most Linux flavors, 127.0.0.0/8) in order not to disrupt communications within it, which in some cases may be a serious problem.

Kind regards

[worric 12]

Thanks for the feedback, Admin.

If you're using ufw, it already has rules built in to allow DHCP function as well as the loopback function via some "before-input/output"-chains in IPTABLES.

I did, however, encounter a problem with these rules once:

I was at a library open network, and the local IP address I got was from a DHCP server on another network. While connected to the AirVPN, my lease on the local IP expired and my Ubuntu machine tried to renew the IP lease, which failed. I'm guessing that since it had already learned the DHCP-server's address, it no longer contacted the 255.255.255.255 broadcast address, and as the firewall settings were that tight, it couldn't get through to the DHCP server.

Creating a route in the connection settings through the gateway to the DHCP server IP on the other network, combined with a "allow out 67/udp" rule in gufw, did the trick.

I can't really say I understand it fully, but I guess this says something about problems arising from locking your computer down to prevent leaks with the VPN-connection on a public network. Had it been on a simple LAN, there would've been no problems (as there usually aren't when I use the machine at home), as well as there would've been no problems had the machine not been locked down (i.e had had unrestricted outbound network access in the first place).

[Anonymous Writer 2]

Guys, what do you think about my network interface approach, written a few days ago..?

airvpn.org/index.php?option=com_kunena&a...&Itemid=142#5642

IMO it has quite a few benefits like allowing LAN traffic to continue functioning, and it's just a cleaner approach as opposed to specifying ports and protocols and whatnot.

Although I would rather not get involved in this discussion, I feel obligated to point out a few things.

I think we can all agree that there are a variety of different configurations possible to secure VPN connections. I am familiar with your configuration. Although I agree that using tun0 works well, I would hardly classify it as overall “cleaner” than the configuration I laid out.

Let's exam this.

Using tun0 requires users to have some basic understanding of sudo and the command line, which many neophytes do not. More importantly, this configuration requires many rules and makes the Gufw look “unclean.”

With my configuration, no tun0 nor command line is required; therefore, it is more simplistic. Similar to the tun0 configuration, in my configuration users connect to the IP and protocol they desire but from their NAT address; more importantly, unlike the tun0 configuration, all incoming is blocked.

You claim “IMO it has quite a few benefits like allowing LAN traffic to continue functioning.” Uh, what? LAN still works.

You claim that “as opposed to specifying ports and protocols...” but in actuality the tun0 configuration requires you to specify between the TCP and UDP protocols. If you specify “TCP,” and the VPN is set for “UDP,” the VPN will not connect. So to be on the safe side, you could choose “Both.” So this is a bit dishonest.

In both configurations, user must choose from TCP, UDP, or Both.

In regard to the claim that my configuration requires one to specify a “port”—it does not. As I already made clear, the “port” is not required and should only be used when using dynamic services (i.e. Tor) that require a fishing expedition of Tor entrance IPs; or to avoid listing every single IP when using multiple services on the same port. IP connections are always the more secure and preferred method.

I would also point out the following:

When using the tun0 configuration, when a VPN connection is made, users can still connect to other IPs apart from the VPN IPs listed in the Firewall rules. In fact, I have successfully made connections to various proxies, including Tor.

Even though the configuration only allows out VPN IPs, all other proxy services work when connected to the VPN. When the VPN is disconnected, nothing works.

In the end, all the various configurations, whether Shorewall, Firestarter, or ufw work well.