Connection Security and Privacy

• Outbound from your PC to public internet. Maybe called a "consumer" or "anonymizer" VPN service, or a "VPN tunnel to a proxy". Some examples are Windscribe, ProtonVPN, PIA.
  
  
• Inbound from your PC to a LAN. Maybe called a "remote access" VPN. Your client PC may be on your home LAN, or (while you're traveling) on some other LAN across the public internet. The target LAN might be your home LAN, or work or school network.
  
  

• Systemwide VPN: encrypts all traffic and changes the IP address it comes from, sends traffic to VPN server.
  
  
• Systemwide forward proxy: only changes the IP address all traffic comes from, sends traffic to proxy server.
  
  
• Systemwide onion proxy: sends all traffic from your system out through the onion network, changing IP address. (anonsurf, nipe, TorGhost, Tallow, torctl, Torifier, etc. article)
  
  
• Dedicated OS with onion proxy: sends all traffic from your system out through the onion network, changing IP address. (Tails, Kodachi, Subgraph OS, Whonix)
  
  


• Single-client VPN: (a browser extension and maybe proxy setting in the browser) encrypts browser's traffic and changes the IP address it comes from.
  
  
• Single-client forward proxy: (a proxy setting in the app) only changes the IP address on traffic from one app.
  
  
• Single-client onion proxy: sends one app's traffic out through the onion network. (torsocks, Torify)
  
  
• Dedicated onion client: only that app's traffic goes out through the onion network, changing IP address. (Tor Browser)
  
  

• VPN client could be:
  
  
  • custom/proprietary from a commercial VPN service (such as Windscribe, ProtonVPN, PIA), or
    
    
  •   standard/open-source built into your operating system.
  
  
• VPN server could be:
  
  
  •   owned by a commercial VPN service (such as Windscribe, ProtonVPN, PIA), or
    
    
  • your own VPN server in a cloud-hosted VPS. But that VPS probably will require real ID to register, may be limited to one geographical area, may use a unique IP address (your traffic not mixed with that of other users), the service could log your traffic, and the service may kill your account if they receive any DMCA complaint. IP address much less likely to be blocked than commercial VPNs. VPS could be free (e.g. T2 micro instance in AWS free tier).
  
  
• VPN protocol settings could be:
  
  
  •   UDP I've found UDP to be faster than TCP. Also OpenVPN's "What is TCP Meltdown?" and Carl Dong's "Why your TCP-based VPN stutters"
    
    
  • port 443. Probably less likely to be blocked or scanned than other ports.
  
  
• DNS service could be:
  
  
  •   provided by the commercial VPN service (such as Windscribe, ProtonVPN, PIA), or
    
    
  • your ISP's DNS, or DNS from Google or Cloudflare or somewhere else.
  
  

• Use an outbound VPN. Leave it running 24/365. Turn it off only briefly when using some site that won't tolerate a VPN.
  
  
• A VPN will not keep you 100% secure or private or anonymous. But it will help in certain small ways.
  
  
• Give as little identity info as possible to your VPN provider.
  
  
• Use HTTPS to hide traffic details from your VPN provider.
  
  
• You never can 100% trust your VPN provider. But trusting the VPN with part of your data is better than trusting your ISP with all of it.
  
  
• Don't use VPN's proprietary client or extension, and don't install a root certificate from VPN.
  
  
• I like Windscribe and ProtonVPN. I'm sure others are good too.
  
  

• Hide your traffic from your ISP, which will see only encrypted traffic to/from the VPN. So your ISP can't sell your data, inject ads, or throttle based on traffic type or traffic source.
  
  
• Add an extra layer of encryption to your traffic; protects against threats on the LAN or Wi-Fi. If any of your apps or services are doing plain HTTP, this added layer of encryption is the only encryption protecting the content from your ISP and devices on the LAN.
  
  
• By using the VPN's DNS, you get a secure tunnel to the DNS, and your ISP can't see your DNS traffic.
  
  
• Web sites and eavesdroppers will see the IP address of the VPN server, not your home IP address.
  
  
• Mix your traffic with hundreds or thousands of other users using the same VPN server.
  
  
• Defeat geo-blocking, where a download or site won't work unless your IP address is in a certain country.
  
  
• Defeat location-tracking, where a site wants to relate your IP address back to physical location.
  
  
• Flexibility: you can turn the VPN on and off, or change VPN server, as you wish.
  
  
• Add multiple jurisdictions/countries, if someone wants to sue or DMCA you.
  
  
• If a site or remote ISP bans your IP address because of something you do, you can just switch to a different VPN server or a different VPN service.
  
  
• If someone tries to DDOS you, the traffic goes to the VPN server, not your home IP address.
  
  
• Some VPNs have additional features, such as ad-blocking and malware-site-blocking and parental controls. Putting this inside the VPN can be great in some situations, such as phones where you can designate only a VPN or an ad-blocker, but not both.
  
  

• You will pay a performance penalty, the only question is how much.
  
  
• Some VPNs may sell your data. If you use HTTPS, the data they can see is limited.
  
  
• You may pay money for the VPN.
  
  
• Some sites may not work or may impose a CAPTCHA if they see your traffic is coming out of a VPN. Some (e.g. PayPal) may not let you log in through a VPN unless you have two-factor authentication enabled on the account.
  
  How can they tell you're using a VPN ? By looking up on list of known VPN IP addresses, checking for DNS leak, maybe using WebRTC, maybe looking at MTU value, maybe seeing if port 1194 is open, maybe looking up who owns your IP address.
  
  See if your VPN is detected: proxycheck.io, Scamalytics
  
  
• Some sites (such as govt or credit-reporting companies) may not work if they see your traffic coming from a foreign country.
  
  
• Some sites (such as open game servers) may automatically ban your account if they see you using a VPN ? They just assume you must be cheating.
  
  
• If someone else has abused a site using the same VPN server you use, the site may ban your account when they see you using same IP address as the abuser.
  
  
• If someone else is using same site as you are, using the same VPN server you are, the site may rate-limit you when they see you using same IP address. Reddit does this.
  
  
• If someone else is using same site as you are, using the same VPN server you are, the site may ban you when they see one IP address using two accounts.
  
  
• Some sites (such as bank or PayPal) may trigger a security flag if they see your traffic coming from a VPN or from an unusual country.
  
  My bank said this:
  We do not prohibit the use of a VPN per se, but VPN use often triggers our automated high-risk login protocols which lead to temporary account restrictions.
  
  We strongly suggest if you choose to use a VPN that you also enable two-factor authentication on your account. An account with active two-factor authentication should be exempt from automated restrictions.
  [Someone on reddit said same is true of Capital One; if you use VPN, have to use 2FA.]
  But your VPN may always have its traffic coming from a certain country, and you may be able to specify a static IP address. So you could reduce or avoid this problem.
  
  

• Some networks (such as a school or library or public network) may ban/block VPN use.
  You may be able to defeat this by using OpenVPN with TCP + port 443 instead of the more common UDP + port 1194.
  
  
• You're adding another layer, another point of failure, to your system. If the VPN or its ISP is down, you're down (until you turn off use of the VPN).
  
  
• If you're installing the VPN's custom app on your system, you're trusting the app not to be malicious.
  
  
• Your ISP has to obey the laws of your country; the VPN may be located in some foreign country under a different legal system. The VPN company may be less regulated than your ISP.
  
  
• If the VPN shares IP addresses among many customers, you may suffer from the bad behavior of other users. For example, suppose user X uses address N (VPN server N) to do port-scanning, an ISP tags that address as malicious, then you connect to the VPN and start using same address N (VPN server N) ?
  
  
• Some VPN clients could crash/fail silently. So you could browse for a while thinking you're using the VPN, when you're not. The feature where the VPN client software disables all internet access if the VPN disconnects is called a "kill switch" (sometimes "firewall", or "always on").
  
  
• VPN might interfere with operations between devices on your LAN, such as file-transfer or remote-contol or peer-to-peer apps.
  
  
• A quirk: when you first turn on the VPN, probably any existing connections are not disconnected. So you may assume that the connection from app X is going through the VPN, but it is not. Solution: quit all apps, turn on VPN, launch all apps again.
  
  
• VPN might give you a false sense of security. Many of the companies providing VPNs exaggerate the benefits. You can't use a VPN and just assume you're fully protected against all threats.
  
  

When creating a new account, or doing a major purchase, you may not be able to use a VPN. The account may be locked or the transaction denied.

So, instead, go to a network that is not associated with you (Wi-Fi at Apple Store or a library or a cafe), turn off VPN, and do your business.

If creating a new account, maybe log in and out several times over the next few days from the same network or nearby networks. You are "training" the security algorithms to see that your IP address can vary, and your location is reasonable, and you're not using a VPN. After that, you should be able to use a VPN, picking a server that is somewhat near that location (same country at least, same city better).

Suppose your VPN is super-malicious ? What's the worst they could do ?

Suppose you have registered with the VPN anonymously (not hard to do).
VPN sees your home IP address each time you connect (unavoidable).
Suppose you use the OS's standard VPN client (best practice; avoid client-side attacks).
Suppose you use the VPN's DNS (good practice).
Suppose you use HTTPS for all traffic (best practice).
Do NOT install a special "root" certificate supplied by the VPN company.


A Man in the Middle (MitM) attack usually has two steps: somehow getting into the middle, then somehow doing something with/to the traffic. But in this case the first step is done; the VPN server already is the MitM. What attacks could it do on the traffic ?

• Decrypting traffic: They would need the web server's private key, or have a way to break public-key cryptography. Or is it possible to grab the session key by listening to the handshake at the start of the session ? That should have been encrypted by public-key cryptography as it went across the wires, I think.
  
  
• DNS spoofing (AKA "DNS poisoning"): They could DNS-redirect you to malicious sites. You ask for "facebook.com", which would be IP address 1.2.3.4, but VPN sends you to IP address 5.6.7.8. You'd have to notice the wrong domain in the address bar, or in the certificate info.
  
  
• HTTPS spoofing / Homograph Attack: They could DNS-redirect you to malicious sites. You ask for "facebook.com", VPN sends you to "faceb00k.com" (which does have a valid certificate). No warning from browser; user has to detect this in the address bar, or in the certificate info.
  
  
• SSL bumping: They produce a fake TLS certificate (not easy to make one that has a valid chain of trust) to make it look like you're talking to the destination site, but you're actually talking to the MitM. Browser should flag this unless you've been tricked into installing a bad root CA into your browser/system. article
  
  
• SSL stripping: You request HTTPS to site W, but MitM says "sorry, only HTTP available", then listens as you talk HTTP to site W. Browser would show open-padlock icon or similar in address bar; user has to notice this icon.
  
  
• SSL / TLS downgrading: You request HTTPS with TLS 1.3 to site W, but MitM says "sorry, only TLS 1.0 available", then is able to crack TLS 1.0. Browsers have started refusing old known-vulnerable versions of TLS.
  
  

IoT devices are an interesting case: there is no browser and no user. You may think a device is using HTTPS and thus secure, but if it ignores bad certificates or broken chain of trust, it could be MitM'd.

Wikipedia's "Man-in-the-middle attack"
Secret Double Octopus's "Man in the Middle Attacks"
Tomasz Andrzej Nidecki's "All about Man-in-the-Middle Attacks"

From someone on reddit:

> Couldn't an SSL decryptor be used for malicious purposes?

First let's categorize the decryptor into 1 of 2 categories:

• Decrypting traffic coming from anywhere addressed to a specific web server.
  
  The decryptor needs access to a legitimate (trusted) certificate with the website's name in the "subject name" or "subject alternative name" fields. To obtain such a certificate you either steal / compromise it or prove you own the domain name in question by having access to either the website's data, the domain DNS zone or specific email addresses like admin@domain.whatever.
  
  Without such a certificate, the decryptor can operate with any certificate, even a self-signed one. But this will throw an error in browsers visiting the website, stating that there is a problem with the certificate. Users may have the option to continue to the website after the error or not, based on factors such as if the site is using HSTS.
  
  
• Decrypting traffic from specific user(s) addressed to any web site.
  
  In this case the decryptor employs an internal CA that generates a certificate with the name of each visited site on the fly. This step doesn't need any interaction, BUT if this CA is not trusted by the client's application (typically a web browser), we will return to the error / warning mentioned above.
  
  

In both cases the decryptor must be placed in the "route" of the data. Also the number of requests must be considered as the decryptor will decrypt then re-encrypt every request / response, which requires some amount of processing power for each request, not to mention storage requirements if the intercepted data will be stored.

If a malicious actor can have the required certificate for the first case, or can make the clients trust his decryptor's internal CA for the second case, and can intercept the traffic (in both cases) to route it or make it go through his decryptor, it's done, he can decrypt the traffic and have access to the plain text.

...

The decryptor must intercept every request/reply, playing as a man in the middle, decrypting the traffic then re-encrypting it. Intercepting just the initial handshake does not give it the ability to decrypt all subsequent traffic, because of perfect forward secrecy (PFS) which is typically used in SSL traffic.

Any sites that deliberately do various types of MitM so you can test your browser ?

Any apps to see if you are being MitM'd right now ?
NoSnoop (Windows only)
chorn / mitm-detector (Linux only)

• Extension in browser (so works only for that application), or
  
  
• A layer/device in OS networking stack on client computer (so each computer in the house has to install it), or
  
  
• In router used by all client devices in the house.
  
  Some VPNs have client software that can be installed in your home router/modem. Only a few home routers support this, and maybe only pre-installed before you buy the router.
  
  Advantages: Nothing has to be installed on each client device, some client devices (such as game consoles, IoT) are locked down and you can't install VPN client software on them, some smartphone OS's (iOS at least) permit installing only a VPN client OR a firewall so this would allow you to have both, new devices automatically use the VPN, you administer the VPN client in only one place, you're guaranteed that even accesses by your client during boot and shutdown and install and update are handled by the VPN.
  
  Disadvantages: If that home router/modem is owned by your ISP, ISP may be able to see your traffic before it goes into the VPN. And if you need to disable the VPN to play a game or stream video or something, it may get disabled for all devices. Make sure you can put a list of domains into the VPN router client, so access to those sites does not use the VPN, because some sites will not tolerate a VPN. Expect complaints from other users in your house as sites break and you have to whitelist them. Sometimes one device or user may need to use a VPN server in country A while another device or user needs to appear to be in country B. You're not protected against other devices on your LAN attacking/monitoring your traffic. If you take your phone/laptop to another network, it no longer has (automatic) use of the VPN, you have to remember to switch to client software on the device. Requires a more-powerful router, and puts a load on it.
  
  From someone on reddit 6/2017:
  
  
  > I want to buy a used router/modem for $100
  > that would run a VPN client.
  
  On a $100 budget you won't be able to get a new modem and router and have a router that is decent for VPNs.
  
  Consumer-level routers are generally woefully underpowered for OpenVPN, so you need the best router CPU that you can get for the budget you have. An underpowered CPU in the router will severely limit your performance to all devices connected through the router while on the VPN.
  
  Also consider the OS of the router. Asus has done a lot of work to make the OpenVPN install process very easy on their routers, and many other vendors do not support OpenVPN out of the box and require flashing the router to DD-WRT or Tomato, which can be hit and miss with support for your router hardware and also be an older build that contains security vulnerabilities.
  
  DD-WRT does have the advantage of being open source, unlike AsusWRT, but it really is a sh*tshow for first-time VPN users.
  
  Based on your budget, i'd get a mid-range consumer-level router from your preferred brand, and connect to the VPN using a regular OpenVPN client on the devices that you want protected. This is because a typical PC (even an old one) has many times over faster CPUs for VPN usage.
  
  This setup would give you the protection of a VPN, with decent speeds (if your VPN provider is fast) and not break your budget.
  
  Router specifically built to run a VPN client: InvizBox
  
  

• Proprietary to the VPN vendor (could have more features), or
• Built into the OS, or
• Open-source standard (OpenVPN or WireGuard or strongSwan ?)

• A standard communications protocol, and
• An open-source protocol layer (SSL/TLS, OpenSSL, usually using AES-CBC or AES-GCM) in the 7-layer stack, and
• An application to start and manage the OpenVPN protocol layer.

• A communications protocol, and
• Existing network interface utilities, plus a new utility "wg".
• Claims to be much simpler than OpenVPN/OpenSSL or *Swan/IPsec.

• A client application.
• Implements the IKEv1 and IKEv2 key-exchange protocols.
• Uses IPsec.
• Can use one of three crypto libraries (legacy [non-US] FreeS/WAN, OpenSSL, and gcrypt).

> On Android, should I install VPN provider's app directly, or
> should I set up OpenVPN per instructions on provider's website?

Often the custom VPN client supplied by a VPN service has nice features that make it preferable to use. The stock Android OpenVPN client is spartan. 'OpenVPN for Android' by Arne Schwabe is better. You choose based on features/convenience.

• Downloaded OpenVPN client installer from OpenVPN's "Community Downloads".
• Logged in to Windscribe web site and downloaded files from OpenVPN Config Generator.
• Installed OpenVPN and copied Windscribe ".ovpn" config file into OpenVPN config folder.
• Ran OpenVPN client and logged in with credentials from Windscribe.
• DNS leak test showed a DNS leak until I added a "block-outside-dns" line to the config file Windscribe gave me. (But someone says that "only works for modern Windows versions, using the Windows Filtering Platform (WFP)", which is true.)
• No way to select a particular VPN server, but directive such as "remote es.windscribe.com 443" in the OpenVPN client config file means you will get a Windscribe server in Spain ("es").
• I didn't install certificates supplied by Windscribe, and saw no obvious ill effects.

• Your home ISP, if you use no VPN.
• The VPN service, if you use a commercial VPN.
• The cloud service, if you use your own VPN server hosted on a cloud service.
• Your home ISP, if you use your own VPN server hosted at home.

• Definitely use HTTPS on every site that supports it.
• Use the VPN all the time, 24/365, don't turn it on and off.
• Use the VPN's DNS server.
• Use a generic client, not the VPN service's custom client app or extension.
• Don't install a root certificate from the VPN company.
• Using a VPN hides traffic from your ISP, and others on your network.
• Using a VPN has costs, in performance and functionality and maybe money.
• Even if the VPN is logging and selling your data, that is better than your ISP doing the same.

• Do browser and DNS leak testing, with sites such as Do I Leak ? and IPleak.com.
  
  Test your torrent client: TorGuard, or IPMagnet.
  
  
• Check the system routing table; the VPN device (maybe "tun0") should be first and handling most of the traffic.
  
  On Linux, do "ip r".
  
  On Windows, maybe "netstat -rn" or "route print".
  
  
• Run a traffic dump and see if any traffic is going to any address other than your VPN's address.
  
  On Linux, use tcpdump. Also maybe tcpflow or netpeek ?
  
  On Windows, use netsh and Microsoft Message Analyzer [tool has been discontinued by MSoft]:
  1. Make sure your VPN is running.
  2. Run CMD as administrator (Start menu, search for cmd, right-click on Command Prompt, choose "Run as administrator").
  3. Run "Netsh trace start scenario=NetConnection capture=yes report=yes persistent=no maxsize=1024 correlation=yes traceFile=C:\Logs\NetTrace.etl".
  4. Do some network activity.
  5. Run "netsh trace stop".
  6. Run Microsoft Message Analyzer.
  7. Open the trace file (".etl" file) saved by netsh.
  8. Your VPN's address probably starts with 10 or 172 or 192. Addresses starting with 127 are okay. (Wikipedia's "IPv4") Access to an IP address starting with some other number is suspicious. Try looking up suspicious addresses on LookIP.net or Whois History (has changed to paid).
  9. To do this efficiently, add filter "!(IPv4.Address in [10.0.0.0/24, 172.0.0.0/24, 192.0.0.0/24, 127.0.0.0/24])".
  10. Apparently only values of TCP "local" addresses matter ? "Remote" will be the outside address the VPN server is talking to, but your computer is not talking directly to that address ?
  
  
