How do I protect my data from my ISP

I am trying to use this guide: Set up a Hardened OpenVPN Server on Debian 9 | Linode, but it’s lost me. Also I noticed that there is an OpenVPN section in PFSense’s gui settings. I imagine that that will make the task of setting up my router as an OpenVPN client easier, or is it meant to set up PFSense as an OpenVPN server ?

1 Like

Not wanting to drag this post too far off topic, but what bit do you get stuck in?

I just skimmed the first bit, setting up the server on a linode, and it seems pretty thorough

I should also mention that I rebuilt my Linode as the OpenVPN AS one-click app. I didn’t know how it was configured before and how to finish setting it up. Then it suddenly stopped working. I started messing around trying to figure out what was going on with it. I noticed that while the OpenVPN repository was enabled in the Debian system, the OpenVPN package itself wasn’t installed. Nor was OpenVPN configured. I’m in a rabbit hole now because apparently OpenVPN as is a different app than OpenVPN. I am still slightly confused, but less so. If I can figure out how to get OpenVPN AS working again that would be perfect cause then maybe I can use the PFSense configurator on my LAN network to easily connect the two. Another thing I would like to do is make the OpenVPN AS web configuration more secure and convenient by routing http://localhost:943 to a subdomain that is pointed to the server and also removing the self-signed cert in favor of one from Let’s Encrypt. (I have another Linode with a full on LEMP stack that I manage myself, so I am fully capable of doing this. I just don’t know anything about the OpenVPN AS configuration. Also, I can think of a way to do this by setting up Nginx as a reverse proxy I guess, but idk if the self-signed nature of OpenVPN AS operating on port 943 will cause issues).

P.S I am not SSHed directly into root. RootLogin over SSH is not permitted on the system. Instead I am logged into my user, and elevated to root via the su command.

1 Like

do you mean, OpenVPN is a different app then the installed / failed OpenVPNAS then yeah, different apps by same team. I didn’t look thru the AS page.

for cert, you can do all that, but if no-one is to access the linode end point, kinda unessecary?

I’m not sure which app calls the program pyovpn, it could be during the OpenVPNAS setup, will skim through the guide linked to the guide which you linked to.

In the mean time, did you get the OpenVPN working as non AS?

the instructions are long / not a single step, but what can you do?

I’ve got to shoot off to work, but the linode instructions you linked looked good.

when I did it, I followed this guide:

using the Nyr github, and it worked okay, except one device (ubuntu tablet) wouldn’t take the config files / wouldnt load a vpn profile.
I ended up just using a pi as a wifi access point for the tablet, and making all traffic on the pi go thru the vpn.

On the concern about using UDP, HTTP3 (which is basically HTTP2+QUIC over UDP/443) is in use by a lot of large web properties such as Google/YouTube, Facebook, Cloudflare, etc.

Here’s a survey which claims ~20% of websites currently support it:

https://w3techs.com/technologies/details/ce-http3

Given that reality, I doubt many ISPs would choose to blindly throttle UDP, or UDP/443 specifically. It’s possible that ISPs will put large properties’ IP networks on whitelists and leave what’s left over to be throttled, but it seems like that would be easy enough to test.

Also, UDP-based VPNs will generally always have better performance than TCP-based ones. Both UDP and TCP assume that they sit on top of the unreliable Data Link layer (i.e., Ethernet in most cases), so being tunneled inside a reliable protocol such as TCP poses problems due to outer windowing, retransmits, etc. Not to mention the UDP protocol itself is just way lighter.

1 Like

I noticed the other day that my phone browser keeps flip-flopping between quic and tcp as I switch between wifi and cellular.

I ran these tests a few times: NGINX QUIC Sandbox

From there, I’m extrapolating that it’ll be a good while / long time until http over TCP starts dying.

Those major websites you mentioned still offer http1.1/http2 over TCP 443 and browsers will still not blindly switch to UDP.

It’s possible there will be networks that are blocking 443 UDP for a long time, because most things will continue to work regardless.

So I gave up on OpenVPN and moved to WireGuard and it is 10 times easier. I actually understand what I am doing. I’ve ran into a problem though. My PFSense Box’s Firewall filter is preventing me from connecting even though I’ve tried to disable it for Wireguard. I’m also including the two Wireguard Peers’ config output:

# Server
interface: wg0
  public key: 8qNBNMogkKaATh9xrr5OHWe6J8tCq77RlNsjJ3oq/1U=
  private key: (hidden)
  listening port: 51820
  fwmark: 0xca6c

peer: B0M0dA6cKroV/6pq4XorQ1x/lpCkxoxavAMm5z5rPWI=
  allowed ips: 10.0.0.2/32
# Client
interface: tun_wg0
  public key: B0M0dA6cKroV/6pq4XorQ1x/lpCkxoxavAMm5z5rPWI=
  private key: (hidden)
  listening port: 51820

peer: 8qNBNMogkKaATh9xrr5OHWe6J8tCq77RlNsjJ3oq/1U=
  endpoint: 45.79.199.139:51820
  allowed ips: 10.0.0.1/32

Where my Linode VPS is referred to as the Server, and PFSense is referred to as the client.

Pinging the server with PFSense outputs the following

PING 10.0.0.1 (10.0.0.1): 56 data bytes
36 bytes from 96.120.19.17: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  20 0054 ae63   0 0000  3f  01 3dc4 68.35.65.62  10.0.0.1 

