Tag: Firewall

How-to VPN: Private Internet Access (PIA) and MikroTik Router

⚠ Information in this post is outdated since the launch of PIA’s ‘Next-Gen’ VPN network in 2020, sunsetting the then-existing set-up ⚠

First create a vpn profile to use when creating l2tp/pptp connections
to privateinternetaccess.

/ppp profile add change-tcp-mss=yes \
comment="PIA VPN" \
dns-server=209.222.18.222,209.222.18.218 \
name=privateinternetaccess only-one=no \
use-compression=no use-encryption=required \
use-ipv6=no use-mpls=no use-upnp=no

Create the l2tp interface

/interface l2tp-client add \
comment="PIA VPN Netherlands" \
connect-to=nl.privateinternetaccess.com \
disabled=no name=pia-de-l2tp \
profile=privateinternetaccess \
user=[l2tp-username] \
password=[l2tp-password]
  • [l2tp-username] Your PIA username for l2tp/pptp/socks connections beginning with ‘x’ (not ‘p’!)
  • [l2tp-password] Your PIA password for l2tp/pptp/socks connections

Create a firewall mangle rule to mark IPv4 traffic we want to
go through the VPN.

/ip firewall mangle add \
action=mark-routing \
chain=prerouting \
comment="PIA VPN Netherlands" \
new-routing-mark="PPTP RM" \
passthrough=yes \
src-address=[ip-range-to-forward-through-vpn]
    • <li

[ip-range-to-forward-through-vpn]

    Fx. 192.168.1.0/24 or 192.168.1.2-192.168.1.254

Create the NAT rule and tell it to use the VPN interface.

/ip firewall nat add \
action=masquerade chain=srcnat \
comment="PIA VPN Netherlands" \
out-interface=pia-de-l2tp

Create a corresponding default route to match the previous NAT
rule. Which only get used when IPv4 traffic has been marked with
‘PPTP RM’.

/ip route add \
comment="PIA VPN Netherlands" \
disabled=yes distance=1 \
gateway=pia-de-l2tp routing-mark="PPTP RM"

Now you should see traffic from clients in the IPv4 range
of [ip-range-to-forward-through-vpn] go through the VPN.

NB: If you want to use another country apart from Netherlands. Check out Private Internet Access list of locations here: PIA VPN Tunnel Network

WireGuard on pfSense

Netgate has “just” published their first blog post, describing official WireGuard support in the latest development snapshot of pfSense 2.5.0.

As a network engineer, routing enthusiast, technical supporter, and DN42 participant. Hearing about the upcoming WireGuard support for pfSense has me very excited due to the ease of use. And simplistic configuration. Making it – in my opinion – the most attractive VPN solution for P2P-mesh VPN network(s) and Road Warrior access on-the-go. Plus the support for WireGuard is close to ubiquitously supported on *most* major platforms via direct development support (& 3rd party software solutions).

Netgate mentioning – in their blog post – they have been a sponsor for the development needed to get WireGuard supported on FreeBSD has me thankful, even thou I am not a paying customer of theirs (i.e. a prosumer #wfh).

pfSense not having WireGuard support. When OPNsense introduced WireGuard (& ZeroTier) support months ago. Have had me seriously consider over the Christmas period to switching my prosumer firewall solution to OPNsense. Just for the VPN support of WireGuard & ZeroTier alone. Now, however… I am convinced to stick with pfSense for more years to come. And excitedly looking forward to the next stable release that will very hopefully include the recently announced WireGuard support. (/^▽^)/

Working with TC on Linux systems – dasblinkenlichten

With that out of the way – I wanted to spend some time in this post talking about the command line tool found on Linux systems called tc. We’ve talked about tc before when we discussed creating some network/traffic simulated topologies and it worked awesome for that use case. If you recall from that earlier post tc is short for Traffic Control and allows users to configure qdiscs. A qdisc is short for Queuing Discipline. I like to think of it as manipulating the Linux kernels packet scheduler.

Working with TC on Linux systems