mttaggart

morningreis

OPNsense + ProtonVPN + Wireguard

Published: 16 December 2022

Reference: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html

Goal: Set up one or more Wireguard connections from ProtonVPN on OPNsense, with policy based routing, and optional Killswitch.

I'm writing this guide first as a reference for my future self for when I inevitably forget how to do this, but also to help others out. I found there were not many guides on this specific configuration, particularly not with multiple concurrent connections, and these were some steps which were not at all obvious. I did begin with the guide in the official OPNsense documentation, but even that was missing info to make ProtonVPN work. If you are a pfSense user, it is very similar to OPNsense, and you should be able to follow along with some success, but I have not tested it myself.

kabili207

rclone systemd service

Preparation

This service will use the same remote name you specified when using rclone config create. If you haven't done that yet, do so now.

Next, create the mountpoint for your remote. The service uses the location ~/mnt/<remote> by default.

mkdir ~/mnt/dropbox

mcguinness

Problem Statement

The OAuth 2.0 Authorization Framework defines the authorization_code grant type and refresh token. It doesn't establish any rules for issuing refresh tokens and explicitly states in Section 1.5 that "Issuing a refresh token is optional at the discretion of the authorization server". One of the explicit goals for Rfc6749 was to enable offline access to protected resources when the end-user is not present. It does not define any request semantics for how a client can explicitly request a refresh token or whether that refresh token's lifecycle should be bound to the user's session that granted the refresh token. Authorization Servers are free to define these behaviors on a per-implementation or policy basis.

OpenID Connect being the identity layer ontop of OAuth 2.0 needed to define some new authorization server behaviors to enable end-user consent for when a client can access their identity info

HardenedArray

# OBJECTIVE:  Install Arch Linux with encrypted root and swap filesystems with an ENCRYPTED BOOT and boot from UEFI.  We will
also decrypt and mount our entire encrypted system using a single LUKS passphrase entry.

# Note:  This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system.

# External USB HDD/SSD Installers Notes:  Encrypted Arch installs can be booted and run from an external USB HDD or SSD, but
# only when the installation is correctly set up.  There are several necessary changes to my standard procedure you'll want
# to make during the install process.  Read my External USB HDD/SSD Installation section below before proceeding.

atoponce

Cryptographic Best Practices

Putting cryptographic primitives together is a lot like putting a jigsaw puzzle together, where all the pieces are cut exactly the same way, but there is only one correct solution. Thankfully, there are some projects out there that are working hard to make sure developers are getting it right.

The following advice comes from years of research from leading security researchers, developers, and cryptographers. This Gist was [forked from Thomas Ptacek's Gist][1] to be more readable. Additions have been added from

jpawlowski

# /etc/network/interfaces
#
auto lo
iface lo inet loopback

# device: eth0
iface eth0 inet manual

# IPv4 bridge
# (connect ONLY your firewall/router KVM instance here, this is the WAN device!)