And the following are my relevant PFSense Firewall rules:


Allow All rules scare the crap out of me. Make sure you change that to internal / private IPs.

I think it might be a server config issue. Here’s my config on Linux, should be similar in pfSense (just that you config in a GUI).

Server:

[Interface]
Address = 10.1.1.1/24
PrivateKey =
ListenPort = 443
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey =
AllowedIPs = 10.1.1.2/32

Client:

[Interface]
Address = 10.1.1.2
PrivateKey =

[Peer]
PublicKey =
EndPoint = ip-or-domain-name:443
AllowedIPs = 10.1.1.0/24, 192.168.1.0/24
##the above rule makes it so that only traffic going to 
##those 2 networks will be pushed through the wireguard tunnel
##I'm not sure if you can add networks coming from behind the client too, never tried

##or if you want to push all the traffic through the VPN:
#AllowedIPs = 0.0.0.0/0

Obviously, ignore the iptables rules, unless you run linux on your server. Also, I haven’t tried to push networks from the client to the server (well, Wireguard doesn’t technically have a client-server architecture, but that’s how I used it), but I mostly didn’t need to when I was using NAT.

TBH I wanted to; and I tried to; but I don’t know how to. I am still learning how to use the PFSense GUI.

Yes, I run Debian 11 on my server. I am very comfortable in Linux land, and Debian was even my second Linux Distro (my first was Raspbian). BSD land, by contrast is a bit different. There is no /etc/wireguard in PFSense for example, and it does’t have it built into the kernel.

I don’t understand. I am using NAT here too afaik. I am still new to PFSense so if it doesn’t use NAT okay, and tbh I don’t fully understand NAT - just that it stands for Network Address Translation and has something to do with DHCP I think. Technically, my PFSense router/firewall is my network. There is no network behind it - unless I am misinterpreting what you mean.

As for my server side configuration, I’ve tweaked it a bit but here it is:

[Interface]
Address = 10.0.0.1/32
Address = fd86:ea04:1115::1/64
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
FwMark = 0xca6c
PrivateKey =

[Peer]
PublicKey = 
AllowedIPs = 10.0.0.2/32

I should mention that now I don’t even get an output when I ping the server with PFSense. It just fails, which tells me that maybe I’ve messed it up even more because it no longer tries to handshake? :man_shrugging:

Also I went back to my previous ping’s output and noticed that in the second line where it says 36 bytes from 96.120.19.17: Communication prohibited by filter

My ISP owns that IP Address…
And it wasn’t the public address of my PFSsense router at the time. I knew what that address was.

Edit: Indeed, if I replicate what I did to get it to produce that output, it replies with the same message with the exact same IP address (96.120.19.17). Therefore, I don’t think it is an issue within my internal network. Please don’t tell me that they’ve blocked port forwarding on 51820.

Interesting…

I own my own modem though. I refuse to pay for the garbage that is the XFi gateway.

1 Like

As for the network configuration stuff. Hmm… how should I explain in simple terms… When you create a VPN tunnel, you are creating a new subnet (that 10.0.0.0/24). So unless you are doing NAT on your pfSense box, or you don’t give additional routes to your Linux VPS, then only the “client” / other end of the tunnel itself will be able to talk with your VPS (so just pfSense itself).

On the pfSense side, you don’t need a listening port, only the VPS needs and they will negotiate a port, so you don’t need any port forwarding on your home router, because the client is smart enough. You only need to port forward when your router will act as a sever (other clients connecting to your home network), which is not what you want in this case.

Change the config in pfSense to not have any listening ports (but obviously keep the peer endpoint’s ip:port) and try to connect. Unless they outright block outbound connections on destinations with UDP port 51820, it should work. If pfSense will be able to ping the VPS internal wireguard IP, we have a working tunnel and we can do the rest of the network configuration (preferably just routes, so you could connect to your VPS on-the-go and go to your home network through it, because obviously it seems like your ISP is not allowing some port forwarding).

If that doesn’t work, set the VPS to listen on port 443 and set the Endpoint ip with port 443 in pfSense. It’s UDP 443, but still, I don’t think they’d block it outright.

Did we discuss anonymous DNS services yet? We are talking about firewalls, vpns, even TOR but what about DNS?

Im new to the topic of taking privacy and security seriously. I think you all know that. That being said, to my ignorance, I am learning there are many parts to the overall idea of protection. I have been using a vpn/firewall (hardware) for the first time. Then I came across some videos that stated even with these technolgies, you are not safe or secure online. One part being the ISP can still see your traffic, where it came from and where its going. This is why I did the following:

I got a vpn (software) that is outside the 14 eyes collab, I got a vpn firewall (hardware), and I started using an anonymous DNS service. (NextDNS)

I just wonder what more one needs to do to keep their searches and traffic content safe from companies?

1 Like

That’s how this started. I’ve been using NextDNS’ DoH and DoT service for a long time now… a little over a year as a matter of fact. But recently, I’ve discovered that that is not enough to protect your data from your ISP.

Read this post from earlier in the thread: How do I protect my data from my ISP - #19 by Biky

Where does DoH and DoT get the certificates and DNS records to begin? :thinking:

2 Likes

Offtopic, but Schematics or DIE :+1:

image

1 Like