Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - blusens

#1
Quote from: OPNenthu on August 14, 2025, 12:56:44 AMIs this for WireGuard?  If so, there is a built-in command in Settings->Cron called "Renew DNS for WireGuard on stale connections" that you could schedule.

Thanks but no, I'm making this so that VLANs from different locations can freely connect to each other. i.e. (Site A-LAN) -> (Site B-managment VLAN). I've been using DHCPv6 reservations + aliases, but it's boring to create aliases+rules on each site and its easier with ipv6 subnets.
#2
So far this seems like the best way:

curl \
  --basic \
  --user "key/pwd" \
  --request POST \
  --insecure \
  --verbose \
  https://opnsense.firewall/api/firewall/alias_util/flush/test_ipv6_alias

curl \
  --header "Content-Type: application/json" \
  --basic \
  --user "key/pwd" \
  --request POST \
  --insecure \
  --verbose \
  --data "{\"address\":\"$(dig +short AAAA wan1.example.local | grep ':' | head -n1 | sed 's/$/\/56/')\"}" \
  https://opnsense.firewall/api/firewall/alias_util/add/test_ipv6_alias

curl \
  --basic \
  --user "key/pwd" \
  --request POST \
  --insecure \
  --verbose \
  https://opnsense.firewall/api/firewall/alias/reconfigure/test_ipv6_alias

And I've set type to external, I think it's better.
#3
Hi,

I have 2 locations with ipv6 dynamic pd and each location uses dyndns with Cloudflare (i.e. wan1.example.local).

I want to allow traffic between the ipv6 subnets from these 2 locations and the best way I came up with, is a small script that updates an alias via API, that will run hourly via cron. (then and an allow rule with alias)

My issue so far is that using "/api/firewall/alias_util/add/[alias_name]" will append the new IP to the alias. Can anyone suggest what I should use, so that the new IP replaces the old?

Quotecurl \
  --header "Content-Type: application/json" \
  --basic \
  --user "key/pwd" \
  --request POST \
  --insecure \
  --verbose \
  --data "{\"address\":\"$(dig +short AAAA wan1.example.local | grep ':' | head -n1 | sed 's/$/\/56/')\"}" \
  https://opnsense.firewall/api/firewall/alias_util/add/test_ipv6_alias   
#4
Could my problem be related to this topic? One of my opnsense boxes has erratic behavior since 24.7.x . Managed radvd stopped working but when I switch to Assisted, only hosts that don't have a static reservation are getting an IP (slaac i think).

Another opnsense box in a different location but on the same ISP and with almost the same settings doesn't have this issue.
#5
I've found a user with the same issue and temporary solution https://github.com/opnsense/core/issues/6671
#6
The LAN interface is set as a Static IPv4 + Track Interface for IPv6 (WAN, Prefix ID set and checked allow manual adjustments of DHCPv6). I haven't changed anything on the interfaces for a few years though.
#7
I've been running 23.7 for a week, and I have an issue with getting an IPv6 assigned on WAN.

I have 3 setups, almost identical, in different geographic regions within my country but with the same ISP (Digi Romania).

The settings are:


  • ipv4: PPPoE
  • ipv6: Dhcpv6
  • MSS: 1452
  • Prefx Delegation size: 56
  • Send IPv6 prefix hint: checked
  • Use IPv4 Connectivity: checked
  • Advanced: Use IPv4 Connectivity: Checked

So, this setup worked pre-23.7, till 23.1.11 and now it doesn't. As I upgraded all 3 sites, they all lost IPv6 (but they do work via Hurricane Electric). At some point, I think it was 23.7, I used to get ipv6 addressess assigned to WAN and lose it after about 5 minutes, but now on 23.7.1_3 I'm not getting any from the get-go (reboot).

I've rolled back one of my sites to 23.1.11 and IPv6 works again.

I've looked through the logs, but I can't identify the issue. Except for the following:

2023-08-21T00:52:53 Notice kernel <7>cannot forward src fe80:2::18de:[redacted]:fe9f:cca7, dst 2a02:[redacted]:fe68:f8d0, nxt 17, rcvif vtnet1, outif pppoe0

That IPv6 looks like something I'd usually get assigned by the ISP - and they're similar on both non-working sites. My ISP assigns different IPv6 on each reboot. I haven't changed any rules between upgrades. The only thing I did, was add DNS servers in System -> General per my post



