Messages

1

24.1 Legacy Series / Re: WAN IPv6 address not renewing after initial dhcp request

« on: July 06, 2024, 11:37:35 am »

Just another +1 for being affected by this issue. I was seeing IPv6 GAs being assigned initially, eventually falling off from the interface. In my case, packet sniffing demonstrated two separate renew packets, the first responding with the GA, and the second responding with my delegated prefix.

Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg

Reboot and try again.

This is what solved the problem for me.

2

23.7 Legacy Series / Re: DHCPv6 static mappings not being utilised

« on: January 31, 2024, 03:50:15 pm »

I ended up populating the IP address field and found that this was provided to the client.

Per the field information:

If an IPv6 address is entered, the address must be outside of the pool.
If no IPv6 address is given, one will be dynamically allocated from the pool.
When using a static WAN address, this should be entered using the full IPv6 address. When using a dynamic WAN address, only enter the suffix part (i.e. ::1:2:3:4).

I had taken this to mean that the hostname would be set for all IP assignments matching the DUID.

3

23.7 Legacy Series / [solved] DHCPv6 static mappings not being utilised

« on: January 30, 2024, 08:15:42 pm »

I've been upgrading my stack to IPv6 along side the existing IPv4. It's coming along, although I've run into an issue with DHCPv6 where static mappings appear to be ignored.

I currently receive a /48 from my provider, received via DHCP on WAN interface.

Each LAN VLAN then tracks the WAN interface, using assisted mode RAs for SLAAC and DHCP.

Each VLAN also has a virtual IP with a ULA, although this is not currently used or leased.

For the hosts I'm needing DNS entries, I've created static mappings with the duid, leaving the address blank for auto assignment. Each machine keeps getting other leases so that the duid duplicates.

I've rebooted opnsense and clients, and just can't figure out why the DHCPv6 server isn't matching the static mappings.

The dhcpd logs on opnsense look unremarkable. For debugging purposes,I I've dropped the time to live right down.

Code: [Select]

<190>1 2024-01-31T05:28:40+11:00 OPNsense.lan dhcpd 99864 - [meta sequenceId="32"] Solicit message from fe80::e4f7:aaaa:bbbb:e759 port 546, transaction ID 0x61C71A00
<190>1 2024-01-31T05:28:40+11:00 OPNsense.lan dhcpd 99864 - [meta sequenceId="33"] Advertise NA: address 2xxx:xxxx:1c04:1:xxxx:119a:6001:aaa2 to client with duid 00:01:00:01:2d:4b:xx:xx:xx:xx:59:3f:02:aa iaid = 1497301674 valid for 300 seconds
<190>1 2024-01-31T05:28:40+11:00 OPNsense.lan dhcpd 99864 - [meta sequenceId="34"] Sending Advertise to fe80::e4f7:aaaa:bbbb:e759 port 546
<190>1 2024-01-31T05:29:13+11:00 OPNsense.lan dhcpd 99864 - [meta sequenceId="35"] Solicit message from fe80::e4f7:aaaa:bbbb:e759 port 546, transaction ID 0x2A063D00
<190>1 2024-01-31T05:29:13+11:00 OPNsense.lan dhcpd 99864 - [meta sequenceId="36"] Advertise NA: address 2xxx:xxxx:1c04:1:xxxx:119a:6001:aaa2 to client with duid 00:01:00:01:2d:4b:xx:xx:xx:xx:59:3f:02:aa iaid = 1497301674 valid for 300 seconds

Any suggestions on what I can check?

4

23.7 Legacy Series / Re: No traffic after handshake with IPv6 Wireguard

« on: January 30, 2024, 07:53:25 pm »

I was able to solve this issue.

It appears the problem was the wireguard configuration (which was reused from ipv4). Once I removed configurations and started again, the tunnel began to function.

Interestingly after that, I ran into another problem where IPv6 tunnels occasionally swapped to IPv4 upon connection and stopped functioning. I ended up separating the dynamic DNS between IPv4 and IPv6 which resolved this problem.

So take-away lesson, don't reuse Wireguard configurations after they're configured.

5

23.7 Legacy Series / Re: No traffic after handshake with IPv6 Wireguard

« on: January 29, 2024, 04:06:50 pm »

Isn't the usual port 51820, not 51280?

Maybe . I'm running on a different port entirely, just noted that for the example.

6

23.7 Legacy Series / Re: No traffic after handshake with IPv6 Wireguard

« on: January 29, 2024, 03:33:36 pm »

Just as sanity check, you did add fd2d:aaaa:bbbb:cccc::10/128 to the wireguard peer on the OPNsense side, too?

Sure have.

Any other ideas I can try?

7

23.7 Legacy Series / Re: No traffic after handshake with IPv6 Wireguard

« on: January 29, 2024, 02:41:35 pm »

The "Wireguard (Group)" firewall interface was empty. My rules were instead in my "WG" interface which is assigned for WireGuard. No matter, I created any-any ICMP rules in both "WG" and "WireGuard (Group)" firewall interfaces. After the handshake, the same problem persisted. I did not get a response to the echo request despite observing traversing packets with tcpdump.

It strikes me as odd that both the client and server are doing the same thing. Both appear to receive the echo request, but then neither appear to send an echo reply. Could this be something to do with the LA network block chosen? I know LAs aren't routed... could that be stopping packets from being handed from Wireguard to the encapsulating interface?

8

23.7 Legacy Series / [Solved] No traffic after handshake with IPv6 Wireguard

« on: January 29, 2024, 09:18:30 am »

I'm preparing to migrate much of my network from IPv4 to IPv6 since CGNAT is coming to my uplink. As part of this, I'm attempting to migrate my Wireguard service to IPv6.

My provider gives me a /48 prefix currently, and these will change periodically. So far I've configured opnsense for this, and it's working well. Using assisted routing, DHCP and SLAAC are working well with prefixed GAs and will be tolerant of changing prefixes.

For Wireguard, I've attempted to set this up with a LA so that I don't have to go changing configs every time my GA prefix changes. I've assigned a random /64 LA to the Wireguard interface instance, and configured the peers within this network. I've then added firewall rules to allow the incoming connection.

The server configuration is configured for tunnel fd2d:aaaa:bbbb:cccc::1/64 on the appropriate port.

The peer configuration looks like this:

Code: [Select]

[Interface]
Address = fd2d:aaaa:bbbb:cccc::10/128
PrivateKey = public_key
DNS = fd2d:aaaa:bbbb:cccc::1

[Peer]
PublicKey = public_key
Endpoint = my.domain.name:51280
AllowedIPs = ::/0
On bringing up this on the client, the handshake is successful via IPv6, and I can see the handshake in the opnsense GUI.

After that, I get no application traffic flow despite observing the UDP packets traversing in both directions on each side of the connection via tcpdump.

For example, when attempting a simple ping, I observe packets leaving the source and arriving on destination without any echo response being sent. This happens regardless of which side I'm sending the echo requests. It almost seems like the packets are being dropped by Wireguard itself.

Note, I have not yet configured any NAT as I only intent to use the VPN to access servers on my internal network.

I'm puzzled about what's happening and what my next steps should be. Any help would be greatly appreciated.