Recently my ISP fixed the compatibility issues between their Huawei BRAS and my Junos router. After some digging, I managed to get some IPv6 address allocation for all my client devices. Here’s how I achieved it.
Disclaimer: This article assumes you have basic understanding on IPv6 as we are not going to dig into the very details of the IPv6 standards.
This article provides everything you need to setup a local DHCP server on a SRX security device.
Traditional point-to-point site-to-site VPN protocols require extensive setup in certain use cases. For example, if you want shortcuts between branch offices rather than let every packet go through the HQ, then you need to set up a cartesian product of tunnels by hand, which is time-consuming and error prone. So, people want something better, something easy to set up and maintain, and dynamic enough. While there are already a lot dynamic point-to-multipoint or full-mesh site-to-site VPN implementations (e.g. Tinc VPN, ZeroTier) on Linux, you don’t have many choices on these commercial black boxes.
Cisco DMVPN (Cisco Dynamic Multipoint VPN) is one solution to this. Huawei also had their DMVPN-compatible solution called DSVPN (Dynamic Smart VPN). Since the protocol is largely compatible, I’ll just reference it as DMVPN.
A SRX is a “security device”, or as we call it conventionally, a firewall. Modern layer-3 firewalls route packets just like a router, but unlike a router, a firewall can organize packets into connections (flows) and run ACLs on the entire flow. This unique functionality is the fundamental building block of every “advanced” security feature offered by a firewall: dynamic NAT (PAT/NPT), zone-based firewall (ZBFW), ACLs for in or out connections only, L7 filtering, etc. For the connection (flow) tracking to work, all the packets in a connection must go through the same device, and the 5-tuple of all the packets in a connection must be of expected values, which usually means:
- The packets from A to B and the packets from B to A must all go through the firewall at some point
- There shouldn’t be single-sided stateless NAT happening on the route
This was never an issue when everyone was single-homed and all the routers had only one routing table. But not today. SRXs now have built-in support for virtual routers which can create an asymmetric flow easily. Let’s look at this simplified topology:
When I was replacing all my buggy little MikroTik RouterOS boxes and VMs with some new shiny (and also buggy) Cisco ISR1000s and CSR1000vs a few years ago, there were several things that I missed so much that existed on the former but not on the latter. One of them was the “MAC Winbox” and “MAC Telnet” capability with which you can plug your maintenance workstation into the router with an Ethernet cable, fire up a Winbox, and it will let you configure the router through a layer 2 connection. It require no valid IP configuration, so it would work as long as you doesn’t shut down the port and there is no wild switch ACL in place. Newer routers have USB console ports, and I do have a console cable in my EDC, but a router’s ability to be configured without a console cable is still its big advantage to me.
Imagine my face today when I learned that Cisco routers (IOS and IOS XE) do support a layer 2 protocol with remote console capability. And the protocol is not new. The protocol is from the 1980s and IOS has been quietly supporting it for years. It has even been enabled by default for years. It is still being supported (as of IOS XE 17.2).
Two things happened in 2017:
Linux finally got native, working MPLS (L3VPN) and VRF support. 3 years later, a thorough documentation of MPLS configuration on Linux is still largely missing. Recently, after digging into all kinds of codes and documentation, I had a standard MPLS core network up and running in my lab. This article is a write-up for my lab setup.