DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 17th February 2021
philomathic_life philomathic_life is offline
Real Name: Zack
Port Guard
 
Join Date: Feb 2021
Location: Littleton, CO USA
Posts: 12
Default How to configure a /64 subnet from a routed /48 on wg0?

I am planning on renting a dedicated server from ARP Networks; but before I do so, I want to be confident that I will be able to configure a WireGuard server on the wg0 pseudo-device such that its peers can use GUAs from a /64 subnet of the routed /48 to surf the public Internet. I am adamant in not using NTP66 nor any from of NDP proxying. Unfortunately, my knowledge in networking is lacking to the say the least; and to make matters worse, I have very little familiarity with route(8). Because this is about a server I don’t actually maintain (yet), I am unable to provide the output of dmesg(8); but I am pretty sure most of this question is more about general networking concepts, so I hope that that is OK. I have found a few resources that seem useful, but sadly I have been unable to leverage them to come up with a roadmap I am confident will work. One of these references is here where the user was able to successfully enable networking on a single interface using the link-local address ARP Networks routes the /48 to. Another reference is here where the OP seems to have configured what I want with a /56 routed to them from their ISP, but the server runs Ubuntu 19.10. Since my goal here is an IPv6-only stack, the problem that poster had shouldn’t affect me.

For the duration of this post, let’s assume that the server is running OpenBSD 6.8, there is one virtual interface, vio0, one pseudo-device, wg0, the /48 is routed to fe80::2%vio0, and the /48 that is routed is 2001:db0:1::/48. Finally, assume pf(4) is disabled—this won’t actually be true; I just don’t want to have firewalls complicate this more—and IPv6 forwarding has been enabled (i.e., # sysctl net.inet6.ip6.forwarding=1).

The following are two ways to configure this that I came up with along with the rationale used in each step. For both of them, I provide explanations for why I think they will fail. If there is anything that is incorrect—I am pretty sure there will be a lot—I would greatly appreciate being corrected.

Method 1

1. Assign fe80::2/64 to vio0. This is so that the routed /48 can be successfully sent from upstream; furthermore, this is the address that actually sends and receives packets from IP addresses outside of the assigned /48.
2. Put fe80::1%vio0 in /etc/mygate. Since this is the link-local address on the provider’s end that routes external traffic to the server, this will be the default gateway.
3. Assign 2001:db0:1::1/48 to vio0 as this will act as the “router” to all of my internal interfaces (including wg0).
4. Assign 2001:db0:1:1::1/64 to vio0. This will act as the WireGuard endpoint for my peers to connect to.
5. Assign 2001:db0:1:2::1/64 to wg0. This is the IP address of the wg0 server.

Why I think the above method will fail. From what I have read, it is “bad” for two interfaces on the same machine to be on the same subnet since the machine will not know which interface to route traffic to. Clearly, 5 is a subnet of 3 though; however gateways should be on the same subnet, so it is a clear contradiction to both require all interfaces to be on different subnets while also having one of the interfaces be the gateway for the other. If I remove step 3 though, then wg0 won’t be able to route traffic outside its /64 (including, most importantly, the public Internet) since the default gateway of the machine is a link-local address associated with a different interface (i.e., vio0).

Method 2

1. Same as Method 1.
2. Same as Method 1.
3. Assign 2001:db0:1:3::1/64 to vio0 as this will act as the “router” to all of my internal interfaces (including wg0).
4. Same as Method 1.
5. Same as Method 1.

Why I think the above method will fail. Now vio0 and wg0 don’t share any subnets in common—so the OS shouldn’t be “confused” about what interface to use—but wg0 is unable to route its traffic outside its own network since the planned gateway is on a different subnet (i.e., 2001:db0:1:3::1/64).

Perhaps adding static routes to Method 2 (e.g., # route add -inet6 2001:db0:1:2::1/64 -link -static -iface vio0?) will avoid the gateway on a different subnet problem?

The actual WireGuard config is pretty easy, so I won’t spend time going over that—I had no problem setting this up via NAT66 on my personal workstation and VPS with Vultr.

I appreciate any help and clarification with the proposed setups and “logic” used to justify the steps and reasons why I think the setup will fail. If there is a way one can achieve my goal, then how so?

Last edited by philomathic_life; 20th February 2021 at 05:27 PM. Reason: Renamed eth0 to vio0.
Reply With Quote
  #2   (View Single Post)  
Old 19th February 2021
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Hello, and welcome!

I recommend setting up several interconnected virtual machines in a "lab" on a workstation so that you can test your various scenarios. For one thing, you will soon discover that there is no eth0 device on OpenBSD.

I am using a WireGuard VPN with a Vultr VPS as my gateway server, with both IPv4 and IPv6. The IPv6 network I use internally for VPN traffic routing is a /64, and it is carved out of the Unique Local Address space fd00::/8. It could be any size I desired but a /64 was convenient and it's well understood. Works fine with OpenBSD and Android clients. I don't have any manual routing table entries at the remote gateway.

My OpenBSD client does have some additional routing provisioned. I set a low priority to the "real" default routes (IPv4, IPv6) using the egress NIC, and a higher priority to the WireGuard default routes (IPv4, IPv6) in RFC1918 (IPv4) and Unique Local Address space (IPv6) through the wg(4) pseudo-NIC so that they will be used when the VPN is up, and skipped if the VPN is down.

There are lots of choices for implementation, and many different needs. Testing will help you pick the best possible options for your use-case.
Reply With Quote
  #3   (View Single Post)  
Old 19th February 2021
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Replying again -- with some additional thoughts...

The /64 I use for internal routing over the WireGuard VPN doesn't have a correlation to the /64 I get from Vultr. That subnet is "real" whereas the VPN's network uses private address space. In my case, the outbound IPv6 gets NAT applied in PF, with:
Code:
pass out on egress from fd00::/64 nat-to (egress)
If I both recall and understand correctly, WireGuard internal address space usage must be private. As an example I recall I was unable to use IPv4 Shared-Address Space (100.64/10) with it.
Reply With Quote
  #4   (View Single Post)  
Old 19th February 2021
philomathic_life philomathic_life is offline
Real Name: Zack
Port Guard
 
Join Date: Feb 2021
Location: Littleton, CO USA
Posts: 12
Default

Using eth0 instead of vio0 was an unfortunate oversight, so I went ahead and changed it. As I mentioned in the post, I have already set up WireGuard on OpenBSD 6.8 on both my workstation and Vultr VPS using both IPv4 and IPv6. NAT is a hack that I want to avoid though. I realize I can’t avoid it in IPv4, but IPv6 was designed to avoid the many mistakes of IPv4 including the use of NAT. While I realize NAT66 and ULAs exist, if one can use GUAs and avoid NAT altogether, one should. Unfortunately many ISPs and VPS providers (e.g., Vultr) don’t follow best practices and the recommendations of IETF when it comes to IPv6. In particular, many do not route prefixes but instead use link prefixes (like Vultr); and many do not provide clients with /48 or at least /56 prefixes per guidelines (again, like Vultr). This forces one to sadly use hacks like NAT or NDP proxying.

I also do not believe WireGuard forces one to use ULAs when it comes to IPv6, but I have not taken the time to dig through the source code to verify that. If they do, then they should fix that; but like I said, I do not believe that to be the case.

Last edited by philomathic_life; 20th February 2021 at 05:28 PM.
Reply With Quote
  #5   (View Single Post)  
Old 19th February 2021
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

I wish you luck with this project. This is a tiny community here, so if you don't get any further input here you might want to reach out to the much larger group of OpenBSD users on the misc@ mailing list.
Reply With Quote
  #6   (View Single Post)  
Old 26th February 2021
philomathic_life philomathic_life is offline
Real Name: Zack
Port Guard
 
Join Date: Feb 2021
Location: Littleton, CO USA
Posts: 12
Default

Quote:
Originally Posted by jggimi View Post
I wish you luck with this project. This is a tiny community here, so if you don't get any further input here you might want to reach out to the much larger group of OpenBSD users on the misc@ mailing list.
Thank you very much. I was making it way more complex than it needed to be. My obvious lack of networking knowledge is at fault. Once forwarding is enabled and a /64 is assigned to wg0, it is ready to go. No NAT. No NDP proxying. Just works.
Reply With Quote
  #7   (View Single Post)  
Old 26th February 2021
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

I'm glad you got it working!

For my use-case, though, I actually want NAT.
Reply With Quote
Reply

Tags
ipv6, networking, routing, vpn, wireguard

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
5.6 ifconfig add IPv6 address no longer adds route for whole subnet. SlyM OpenBSD General 6 4th November 2014 02:05 PM
X -configure ocicat OpenBSD General 3 19th July 2012 04:30 AM
need help to configure netstick. wlm2 OpenBSD General 5 30th September 2011 01:27 PM
Two NICs on same subnet anomie Other BSD and UNIX/UNIX-like 6 7th November 2008 03:24 AM
mpd5 stoped working after subnet change hamba FreeBSD General 0 29th May 2008 04:22 PM


All times are GMT. The time now is 07:24 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick