Tag: network

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

“Switching” to IP fabrics – Namex Bits

At the beginning of 2021, Namex IXP has started the rollout of its next-generation peering platform, the active infrastructure which is at the core of its network interconnection facility. This new platform relies on an IP fabric design with VXLAN as the overlay network and BGP EVPN as the control plane protocol. The development of this project started back in March 2020 and saw Mellanox and Cumulus Networks (both parts of NVIDIA corporation now) as major technological partners.

Before diving into the details, a brief historical note may help to understand the drivers and motivations behind such technical choices.

More at “Switching” to IP fabrics – Namex Bits – https://blog.namex.it/2021/04/switching-to-ip-fabrics/

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

Increasing Port Density in Data Centers | Network Computing

Demands for connectivity in the data center are rising, especially in hyperscale data centers where 1728- or 3456-fiber cables are becoming more popular. Connecting such high-fiber-count cables to servers and switches is the key challenge because there’s only so much rack space available. Fiber patch panels are at the center of this challenge. To address this issue, the industry is increasing port density in patch panels to accommodate the ongoing thirst for bandwidth.

Source: Increasing Port Density in Data Centers | Network Computing

Hands-on with Intel Co-Packaged Optics and Silicon Photonics Switch – ServeTheHomeVideo

Hands-on with Intel Co-Packaged Optics and Silicon Photonics Switch
Watch this video on YouTube.
We get some hands-on time in the Intel lab with their new switch. Based on the recently acquired Intel Barefoot Tofino 2 switch ASIC, we see the world’s first (publicly shown like this) working set of switches using both silicon photonics as well as co-packaged optics. We also explain why pluggable optics will be going away in future generations of network switches as they will consume too much power in the 51.2Tbps generation of switches.

Problems with a IPv6 only network – Ben’s Place

In my last post I talked about running a pure IPv6 network, as part of my ISP building project, but still allowing access to resources on the internet currently only available via IPv4.This works well assuming all the clients on the local network are IPv6 capable, unfortunately this is not always the case. There are legacy devices that do not understand IPv6.This is a real problem with IoT devices that are either no longer being maintained or just that have hardware that is incapable of using anything other than IPv4. There is also a small problem that a IP cam with a IPv6 address is probably available to the world with out some firewall rules or a ACL limiting access to the local /64, but those are problems for another day…Another issue is hard coded IPv4 addresses in legacy applications, this is a problem even if the OS/device supports both IPv4 & IPv6 but is only connected via IPv6.There is are a few of solution to both these problems.

Source: Problems with a IPv6 only network – Ben’s Place

Proactive Network Configuration Validation with Batfish – NANOG (2015) Presentation

Proactive Network Configuration Validation with Batfish

Watch this video on YouTube.

Batfish is an open-source network configuration analysis tool in active development produced jointly by researchers at University of California, Los Angeles; University of Southern California; and Microsoft Research. Though its individual modules have various applications, its primary purpose is to detect bugs in network configurations. Batfish takes as input a set of network configurations, and an environment, which consists of a set of (in)active links and a set of external BGP advertisements. Users are able to ask customized queries about the control plane using Batfish’s domain-specific query language e.g. whether all loopback addresses are being advertised into OSPF, or whether all route policies attached to eBGP neighbors apply a particular community to incoming routes. Batfish also is able to compute the convergent data plane for a network, which provides further query facilities. Given the data plane, users can employ an off-the-shelf data plane checker or use Batfish’s data-plane queries to check common properties such as reachability/black holes, loops, etc, as well as novel properties (introduced at NSDI’15) regarding equivalence of multipath routes, fault-tolerance, and unique delegation of customer address space, with more to come.