• On Linux, monitor for IP address changes:

  
  ip -t monitor   # gives messages when route changes, but not very clear
  
  https://stackoverflow.com/questions/2261759/get-notified-about-network-interface-change-on-linux
  
  # If you're using Network Manager to take VPN down/up deliberately, add a script
  # under /etc/NetworkManager/dispatcher.d
  # But I think this will only catch deliberate user operations through Network Manager
  
  # Add scripts under /etc/network/if-up.d and /etc/network/if-post-down.d ?
  # A script put in /etc/network/if-down.d never gets called, for some reason.
  
  # Hooks into DHCP or D-BUS will catch only changes in local IP address, not public IP address ?
  

  Made a Python program (ipwatch) that polls for changes to public IP address, but polling is an ugly solution.
  
  https://askubuntu.com/questions/38733/how-to-read-dbus-monitor-output
  https://stackoverflow.com/questions/11544836/monitoring-dbus-messages-by-python
  https://dbus.freedesktop.org/doc/dbus-python/tutorial.html
  
  Windows:
  https://www.groovypost.com/howto/automatically-run-script-on-internet-connect-network-connection-drop/
  https://www.windowscentral.com/how-create-automated-task-using-task-scheduler-windows-10
  https://docs.microsoft.com/en-us/configmgr/apps/deploy-use/create-deploy-scripts
  
  