#8
23.7 Legacy Series / Re: All plugins are orphaned
August 14, 2023, 10:24:47 PM
Hello!

Thanks for the fast reply and sorry for my delay.

I did some tests and I couldn't do a connectivity audit. The screen just stayed blank, but it's kind of clear now that opnsense wasn't able to check the mirrors for updates. There were 2 lines in the update panel that hinted this:

Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/285072 bytes


What threw me off was that the update always ended with this line:

Your packages are up to date.

I've been running without DNS forwarders in Systems -> Settings -> General - I think it had something to do with running NextDNS over TLS + VPN client or something. Weirdly I can't remember exactly why I did it.

Anyway, I've added DNS servers in General, rebooted the firewall, and voila.

This also fixed another issue. I wasn't getting an IPv6 address on WAN anymore. I could see it in the logs on boot, but then it dissappeared.

I'd say my issue is fixed. Thanks!
#9
23.7 Legacy Series / [SOLVED] All plugins are orphaned
August 14, 2023, 02:20:28 AM
Hello.

I've upgraded from 23.1.11 to 23.7 (and separately, directly to 23.7.1_3). I did this on 2 separate systems and both times my plugins show up as orphaned.

On one of the systems I've rolled back and uninstalled dyndns as I thought it'd be the cause. But all plugins still showed up as orphaned.

