This article is part of a series where I discuss dn42, a decentralized VPN and community for studying network technologies. You can find out more about dn42 on its Wiki: https://dn42.dev/

BGP and dn42 on a Windows Server

Earlier this month, I saw a hosting provider on LowEndTalk offer free Windows Server along with some fairly beefy VMs. As someone who's been running and administering Linux machines for several years now, I thought it'd be a cool experiment to play with something new.

And as a networking enthusiast, I had to give Windows Server's native networking features a try. As documented by many blog posts before me, Windows Server actually comes with its own dynamic routing stack supporting BGP!

Step 0: Setting the server up

As far as I know, the standard way for administering Windows Servers is still RDP, and that was definitely the case here too. I had a small hiccup here while provisioning the server as I was waiting for it to respond to ping, forgetting that Windows Firewall blocks incoming ICMP by default. 😀

Other than that though, the initial setup was fairly straightforward: Windows Server really is just regular Windows, though with Modern apps ripped out* and Server Manager popping up each time you log in. All the app installers I tried (Git, WireGuard, etc.) worked perfectly fine, even though I doubt they get as much testing on Windows Server specifically.

One network limitation to note: Windows does not support /31 addressing, so I had to configure WireGuard using a /30.

* Unfortunately this does mean that your default browser is still Internet Explorer 11.

Step 1: Installing Routing and Remote Access

The routing stack in Windows Server is installed as part of "Remote Access" role. This is a fairly vague name, but the role also comes with a whole bunch of other VPN related features that I suppose better fit the description.

Installing the Remote Access role from Server Manager

The feature I'm interested in, RRAS routing, is sparsely mentioned throughout the setup process.

Installing the Remote Access role from Server Manager (continued)

The next step is to configure Routing and Remote Access (RRAS). The actual configuration tool presents itself as a standard MMC snap-in.

Configuring RRAS

Configuring RRAS (continued)

Starting RRAS

Some of the dialog boxes here look unbelievably retro.

Starting RRAS (continued)

Step 2: Configuring IGP routes

Now that RRAS is installed and configured, it happily detects all interfaces present on the system. Of course, the first thing I tried was to add a new Routing Protocol (navigate specifically to IPv4 -> General, then Action -> New Routing Protocol) and look for OSPF there. Only... it's not there.

But what about all the articles that talk about Windows Server supporting OSPF? Turns out, these docs are for Server 2003, and Microsoft actually dropped OSPF with the release of Server 2008! Bummer.

Adding a new Routing Protocol in RRAS

Not wanting to downgrade my network to RIP or run a 20 year old Windows release, I hardcoded in static routes for the rest of my network to the WireGuard tunnel I'd set up at this point. Of course this limits me to having one active "IGP" neighbour at a time, but I'm not aware of any (maintained) OSPF implementations that actually support Windows. Even XORP, which had a Windows port at one point, dropped that too somewhere in the mid-2000s. (And even if changing route tables via WSL is possible, I consider that cheating for this experiment)

Displaying static routes in RRAS

Step 3: Configuring Windows Server's BGP

With internal connectivity somewhat hacked together, the next step I looked at was configuring (internal) BGP. As far as I know, there is no GUI for configuring this BGP stack; instead there is a series of PowerShell cmdlets.

The commands for setting up a new BGP router are quite simple, consisting of Add-BgpRouter and Add-BgpPeer.

However, these commands immediately errored when I tried to input my dn42 ASN. Apparently, these ASNs are so large that instead of just giving a validation error, the parameter validation code even gets confused by UInt32 vs. Int32. More broadly, lack of 4 byte ASN support is an undocumented but well known limitation. (It's frankly a bit odd too seeing a Microsoft Q&A post with 0 responses)

Add-BgpRouter error when trying to add large ASNs

I did try removing the range restrictions on the cmdlets to see if this was a frontend limitation, but no: doing so just changes the error messages to be backend errors instead.

Step 4: Configuring GoBGP on Windows instead

Bummer... Are there any other options for running BGP on Windows?

Turns out, yes! In early 2023, Ben Renninson (@GSGBen) wrote a port of GoBGP to Windows, and extended it to inject routes into the kernel. His focus was getting BGP to run on consumer Windows versions, which do not have a BGP stack. That said, knowing that Windows Server is still Windows under the hood, I had little reason to believe that this wouldn't work here too.

And it did, mostly. I had to apply a small fix to make it add routes to the right interface, but other than that, GoBGP on Windows does in fact feed the system with dn42 full tables*!

Demonstration of GoBGP running on Windows, with route table and traceroute to dn42 wiki

* The host FIB export currently only supports IPv4 routes, though this shouldn't be too difficult to extend.

Step 5: Finding some peers?

At this point, if you're mad enough to peer with a Windows Server, I'm happy to entertain the attempts. You can contact me for peering in all the usual places.

Previous Post