• Mostly for curiosity, see who owns the IP address you're using:
  
  Get IP address, maybe from WhatIsMyIPAddress.
  On Linux:

  
  host IPADDRESS
  nslookup IPADDRESS
  dig -x IPADDRESS
  

  
  
• Do services report your IP address as belonging to a VPN ?
  
  IPQuery and see "is_vpn" field.
  
  

• Windscribe custom client application. (Easiest and get all features.)
• Manual steps using Powershell and Windows Settings UI.
  Windscribe's "Windows Setup Guide"
• Manual steps using only Windows Settings UI.
  Windscribe's "Windows Setup Guide"
• OpenVPN client application plus config file. (Don't get firewall ?)
  Mike Williams' "How to setup and use OpenVPN"
  Reference manual for OpenVPN 2.4

sudo apt install strongswan network-manager-strongswan libcharon-extra-plugins

Gateway address from ping es.windscribe.com
Authentication = EAP.
Username from Windscribe.
Enable "Request an inner IP address".
Enable "Enforce UDP encapsulation".
Click "Add" button.
Copy password into clipboard.
Move slider to enable VPN.
Paste password into dialog.


Password is NOT remembered once the IKEv2 connection profile is set; you have to type it in each time you connect.

Connection is unreliable for some sites.
sudo gedit /etc/strongswan.d/charon/kernel-netlink.conf
# and after line "# mtu = 0" add:
mtu = 1300
# then reboot
# that helped a bit, but still not 100%

Logged into Windscribe account and got openvpn_cert.zip (contains ca.crt and ta.key files) and Windscribe-*.ovpn files and username and password.
Move the ca.crt and ta.key files to somewhere permanent; Network Manager seems not to keep its own copies of them.

sudo apt install network-manager-vpnc   # doubt this is needed

Go to Settings / Network / Wired.
Click "+" next to VPN.
Click "Add from file".
Select the Windscribe-*.ovpn file.
See dialog; Gateway field should be populated, Authentication type = Password.
Type in username and password.
CA certificate field should be a .pem file.
Click Advanced.
Under General tab: enable "Randomize remote hosts".
Click TLS Authentication tab.
Under "Additional TLS authentication ..." should be Mode = TLS-Auth, Key-file = ta.key, Key Direction = 1, Extra certificates = ca.crt.
Click Okay.
Click Add.

Move slider to enable VPN.
In upper-right of desktop, see white rectangle "VPN" appear !
Do browser leak-tests.

After reboot, OS does not reconnect to VPN automatically.
Do "sudo nm-connection-editor" to set that.
Now after reboot, OS does not reconnect to wired ethernet automatically (!), but when you manually turn on wired ethernet, it WILL reconnect to VPN automatically.
Behavior is different for Wi-Fi ? Will connect to Wi-Fi automatically, but won't reconnect to VPN automatically ? Not sure.

Later, Windscribe sent me some configuration files, one per VPN server. They're .txt files that each have a complete Network Manager (or is it OpenVPN ?) VPN definition in them. [They're OpenVPN "unified connection profile" files, sometimes named with .ovpn extension; see OpenVPN's "Connection Profile creation" and Reference manual for OpenVPN 2.4.]
Do Settings / Network / VPN + / Import from file, give it one of these files, type in your username and password, done.
[nm-connection-editor will export a VPN connection to a file, but only for OpenVPN connections.]

Password is remembered once the OpenVPN connection profile is set; don't have to type it in each time.

sudo apt install wireguard
sudo modprobe wireguard
lsmod | grep wireguard
sudo ls /etc/wireguard

# 5/2020: I think no Network Manager GUI support yet;
# can't click "+" to create a WireGuard connection profile

nmcli connection add type wireguard ifname wg0 con-name Winds-WireG-Spain
# profile doesn't appear in Network Manager GUI
nmcli --overview connection show Winds-WireG-Spain

sudo apt install wireguard
# rebooted, not sure if needed

nmcli connection import type wireguard file Winds-WG-Mad.conf
nmcli connection show Winds-WG-Mad | less
# works

• WAN connector: connects to outside copper cable or fiber or phone line.
• Modem: from WAN connector, converts outside signal to internal/Ethernet, sends to router.
  [Fiber modem may be called an ONT (Optical Network Terminal).]
• Router: intelligence that converts between internal (LAN) and external (WAN) IP addresses, usually using NAT, often including a stateful firewall. Handles IP addresses, uses subnets, operates at L3 and L4 levels. Services to LAN clients: DHCP, uPNP.
• LAN Switch: connects all the parts of the local network: LAN side of router, Ethernet ports, Wi-Fi AP. Handles MAC addresses, learns what MAC addresses are on each port, operates at L2 level, does ARP and RARP. But article.
• LAN Ethernet connector: wired connection to client device in home.
• Telephone connector: wired connection to telephone in home.
• TV connector: wired cable connection to TV in home.
• USB connector: for a disk drive to be shared on the LAN.
• Wi-Fi access point: wireless connection to Wi-Fi devices in home.

• IP layer (with IP addresses, which are assigned by software or by router or by authorities).
  
  
• Link layer (with MAC addresses, which are permanent in hardware).
  
  

1. In your computer, your browser forms an HTTP request and gives it to TCP layer, saying: "send to IP address N.N.N.N".
   [Ignore how (DNS) a web-address is looked up to find IP address.]
   
   
2. TCP layer forms a TCP packet: TCP header followed by data (the HTTP request). The TCP header contains port numbers and flags and other info.
   
   
3. TCP layer gives TCP packet to IP layer, saying "send to IP address N.N.N.N".
   
   
4. IP layer forms an IP packet: IP header followed by data (the TCP packet). The IP header contains the IP addresses and other info.
   
   
5. The IP layer does a check of destination IP address N.N.N.N:
   
   
   • If special address such as localhost (127.0.0.n), the traffic is handled internally by software.
     
     
   • If source and destination IP addresses are on the same subnet (destination is in the LAN), the IP address should be found in the ARP table, and it gives MAC address DD:DD:DD:DD:DD:DD for the destination.
     
     
   • Otherwise, the IP layer picks destination MAC address RR:RR:RR:RR:RR:RR (the router).
     [This mapping was established earlier by ARP mapping "gateway" IP address to MAC address.]
     
     
6. IP layer gives IP packet to link layer, saying "send to MAC address" (DD:DD:DD:DD:DD:DD or RR:RR:RR:RR:RR:RR).
   
   
7. Link layer adds its own header, forming a frame. Then frame goes across the LAN (Ethernet or Wi-Fi) from MAC address CC:CC:CC:CC:CC:CC (your computer) to destination MAC address. At other end, link layer strips off the link header.
   
   
8. If the destination was the router:
   
   
   • The IP layer in the router does a lookup of IP address N.N.N.N in rules for IP address ranges. In simplest case, only rule is "send everything out to WAN". But there could be firewall rules, segmented LAN, etc. And DHCP table here serves as backstop for source machine's ARP table ?
     
     
   • If the destination IP address is outside your LAN (on public internet), the lookup finds that packets to IP addresses in that range should be sent to the device at MAC address II:II:II:II:II:II (the ISP's router).
     
     
   • Packet goes out (through a link layer again) through the modem to MAC address II:II:II:II:II:II.
     
     

• Modem (owned by ISP or by you) + router (owned by ISP or by you).
• Combined modem/router (owned by ISP or by you).
• Modem (owned by ISP) + router (owned by ISP) in "bridge" mode + router (owned by you).
• Combined modem/router (owned by ISP) in "bridge" mode + router (owned by you).

• You will be paying monthly rent for the pieces owned by the ISP.
• The pieces owned by the ISP could be used by the ISP to spy on you.
• The ISP may be slow to update firmware and software in their pieces to latest versions.
• Likely you can't install new software on the pieces owned by the ISP.
• Likely the ISP's standard software will not have features you could get through new software, such as VLANs, guest Wi-Fi networks, firewall, VPN, more.

• Custom from ISP or router manufacturer (often based on some form of Linux, but could be VxWorks or other).
  
  Consumer routers have a lot of custom code, and often some very old version of the Linux kernel, that doesn't get a lot of inspection, except by bad guys. And they are using small amounts of slow RAM/flash.
  
  Danny Bradbury's "Home Routers Are All Broken, Finds Security Study"
  
  
  
• DD-WRT
  Easy Linux tips project's "DD-WRT on your router"
  
  
• OpenWrt
  
  
• Asuswrt-Merlin
  
  
• Tomato
  
  Easy Linux tips project's "Tomato: set your router free"
  
  
• pfSense
  
  
• OPNSense
  
  
• IPFire (review)
  
  
• Generic *nix.
  
  Summarized from 2.5 Admins episode 07 (7/2020):
  Just install vanilla Ubuntu (server, I guess) or FreeBSD on an old generic PC, with 2 or more Ethernet ports. Run iptables, BIND 9 or Unbound for DNS, ISC DHCP server, NAT through iptables ( article1, article2 ). That's faster even than running pfSense on the same hardware. "sudo apt install unattended-upgrades". But also you need to add a Wi-Fi access point (Ubiquiti UniFi AP AC Lite, or better TP-Link).
  
  
  

• Gigabit Ethernet (1000 Base-T), not just "Fast Ethernet" (100 Base-T).
  
  
• Number of Ethernet LAN connectors.
  
  
• VLANs: ability to put devices on separate VLANs where traffic does not pass between VLANs. You want this enforced in the switch/router, not just by packet-tags applied in each client device.
  
  
• Guest networks: multiple Wi-Fi network names and passwords (and once devices log in, they're on separate LANs where traffic does not pass between LANs).
  
  
• WPA3. Starting to become available at end of 2018.
  
  
• IPv6. But your ISP and VPN may not support this.
  
  
• Compatibility with / support for running a VPN client in the router.
  
  
• Compatibility with / enough processing power and RAM to run a custom OS (DD-WRT, Tomato, pfSense, etc).
  
  
• Firewall: ability to control traffic by MAC address, IP address, TCP/IP port number, maybe import lists of rules from elsewhere.
  
  
• Incoming port forwarding.
  
  

• WPS.
  
  
• Remote management.
  
  
• PNP.
  
  
• Any telemetry or "phone home" features.
  
  

• Level 3 (packet filtering): filter by IP address, port number, and protocol type (TCP, UDP, ICMP) ?
  
  
• Level 4 (stateful filtering): filter TCP and maybe UDP by connection and session state.
  
  
• Level 7 (application level): understand application protocols such as FTP, SMTP, Telnet, HTTP, etc.
  
  
• WAF: Web Application Firewall (understand HTTP and associated).
  
  

• A layer in OS networking stack on client computer (so each computer in the house has to install it).
  
  Martin Brinkmann's "Block all outbound traffic in Windows Firewall"
  
  
• In router used by all client devices in the house.
  
  Most consumer routers have some set of firewall features built into them, but they're generally closed-source, limited processor power, limited features.
  
  Recommended firewall software: pfSense or a fork of it with much more added: OPNSense. (Useful tool: pfFocus)
  
  Router specifically built to run pfSense: Protectli "Vault".
  Intel Techniques' "Episode 166 - Home Firewalls Revisited" (audio) (about running pfSense, VPN, and pfBlock on a Protectli)
  
  IPFire (review)
  
  Andy O'Donnell's "How to Enable Your Wireless Router's Built-in Firewall"
  Tom Lawrence's "Getting started with pfsense 2.4 Tutorial" (video)
  
  
  
• An appliance for a specific purpose (such as a WAF to protect a web server).
  
  
• An old computer with multiple Ethernet ports.
  
  

• Best way: a leak-test site such as Do I Leak ? will tell you what DNS server actually is being used.
  
  
• On Linux:

  
  systemd-resolve --status
  nmcli dev show | grep DNS
  resolvectl status
  resolvectl query SOMEDOMAIN
  nslookup SOMEDOMAIN
  resolvectl statistics   # see DNS cache statistics
  # cache is limited to 4096 entries
  # Firefox has its own very transient DNS cache in front of this one
  
  cat /etc/resolv.conf
  cat /etc/nsswitch.conf
  cat /etc/nsswitch.conf | grep hosts    # DNS order of checking
  cat /etc/sysconfig/network/config      # man netconfig
  
  nmcli dev show tun0       # and see GATEWAY
  systemd-resolve --status  # and see "Current DNS Server" for "tun0" device
  
  pidof dnsmasq
  dnsmasq --test
  
  # LAN mDNS/DNS-SD only ?
  # AKA "Zeroconf"; "Rendezvous" or "Bonjour" protocol.
  sudo systemctl status avahi-daemon --full --lines 1000
  avahi-browse --cache --all
  mdns-scan
  dns-sd
  man systemd.dnssd
  
  # Used by Windows clients:
  man llmnrd
  llmnr-query google.com    # ???
  

  Baeldung's "Difference Between resolve.conf, systemd-resolve, and Avahi"
  Fabien Sanglard's "mDNS Primer"
  daenney's "Getting rid of Avahi"
  
  
• Open a command prompt and run "nslookup google.com". First address shown is your DNS's address. But an IPv4 address that starts with "10.", "127.", "172." or "192." likely is an "internal" address, meaning that something in your computer or VPN client or router is grabbing that address and mapping it to something else. See Tim Fisher's "Private IP Address".
  
  

• If/when you're using a VPN, use the VPN's DNS. That way all DNS traffic is inside the VPN's encrypted tunnel, and your ISP or eavesdroppers can't see it.
  
  Important: you want your system to be accessing the DNS through the VPN, not directly. If the DNS address specified in your system is something like 10.x.x.x, it's going through the VPN tunnel (good).
  
  
• When the VPN is off:
  
  
  • Probably might as well just use your ISP's DNS, since the ISP is going to see all the IP addresses you access anyway.
    
    But instead you could:
    
    
  • Avoid a DNS owned by a data-collector (e.g. Google 8.8.8.8 and 8.8.4.4).
    
    
  • Use a DNS owned by a service that is fast and supposedly doesn't log traffic (e.g. Cloudflare 1.1.1.1 and 1.0.0.1, Quad9 9.9.9.9, OpenDNS 208.67.222.222).
    
    
  • Use a DNS that will block malware and/or adult sites (e.g. Cloudflare 1.1.1.3 and 1.0.0.3).
    Cloudflare's "Introducing 1.1.1.1 for Families"
    DNS0.EU
    
    
  • Use an encrypted connection to DNS to prevent your ISP from redirecting you (if ISP is malicious), or to prevent someone on your LAN (which may be public Wi-Fi) from modifying your DNS results.
    
    

1. Turn off VPN.
   
   
2. Run Do I Leak ? to see what DNS server is being used.
   
   
3. In router:
   1. Login to router's admin page.
   2. You may have to set "expert mode".
   3. Look for any DNS settings.
   4. My Vodafone router only has a "Secure DNS" setting. The text for this implies that it overrides DNS settings in individual devices, but I'm not sure. Turning it off did not let me specify a DNS server address. Turning it off did not make Linux use its own DNS settings. Power-cycling router didn't help.
   Tim Fisher's "How to Change DNS Servers on Most Popular Routers"
   Haidar Ali's "Using a Specific DNS for a Specific Domain in Linux"
   
   
4. Run Do I Leak ? to see what DNS server is being used.
   
   
5. In Linux Ubuntu/Mint:
   1. Click on network icon in system tray and choose "Network Settings".
   2. Click on the network interface (Wi-Fi or Wired).
   3. Click on "gear" icon in lower-right.
   4. Click on "IPv4".
   5. In the "DNS - Server" field, put the value you want, such as "1.1.1.1".
   6. Set the "DNS - Automatic" switch to "off".
   7. Click on "Apply".
   8. Close "Network Settings" app.
   9. Click on network icon in system tray and turn the network interface (Wi-Fi or Wired) off and then back on.
   10. Reboot.
   11. Didn't work, still using ISP's DNS.
   12. Later set DNS on other network interface, and got different results ? Have to do both same way ?
   Another try:
   1. Edit "/etc/network/interfaces" as root, add line "dns-nameservers 1.1.1.1".
   2. Run "cat /etc/resolv.conf"
   3. Reboot.
   4. Run "cat /etc/resolv.conf", now new line appears in it.
   5. Didn't work, still using ISP's DNS. [Maybe have to edit /etc/NetworkManager/NetworkManager.conf and add "dns=none" in [main] section ?]
   Ended up worse than before: now, with VPN on, I'm getting a DNS leak to 1.1.1.1. Removed the line from /etc/network/interfaces and rebooted, that fixed it.
   
   Maybe should remove "nameserver 127..." line from /etc/resolv.conf somehow ?
   
   In Linux, some apps use /etc/resolv.conf file directly. Other apps use glibc's NSS functions, which talk to systemd-resolved. "systemd-resolved is a DNS stub. In other words, it's a local, caching, recursive-only DNS server. It brings features to GNU systems that the standard DNS resolver client doesn't have, such as DNSSEC support and rich lookup policies for multi-homed systems." "systemd-resolved will manage /etc/resolv.conf in its standard configuration".
   
   Baeldung's "Difference Between resolve.conf, systemd-resolve, and Avahi"
   Chris Siebenmann's "Things that systemd-resolved is not for (as of systemd 251)"
   Unix Sheikh's "How to split your DNS requests when using a VPN"
   
   
6. In Windows:
   1. ???
   Mauro Huculak's "How to configure Cloudflare's 1.1.1.1 DNS service on Windows 10 or your router"
   
   
7. In Android:
   1. Turn off VPN.
   2. XSLab's "How to Change DNS Settings on Android"
   3. Followed the "long-press on Wi-Fi network" instructions, everything fine except you really have to specific static addresses for phone (maybe 192.168.0.128) and router/gateway (maybe 192.168.0.1).
   
   
8. Run Do I Leak ? to see what DNS server is being used.
   
   
9. In Firefox:
   1. Click on hamburger icon / Preferences.
   2. Click on General.
   3. Scroll to bottom, click on Network Settings.
   4. In "Configure Proxy Access to the Internet", click on "No Proxy".
   5. Scroll to bottom, click on "Enable DNS over HTTPS", set "Use Provider" to desired value.
   6. Didn't work, now getting DNS requests from both the provider I chose AND from my ISP's DNS. One request from provider, plus N from ISP's DNS. Could be that first is for the main page and then others are for images/scripts on the page ?
   
   
10. In Chrome / Chromium:
    1. ???
    
    
11. Run Do I Leak ? to see what DNS server is being used.
    
    
12. Turn VPN back on.
    
    
13. Run Do I Leak ? to see what DNS server is being used.
    
    

dig -f dig-input.txt | grep -E 'Query|SERVER'

Various flavors of encrypted connection to DNS

• Plain DNS: connection between Browser/OS and DNS is not encrypted.
  
  
• DNSCrypt:
  DNSCrypt
  Supported by DNSCrypt-Proxy and OpenDNS clients.
  
  
• DNS-over-TLS: new.
  Supported by Quad9 and OpenDNS clients.
  rfc7858
  
  
• DNS-over-HTTPS (DoH): new.
  Being tested by Mozilla/Firefox, servers provided by Cloudflare and Google.
  Supported by DNSCrypt-Proxy client.
  Catalin Cimpanu's "How to enable DNS-over-HTTPS (DoH) in Firefox"
  Martin Brinkmann's "Configure DNS Over HTTPS in Firefox"
  
  From someone on reddit:
  "Doing DNS requests is the task of the OS not an application, I really dislike this behavior [DOH in Firefox]. An application will not respect any rules in my hosts file and this will prevent me from having local servers with (fake) domain or blocked domains." [Instead, use a DNS proxy.]
  
  
• Oblivious DNS-over-HTTPS (ODoH): new.
  Have an encrypted (TLS) connection to a DNS server, but run it through a proxy that hides your IP address.
  This is better than DoH only if the companies running the proxy and the DNS are different and don't share info with each other.
  
  
• Just use a VPN, and use their DNS: then the connection to DNS doesn't matter, it's all protected by the overall VPN encryption. But make sure you ARE using their DNS through their tunnel; it should have a non-public address such as one starting with 10 or 172 or 192. And ask if their DNS is using DNSSEC to talk to other DNS servers; it should be.
  
  
  

Test with:
Do I Leak ?
Cloudflare's "Browsing Experience Security Check" (ESNI/ECH)
DNSSEC Resolver Test

Sean Gallagher's "How to keep your ISP's nose out of your browser history with encrypted DNS"
DNSCrypt
DNSCrypt Proxy
Domain Name System Security Extensions (DNSSEC)

1. User runs Tor Browser.
   
   
2. In the background, a Tor SOCKS5 proxy is launched, listening on localhost TCP port 9050 or 9051. If first time this is run, a set of guard nodes is chosen, and will be used for some months.
   
   
3. Tor proxy establishes a circuit (picks a list of relays/nodes). Assume this consists of 3 onion relays (it can be more ?). The exit relay is chosen first, gated by settings in the torrc file, what port/protocol is needed, and how busy the relays are. Information about all nodes/relays (except bridge nodes) in the onion network is maintained by a set of 9 directory nodes.
   
   
4. User types an address into Tor Browser.
   
   
5. Tor Browser sends HTTP GET message to Tor SOCKS proxy.
   
   
6. Tor SOCKS proxy sees that address is for a clearnet site:
   
   
   1. Tor proxy encrypts message with key of third relay in the circuit, then encrypts that result with key of second relay in the circuit, then encrypts that result with the key of the first relay in the circuit.
      
      
   2. Tor proxy sends triple-encrypted message to first relay in the circuit.
      
      
   3. If a Pluggable Transport and a Bridge node are being used, the PT transforms the message to look less Tor-like.
      
      
   4. First relay ("guard relay", may also be a Bridge node) decrypts outermost layer of encryption, finds address of second relay, sends contents to there.
      
      
   5. Second relay ("middle relay") decrypts outermost layer of encryption, finds address of third relay, sends contents to there.
      
      
   6. Third relay ("exit relay") decrypts outermost layer of encryption, finds address of clearnet web site, sends contents to there.
      
      
   7. Clearnet web site gets the message. Source IP address is the IP address of the exit relay.
      
      
7. Else: Tor SOCKS proxy sees that address is for a onion site (Tor Hidden Service):
   
   
   1. When onion site was created, it chose one or more nodes as Introduction Points. Then all other nodes were told about this association: onion address to Introduction Points. Each of the onion site's circuits to the Introduction Points have guard node and middle node in them.
      
      
   2. Tor proxy chooses some node as a Rendezvous Point.
      
      
   3. Tor proxy makes a circuit (with guard node and middle node) to the Rendezvous Point, and asks it to contact the Introduction Point for Tor Hidden Service X.
      
      
   4. The Rendezvous Point asks one of the Introduction Points to contact the Tor Hidden Service X.
      
      
   5. The Tor Hidden Service creates a new 3-hop (guard, middle, exit) circuit back to the Rendezvous Point.
      
      
   6. Tor proxy encrypts message with six layers of encryption: for guard, middle, rendezvous, then exit, middle, guard to onion site.
      
      
   7. Tor proxy sends sextuple-encrypted message to first relay in the circuit.
      
      
   8. Each relay/node strips off a layer of encryption.
      
      
   9. Onion web site (Tor Hidden Service X) gets the message. Source IP address is the IP address of the guard relay chosen by the Tor Hidden Service.
      
      

• Tor Browser and normal OS: Only activity from Tor Browser goes through onion network; all other traffic goes out normally (and your home IP address is revealed to destination servers). ISP sees that you're using onion network, and sees the destination IP addresses on your other traffic.
  
  This is a bad configuration: For your non-onion traffic (from services, and apps other than Tor Browser), your ISP is seeing the destination IP addresses, and your home IP address is being revealed to the destination servers.
  
  
•    Tor Browser and normal OS and VPN (AKA "Tor over VPN"): All traffic (Tor and other) goes out through VPN; activity from Tor Browser then goes through onion network (after coming out of VPN server). ISP sees that you're using VPN, but can't tell anything else.
  
  This is a good configuration: All your traffic is protected from your ISP and the destination servers, one way or the other. And for your Tor Browser traffic, the VPN knows your ID but only sees that your destination is an onion entrance node, it doesn't know your final destination.
  
  VPN doesn't help or hurt the Tor traffic. VPN is there to protect the non-Tor traffic.
  
  
• Normal OS and an onion connector (e.g. nipe or Orbot or TorGhost etc): All network traffic goes through onion network. ISP sees that you're using onion network.
  
  This is a somewhat-good configuration: All your traffic is protected from your ISP and the destination servers, but you're paying a performance cost by using the onion network for everything. Also you can't do UDP through onion network.
  
  
• Custom OS and an onion connector (e.g. Tails, Kodachi, Subgraph OS, Whonix): All network traffic goes through onion network. ISP sees that you're using onion network.
  
  This is a somewhat-good configuration: All your traffic is protected and there may be other security and privacy features, but you're paying a performance cost and running an uncommon OS that may lack features or support. Also you can't do UDP through onion network.
  
  
• Normal OS and a VPN and then an onion connector (AKA "VPN over Tor"): All network traffic goes through onion network, then to VPN server. ISP sees that you're using onion network.
  
  This is a bad configuration: You're losing any benefit from the onion routing, the VPN knows your ID and sees the final destination of your traffic.
  
  

ExitNodes {es},{ie},{fr} StrictNodes 1
ExcludeNodes {us},{ca}

• Give identifying info: if you tell a site your name and address, then do something illegal, and the police have compromised the site, or later it gets breached, you're caught.
  
  
• Caught outside Tor/onion: if the shipment of drugs is detected by Customs or post office, police may watch the delivery address to catch whoever picks it up. Or police seize your computer for some other reason, and do forensic analysis on it. Or your payment method reveals your identity.
  
  
• Traffic correlation: if you use Tor on school LAN to send a bomb threat about the school, police may check to see who was using Tor on the school LAN at the time of the threat. You may be the only person who was doing so.
  
  
• Download something malicious: if you download and run an EXE or script, it doesn't matter that you were using Tor when you downloaded it. That executable can send your info, maybe including home IP address, to any server. Even usually-harmless file types such as PDF or JPEG or MPEG or Office docs have been used in attacks. At the very least, scan them for malware, and take the docs to another machine (or a VM) that has no internet access before opening them.
  
  
• Not using Tor every time: if you do some connections insecurely, you may be caught.
  
  
• Not keeping Tor Browser updated: occasionally security holes are found, and fixed. But if you continue to run an old vulnerable version, you may be caught.
  
  
• Keeping evidence: it's probably good OpSec to replace your devices, or at least wipe them, periodically or after some big transaction. Or boot a transient OS such as Tails, although you'll still be using (for example) the MAC address built into your system's hardware, maybe your home LAN and router, etc.
  
  
• Unwilling to pay the price for good OpSec: for example maybe never do anything illegal from your home LAN. It's a pain to always go out to public Wi-Fi, but if you don't pay that price, you may get caught.
  
  
• Trusting someone, or boasting to someone: if they get mad or get pressured, you may get caught.
  
  
• Confessing as soon as you're questioned: just because the police question you, or even arrest you, does not mean they can convict you. If you confess, you're caught.