Messages

1

23.7 Legacy Series / Re: Static IPv6 internally while using ISP PD assigned range externally

« on: November 10, 2023, 03:38:18 am »

You can avoid these problems by not enabling DHCPv6 internally, just "unmanaged" RA, like described here. Thereby, you do not poison your internal DNS.

That does not change the fact that machines still discover and use their IPv6 addresses internally. Clients register to Active Directory, and client-initiated discovery happens automatically. It doesn't matter how the IPs are assigned, only that they change resulting in intermittent connectivity.

Being able to point external requests to a specific IPv6 IP will be great, but I'm not there yet. Right now I'm at this point that if I run IPv6 internally and for all the traffic through NAT everything works, or if I use statically assigned ranges everything works. But as soon as I switch to ISP assigned dynamic addresses things break and that's all my ISP can manage to come up with at the moment.

The fix is not to email every app developer and ask for a "hey, could you rewrite your discovery mechanism to not use half my network even though it looks like it should work?", the fix is to use stable IPs, which leads me back to NPTv6, except that it doesn't seem to work either with PD assigned addresses.

2

Virtual private networks / Re: Routing a public /29 via WireGuard

« on: November 06, 2023, 10:59:19 pm »

One other discovery, I had this working with the old WireGuard before, so on a lark I switched back and... Using the old WireGuard and listing the IPs as normal Virtual IPs, everything works and has been running solid for over 12 hours.

On the kernel WireGuard I can get it running for a short time, until either outbound traffic from OPNsense itself starts failing (taking DNS with it) or the tunnel itself stops responding.

It's feeling like a bug/problem in the kernel WireGuard (but of course this is not certain, if my configuration is bad it might still happen to work in the old WireGuard for various reasons -- Nonetheless, it is possibly a clue).

3

23.7 Legacy Series / Re: Static IPv6 internally while using ISP PD assigned range externally

« on: November 06, 2023, 04:09:59 am »

The initial problem I'm running into internally is the various "things" that notice they have an IPv6 address and remember/register/cache it somewhere, and then that address becomes invalid.

A simple example is every Windows machine registers its IP addresses with Active Directory's DNS, which itself must then replicate changes across AD, plus DNS TTLs. NoMachine (remote control for macOS machines) is similar, each client discovers IPs (great!) and then caches them (less great). A few mobile apps that do their own discovery and then stick with the answer for a while, and at least one IoT product needs a hardware reboot to recover. Oh and one IoT device I had actually rebooted itself whenever it couldn't renew an existing IPv4 or IPv6 IP (it seems to only know how to get a new IP on bootup). Ugh.

Down the road I'd like to be able to use IPv6 on my site-to-site and road-warrior VPN configurations and get away from the mess of NAT, port mappings, and other tweaks to get things talking to each other. Going IPv6-first/only internally with IPv4being relegated to external connectivity just seems like a dream.

My current situation is a mess of my own making, I fully admit, but having stable IPv6 numbering (even if only internally) greatly simplifies this process.

If I'm stuck with internal IPs changing randomly forever then a combination of Dynamic IPv6 Host and/or dynv6.com look like partial solutions. I already started down the road of a script to hit my DNS provider's API and swap prefix-X for prefix-Y, if dynv6.com is stable then it might be just the thing. Thanks!

As much as I'd love to see NAT go away completely, I don't see it happening even if we all got together and threw out IPv4 tomorrow. NPTv6 is a literal purpose-made solution that removes so much of the NAT related issues (the big one being internal ports match external ports across the board) without requiring permanent IP space. I just wish I could use it.

4

23.7 Legacy Series / Static IPv6 internally while using ISP PD assigned range externally

« on: November 06, 2023, 02:01:03 am »

My ISP only offers a IPv6 prefix and no IPv6 address for the WAN interface itself, but I've been able to get up and running using "Track Interface" with "Request only an IPv6 prefix" enabled on the WAN. Great.

Unfortunately I switched ISPs and my new ISP's PD range changes pretty regularly which causes various issues inside my network every time it happens.

It looks like NPTv6 to statically assigned IPs would be my solution, but it doesn't look like it can pull a /64 from a PD range. With a previous ISP I was able to get an IPv6 on the WAN and could at least use NAT to make the IPv6 internet reachable (yeah yeah, I wasn't happy with it either, but some access was better than no access), but with only PD I think I'm stuck.

There is an open feature request to support PD for NPTv6, which will be great when it happens, but I'm wondering if anyone has discovered any other tricks/hacks around this in the meantime?

5

Virtual private networks / Routing a public /29 via WireGuard

« on: November 06, 2023, 01:38:51 am »

Hey there! Doing something new to me in WireGuard and having a bit of an issue.

OPNsense 23.7.7_3 with os-wireguard (kernel).

I have a /29 subnet that I'd like routed to me over WireGuard, to assign more public IP addresses to my OPNsense box.

I've done this type of configuration with the subnet routed directly to me by my ISP, but I've been forced to switch ISPs and don't have this option, and luckily I found a local-ish provider that can sell me IPs via VPN.

I set up a tunnel with the 6 usable IP addresses as the Tunnel Address each as a /29 (is that correct? Or should these be individual /32s? Or one /29 for the whole network?). And in the Peer I set Allowed IPs 0.0.0.0/0 as I want to be able to receive traffic from any IP.

I also added the same usable IPs as Virtual IPs type Other, so that they appear in the OPNsense GUI in various places.

I'm a bit unclear about whether I want to use "Disable routes" or not, I think I want Disable routes enabled because I do not want to redirect all traffic. With "Disable routes" not selected everything seems to work (the routed IPs are pingable from outside, and my existing NAT rules that apply to all interfaces apply), but this interferes with normal traffic to some extent. With "Disable routes" unselected, the IPs are not pingable or otherwise accessible from an external perspective.

In both cases I have various Firewall rules on the wg interface, such as allowing all ICMP, as well as allowing 80/443 for haproxy on my OPNsense box, plus some NAT rules (25 to reach my internal SMTP server). This all works with "Disable routes" enabled, but stops working with "Disable routes" disabled and I'm not completely sure why.

I've mucked around with Virtual IPs either in IP Alias or Other states without change, as well as tried a few permutations of Tunnel Addresses, but I can't get it working reliably without it trying to route at least some traffic across the tunnel.

My provider could offer OpenVPN instead if this would be more useful, but I already use WireGuard for "road-warrior" setups and connectivity to some remote server and I would rather not increase complexity with multiple VPN platforms running unless necessary.

Thanks!