I've reinstalled different packages on different systems, and upon plugin refresh, they still showed up as orphaned. But they showed up as misconfigured or installed initially. I don't know what to make of this. It also takes a very long time to display the status of the plugins (it's in the order of minutes).
#10
I've been using the cron script to restart radvd and dhcpv6 since 2020. I've been on 22.1 for a few weeks and hadn't the issue anymore. Yay!
#11
I've tried a variety of settings but I can't get to the bottom of this.

When I switch the Windows VMs to other test VLANs that have DHCPv6 and RA enabled, Windows picks up an IPv6 address and works. I've compared the wireshark icmpv6 RA packets and they look almost identical (LAN vs test  VLAN). It's not just the VMs, I've a baremetal Windows host with the same behavior.

The radvd settings for LAN and test VLAN interfaces look almost identical. I found only 2 differences between the them:

1. radvd for LAN shows and MTU of 1492 (same as WAN) whereas the test VLAN has an MTU of 1500. I've tried setting LAN AdvLinkTMU to 1500 in RAs but it's ignored and the generated radvd.conf file has 1492.

But I don't think that's the issue either. If I set an AdvLinkMTU of 1492 in the test VLAN when the interface has an MTU of 1500, Windows still works. When I set an interface MTU of 1492, it works.

So, I don't think MTU is the issue.

2. AdvRouteLifetime was 0 for LAN and 1800 for the test VLAN (even though the respective fields were left empty by default). So I've set an AdvRouteLifetime of 1800 for LAN with no effect.

I've enabled radvd logging with:

/usr/local/sbin/radvd -d 5 -p /var/run/radvd.pid -C /var/etc/radvd.conf -m logfile -l /var/log/radvd.log


but the only weird thing is this message via pppoe0 (WAN):

pppoe0 received icmpv6 RS/RA packet on an unknown interface with index 22


This is my generated radvd.conf file

Quote# Automatically generated, do not edit
# Generated for DHCPv6 server lan
interface vtnet1 {
   AdvSendAdvert on;
   MinRtrAdvInterval 200;
   MaxRtrAdvInterval 600;
   AdvLinkMTU 1492;
   AdvDefaultPreference high;
   AdvManagedFlag on;
   AdvOtherConfigFlag on;
   prefix [LAN ipv6 prefix]::/64 {
      DeprecatePrefix off;
      AdvOnLink on;
      AdvAutonomous off;
   };
   route ::/0 {
      RemoveRoute off;
   };
   RDNSS [ipv6] {
   };
   DNSSL [local domain] {
   };
};
# Generated for DHCPv6 server opt12
interface vtnet1_vlan117 {
   AdvSendAdvert on;
   MinRtrAdvInterval 200;
   MaxRtrAdvInterval 600;
   AdvLinkMTU 1500;
   AdvDefaultPreference medium;
   AdvManagedFlag on;
   AdvOtherConfigFlag on;
   prefix [vlan ipv6 prefix]::/64 {
      DeprecatePrefix on;
      AdvOnLink on;
      AdvAutonomous off;
   };
   RDNSS [ipv6] {
   };
   DNSSL [local domain] {
   };
};
#12
My Windows VMs are not renewing their DHCPv6 leases from Opnsense but Linux VMs don't have issues.

On a network with opn 2.1.6, the hosts don't renew unless I reboot or apply ipconfig /renew6 via cmd. On another network with opn 2.1.5, they won't renew even when I try /renew6. The sites and windows VMs are setup largely the same.

In wireshark I can see the RAs to ff02::01 (the lines are marked with pink if this matters).

How can I troubleshoot this?

Edit:
I believe I've encountered this open issue w/ regard to this part

Quote from: blusens on June 17, 2021, 12:03:21 AM
On another network with opn 2.1.5, they won't renew even when I try /renew6.

If I restart the dhcpv6 service, then ipfconfig /renew6 works on the Windows host
#13
Quote from: franco on June 10, 2021, 04:58:44 PM
Wrong ACL in Unbound maybe? Have you used log / log level to see if requests are made?


Cheers,
Franco

I've a custom ACL to allow all. I've enabled logging and I can't see the requests. They are not reaching the firewall at all cause I'm monitoring firewall traffic for port 53
#14
I have two sites, A and B. Between them there's an IPv4 IPSEC connection. Both sites have dynamic IPv6 WANs and Hurricane Electric (HE_WAN) tunnels for static IPv6 WAN addresses. Problem is, Unbound doesn't use HE_WAN interface for address resolution of Domain Overrides.

In Unbound I've set Domain Overrides for each others' site internal domain, to the respective HE_WAN IPv6 address. For example Domain A has a Domain Override: DomainB.com -> HE_WAN_Site_B_IPv6 and Site B has DomainA.com -> HE_WAN_Site_A_IPv6 .

Unbound's Outgoing network interfaces have WAN, HE_WAN and IPSEC set on both sites. They both listen on all interfaces.

Unbound won't do lookups via HE_WAN on either site. They use WAN IPv6 and IPSEC IPv4 interfaces but won't use HE_WAN, even if it's the only one selected as Outgoing Network Interface - in this case, it'll use WAN IPv6.

I've checked all rules and HE_WANs respond to Unbound queries. If I use something like

dig -b HE_WAN_Site_A_IPv6 DomainB.com @HE_WAN_Site_B_IPv6

it works properly.

I've also a 3rd site which I've used to confirm this behavior. As far as I know, Unbound should use all interfaces for  queries and I'm pretty sure this was the behavior on pfsense. Site A runs opn 2.1.6 while Sites B and C use 2.1.5.
#15
Quote from: Napsterbater on April 28, 2021, 01:31:46 AM
Quote from: blusens on April 27, 2021, 10:01:26 AM
I have a /56 dynamic prefix allocated from my ISP. I've configured 4 VLANs with Track interface and Manual DHCPv6 and Router advertisments. One of those VLANs (i.e. VLAN D) has both DHCPv6 server and RA disabled. RA is set to Managed on the other interfaces.

Windows Hosts on VLAN A are getting an IPv6 address from their own VLAN (Native VLAN, i.e. VLAN A) but they're also getting an IPv6 address and termporary address from VLAN D. These extra IPv6 addresses are not present in DHCPv6 leases and they're not part of the DHCPv6 range set on the interface. Windows Hosts also have the other interfaces as DNS servers.

Make sure the Windows host and any non VLAN aware host are not on ports that send tagged VLAN traffic, those ports for end devices should ONLY have untagged packets for a single VLAN.

Yeah, so you were right. My Windows VM was sitting on the default vmbr0 bridge in Proxmox. When I've set VLAN tag 1 in Proxmox or within the Windows VM, I stopped getting IPv6 addresses from the other interfaces. I've tried researching this a bit to understand and ran a wireshark packet capture, but I'm lacking some fundamental networking knowledge that prevents me from understanding.

Is it because RAs are sent over ICMP to all VLANs? Or is it that the RA is sent via tagged VLAN and Windows simply picks up that packet? I saw that there's something called SLAAC snooping that should prevent this behavior.