Topics

I just noticed a weird problem, none of the .mil domains can be resolved within the my home network managed by Opnsense running Unbound as forwarder. Examples: www.navy.mil, www.af.mil, etc ....

Quick googling points to some DNSSEC issue with these US military domains. However unchecking the box "Enable DNSSEC support" doesn't change anything for me.

I'm using DNS over TLS with Google dns servers. Tried switching to Cloudflare or Quad9. Tried enabling all of them. Still doesn't work. I also made sure the setting "Use system nameservers" is NOT selected to make DoT work. I'm also using OISD blocklist, but i doubt that is the culprit.

If i use my phone with cellular connection or connect to Mullvad VPN service directly from my laptop, i can query these domains (with dig command) and visit them normally.

Anyone having this weird issue here?

[Only if i had to manually restart lighttpd, i can access WebUI. It's broken again once i reboot Opnsense until i manually restart webserver.]

I followed this tutorial on official documenation: WireGuard Road Warrior Setup

WG road warrior clients has no problem connecting to internal networks, except that they can't access Web GUI. Firewall allowed the connection and i can see that traffic to Opnsense Web GUI is passed in firewall logs.

I also have Web UI listen to 'HomeWireguard' interface in System > Settings > Administration. There is no log in System > Logs File > Web GUI although i had access log enabled.

Only if i had to manually restart lighttpd, i can access WebUI. It's broken again once i reboot Opnsense until i manually restart webserver.

I suspect that lighttpd service tried to bind to 'HomeWireguard' interface before the this interface is active? Does this sound like a bug?

Is there anyway for me to further debug this problem on my end? I'm seeing no web UI log.

Thank for help!

[ice]

I don't need 25GbE but E810-XXVDA2 card is at same price as X710-DA2 so I'm thinking why not go for the supposedly better NIC.

I'm aware that FreeBSD has ice driver supporting Intel 800 series but i'm wondering if it is stable as Intel NICs has always been with FreeBSD. One person in this forum seems to have problem with Opnsense not recognizing this card.

Thnx for help guys  :)

Aliases section in Services > Unbound DNS > Host Overrides does not show any of my aliases rule:

https://i.postimg.cc/rydZZYVf/screenshot.png

I can see the aliases in my XML config file, and i can verify that they are working by dig command but none of the rules show up on web UI.

I can even blindly add new aliases via the form but that also allow dupulicated alias and thus creating the warnings PTR record ... already exist on the logs.

I'm planning on acquiring or building new hypervisor host in next year or two, virtualized Opnsense with SR-IOV passthrough will be one of the guests. It appears to me that many servers and motherboards being offered right now have built-in Broadcom SFP+/SFP28 NIC.

I'm aware that Intel NICs are still best, but i would have to buy additional NIC and leave built in ports unused.

So, are the drivers for Broadcom NIC are 'good enough' for Opnsense at the moment or in next couple of years? Specifically, i'm referring to BCM5741x series.

Thanks for any insight  :)

I'm not sure if i'm understanding documentation correctly here:

https://docs.opnsense.org/manual/unbound.html#advanced-configurations

Some installations require configuration settings that are not accessible in the UI. To support these, individual configuration files with a .conf extension can be put into the /usr/local/etc/unbound.opnsense.d directory. These files will be automatically included by the UI generated configuration. Multiple configuration files can be placed there.

But Opnsense config file downloaded from System > Configuration > Backups does not have this custom .conf file i placed in that folder.

I had very same setup with another router without problem but for some unknown reason when i recreate settings with this machine this issue popped up.

I followed Wireguard selective routing with external endpoint in Opnsense documentation, using both Ipv4 and 6. IPv6 gateway monitoring has no problem but IPv4 gateway is always down despite that tunnel is up AND selective routing still works. I tried different monitoring IPs.



Logs are filled with error code 93:



Tunnel settings:




Gateway settings:



I tried comparing this setup with previous one but can't find any difference that could cause this issue. Old router has i210 NICs, this new on has i226.

I tried difference sizes of ICMP payload: 0, 1, 60.

I don't think 23.7 is problem because is has been going on before that.

Would love to have some ideas here to diagnosis this annoying issue. Thanks!

I was trying to add simple rule for VLAN5:

Action: Pass
Quick: Checked
Interface: VLAN5
Direction: In
TCP/IP version: IPv4
Protocol: TCP/UDP
Source: VLAN5 net
Destination invert: checked
Destination: RFC1918_net

RFC1918_net is alias of networks: 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

Got the following rec message:

The following input errors were detected:

    The field Destination bit count is required.
    A valid destination bit count must be specified.

I had same rule in another OPNsense router. But now i can't add any rule with Destination aliases. What's wrong here? Does 23.1.10 has a bug i'm not aware of? How can i roll back to 23.1.9.

Hello,

I've got my selective routing up and running for awhile with just 2 tunnels to Mullvad. I followed this official documentation:

https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html

What I don't understand is the purpose of Step 9 with that Floating rule. My setup doesn't seem to be affected with or without that rule. Can somebody explain to me what it does ? I consider myself pretty familiar with firewall rules, but with a Floating rule not selecting any interface i don't understand. Beside that, pfsense guide does not have that step which is even weirder to me.

Also, I have 2 tunnels each with both IPv4 and IPv6 gateways. Does that mean I need total of 4 of that floating rules for 4 gateways?

Thanks!

I restarted the ISP-provided modem (in bridge mode), Opnsense then get new WAN address as usual but NTP daemon stopped permanently and could not be manually started unless I have to reboot the firewall.

My guess is that it was listening on an interface that track WAN for IPv6 address, and somehow WAN going down caused this.

Here's the full log:

Code Select Expand


2021-08-27T00:36:15 ntpd[70683] daemon child exited with code 1
2021-08-27T00:36:15 ntpd[91311] unable to bind to wildcard address :: - another process may be running - EXITING
2021-08-27T00:36:15 ntpd[91311] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:36:15 ntpd[91311] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:36:15 ntpd[91311] basedate set to 2021-07-10
2021-08-27T00:36:15 ntpd[91311] proto: precision = 0.134 usec (-23)
2021-08-27T00:36:15 ntpd[70683] ----------------------------------------------------
2021-08-27T00:36:15 ntpd[70683] available at https://www.nwtime.org/support
2021-08-27T00:36:15 ntpd[70683] corporation. Support and training for ntp-4 are
2021-08-27T00:36:15 ntpd[70683] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:36:15 ntpd[70683] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:36:15 ntpd[70683] ----------------------------------------------------
2021-08-27T00:36:15 ntpd[70683] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:36:15 ntpd[70683] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:36:06 ntpd[27532] daemon child exited with code 1
2021-08-27T00:36:06 ntpd[39687] unable to bind to wildcard address :: - another process may be running - EXITING
2021-08-27T00:36:06 ntpd[39687] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:36:06 ntpd[39687] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:36:06 ntpd[39687] basedate set to 2021-07-10
2021-08-27T00:36:06 ntpd[39687] proto: precision = 0.134 usec (-23)
2021-08-27T00:36:06 ntpd[39687] proto: precision = 0.134 usec (-23)
2021-08-27T00:36:06 ntpd[27532] ----------------------------------------------------
2021-08-27T00:36:06 ntpd[27532] available at https://www.nwtime.org/support
2021-08-27T00:36:06 ntpd[27532] corporation. Support and training for ntp-4 are
2021-08-27T00:36:06 ntpd[27532] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:36:06 ntpd[27532] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:36:06 ntpd[27532] ----------------------------------------------------
2021-08-27T00:36:06 ntpd[27532] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:36:06 ntpd[27532] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:49 ntpd[70489] daemon child exited with code 1
2021-08-27T00:35:49 ntpd[81772] unable to bind to wildcard address :: - another process may be running - EXITING
2021-08-27T00:35:49 ntpd[81772] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:35:49 ntpd[81772] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:35:49 ntpd[81772] basedate set to 2021-07-10
2021-08-27T00:35:49 ntpd[81772] proto: precision = 0.136 usec (-23)
2021-08-27T00:35:49 ntpd[70489] ----------------------------------------------------
2021-08-27T00:35:49 ntpd[70489] available at https://www.nwtime.org/support
2021-08-27T00:35:49 ntpd[70489] corporation. Support and training for ntp-4 are
2021-08-27T00:35:49 ntpd[70489] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:35:49 ntpd[70489] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:35:49 ntpd[70489] ----------------------------------------------------
2021-08-27T00:35:49 ntpd[70489] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:35:49 ntpd[70489] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:34 ntpd[76094] daemon child exited with code 1
2021-08-27T00:35:34 ntpd[88905] unable to bind to wildcard address :: - another process may be running - EXITING
2021-08-27T00:35:34 ntpd[88905] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:35:34 ntpd[88905] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:35:34 ntpd[88905] basedate set to 2021-07-10
2021-08-27T00:35:34 ntpd[88905] proto: precision = 0.134 usec (-23)
2021-08-27T00:35:34 ntpd[76094] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[76094] available at https://www.nwtime.org/support
2021-08-27T00:35:34 ntpd[76094] corporation. Support and training for ntp-4 are
2021-08-27T00:35:34 ntpd[76094] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:35:34 ntpd[76094] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:35:34 ntpd[76094] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[76094] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:35:34 ntpd[76094] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:34 ntpd[27324] daemon child exited with code 1
2021-08-27T00:35:34 ntpd[59351] unable to bind to wildcard address :: - another process may be running - EXITING
2021-08-27T00:35:34 ntpd[59351] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:35:34 ntpd[59351] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:35:34 ntpd[59351] basedate set to 2021-07-10
2021-08-27T00:35:34 ntpd[59351] proto: precision = 0.135 usec (-23)
2021-08-27T00:35:34 ntpd[38070] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
2021-08-27T00:35:34 ntpd[38070] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
2021-08-27T00:35:34 ntpd[38070] Listening on routing socket on fd #43 for interface updates
2021-08-27T00:35:34 ntpd[38070] Listen normally on 22 ix0_vlan99 10.0.99.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 21 ix0_vlan99 [fe80::3333:44ff:fe55:6666%19]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 20 ix0_vlan98 10.0.98.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 19 ix0_vlan98 [fe80::3333:44ff:fe55:6666%18]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 18 ix0_vlan60 10.0.60.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 17 ix0_vlan60 [fe80::3333:44ff:fe55:6666%17]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 16 ix0_vlan40 10.0.40.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 15 ix0_vlan40 [fe80::3333:44ff:fe55:6666%15]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 14 ix0_vlan30 10.0.30.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 13 ix0_vlan30 [fe80::3333:44ff:fe55:6666%14]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 12 ix0_vlan20 10.0.20.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 11 ix0_vlan20 [fe80::3333:44ff:fe55:6666%13]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 10 ix0_vlan10 [2001:ee0:4161:a5ce:3333:44ff:fe55:6666]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 9 ix0_vlan10 10.0.10.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 8 ix0_vlan10 [fe80::3333:44ff:fe55:6666%12]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 7 ix0_vlan9 10.0.9.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 6 ix0_vlan9 [fe80::3333:44ff:fe55:6666%11]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 5 lo0 127.0.0.1:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 4 lo0 [::1]:123
2021-08-27T00:35:34 ntpd[38070] Listen normally on 3 ix2 [fe80::aaaa:bbff:fecc:dddd%5]:123
2021-08-27T00:35:34 ntpd[27324] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[27324] available at https://www.nwtime.org/support
2021-08-27T00:35:34 ntpd[27324] corporation. Support and training for ntp-4 are
2021-08-27T00:35:34 ntpd[27324] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:35:34 ntpd[27324] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:35:34 ntpd[27324] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[27324] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:35:34 ntpd[27324] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:34 ntpd[38070] Listen normally on 2 ix2 192.168.1.1:123
2021-08-27T00:35:34 ntpd[38070] Listen and drop on 1 v4wildcard 0.0.0.0:123
2021-08-27T00:35:34 ntpd[38070] Listen and drop on 0 v6wildcard [::]:123
2021-08-27T00:35:34 ntpd[38070] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:35:34 ntpd[38070] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:35:34 ntpd[38070] basedate set to 2021-07-10
2021-08-27T00:35:34 ntpd[38070] proto: precision = 0.135 usec (-23)
2021-08-27T00:35:34 ntpd[19683] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[19683] available at https://www.nwtime.org/support
2021-08-27T00:35:34 ntpd[19683] corporation. Support and training for ntp-4 are
2021-08-27T00:35:34 ntpd[19683] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:35:34 ntpd[19683] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:35:34 ntpd[19683] ----------------------------------------------------
2021-08-27T00:35:34 ntpd[19683] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:35:34 ntpd[19683] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:30 ntpd[51659] 20.43.94.199 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:30 ntpd[51659] 17.253.68.125 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:30 ntpd[51659] 2606:4700:f1::1 local addr 2001:ee0:4161:a5ce:3333:44ff:fe55:6666 -> <null>
2021-08-27T00:35:30 ntpd[51659] 2001:4860:4806:4:: local addr 2001:ee0:4161:a5ce:3333:44ff:fe55:6666 -> <null>
2021-08-27T00:35:30 ntpd[51659] ntpd exiting on signal 15 (Terminated)
2021-08-27T00:35:23 ntpd[51659] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
2021-08-27T00:35:23 ntpd[51659] kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
2021-08-27T00:35:23 ntpd[51659] Listening on routing socket on fd #43 for interface updates
2021-08-27T00:35:23 ntpd[51659] Listen normally on 22 ix0_vlan99 10.0.99.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 21 ix0_vlan99 [fe80::3333:44ff:fe55:6666%19]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 20 ix0_vlan98 10.0.98.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 19 ix0_vlan98 [fe80::3333:44ff:fe55:6666%18]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 18 ix0_vlan60 10.0.60.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 17 ix0_vlan60 [fe80::3333:44ff:fe55:6666%17]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 16 ix0_vlan40 10.0.40.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 15 ix0_vlan40 [fe80::3333:44ff:fe55:6666%15]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 14 ix0_vlan30 10.0.30.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 13 ix0_vlan30 [fe80::3333:44ff:fe55:6666%14]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 12 ix0_vlan20 10.0.20.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 11 ix0_vlan20 [fe80::3333:44ff:fe55:6666%13]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 10 ix0_vlan10 [2001:ee0:4161:a5ce:3333:44ff:fe55:6666]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 9 ix0_vlan10 10.0.10.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 8 ix0_vlan10 [fe80::3333:44ff:fe55:6666%12]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 7 ix0_vlan9 10.0.9.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 6 ix0_vlan9 [fe80::3333:44ff:fe55:6666%11]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 5 lo0 127.0.0.1:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 4 lo0 [::1]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 3 ix2 [fe80::aaaa:bbff:fecc:dddd%5]:123
2021-08-27T00:35:23 ntpd[51659] Listen normally on 2 ix2 192.168.1.1:123
2021-08-27T00:35:23 ntpd[51659] Listen and drop on 1 v4wildcard 0.0.0.0:123
2021-08-27T00:35:23 ntpd[51659] Listen and drop on 0 v6wildcard [::]:123
2021-08-27T00:35:23 ntpd[51659] restrict: 'monitor' cannot be disabled while 'limited' is enabled
2021-08-27T00:35:23 ntpd[51659] gps base set to 2021-07-11 (week 2166)
2021-08-27T00:35:23 ntpd[51659] basedate set to 2021-07-10
2021-08-27T00:35:23 ntpd[51659] proto: precision = 0.135 usec (-23)
2021-08-27T00:35:23 ntpd[46990] ----------------------------------------------------
2021-08-27T00:35:23 ntpd[46990] available at https://www.nwtime.org/support
2021-08-27T00:35:23 ntpd[46990] corporation. Support and training for ntp-4 are
2021-08-27T00:35:23 ntpd[46990] Inc. (NTF), a non-profit 501(c)(3) public-benefit
2021-08-27T00:35:23 ntpd[46990] ntp-4 is maintained by Network Time Foundation,
2021-08-27T00:35:23 ntpd[46990] ----------------------------------------------------
2021-08-27T00:35:23 ntpd[46990] Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
2021-08-27T00:35:23 ntpd[46990] ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
2021-08-27T00:35:23 ntpd[93283] 139.59.112.6 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:23 ntpd[93283] 124.108.20.1 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:23 ntpd[93283] 2001:470:19:301::123 local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:35:23 ntpd[93283] 118.143.17.82 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:23 ntpd[93283] 20.189.79.72 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:23 ntpd[93283] 17.253.84.253 local addr 192.168.1.1 -> <null>
2021-08-27T00:35:23 ntpd[93283] 2606:4700:f1::1 local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:35:23 ntpd[93283] 2001:4860:4806:4:: local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:35:23 ntpd[93283] ntpd exiting on signal 15 (Terminated)
2021-08-27T00:31:09 ntpd[93283] 2001:4860:4806:4:: local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:31:09 ntpd[93283] 2606:4700:f1::1 local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:31:09 ntpd[93283] 2001:470:19:301::123 local addr fe80::3333:44ff:fe55:6666%11 -> <null>
2021-08-27T00:31:06 ntpd[93283] 17.253.84.253 local addr 10.0.99.1 -> <null>
2021-08-27T00:31:06 ntpd[93283] 20.189.79.72 local addr 10.0.99.1 -> <null>
2021-08-27T00:31:06 ntpd[93283] 118.143.17.82 local addr 10.0.99.1 -> <null>
2021-08-27T00:31:06 ntpd[93283] 124.108.20.1 local addr 10.0.99.1 -> <null>
2021-08-27T00:31:06 ntpd[93283] 139.59.112.6 local addr 10.0.99.1 -> <null>
2021-08-27T00:31:06 ntpd[93283] 2001:4860:4806:4:: local addr 2001:db8:1111:2222:3333:44ff:fe55:6666 -> <null>
2021-08-27T00:31:06 ntpd[93283] 2606:4700:f1::1 local addr 2001:db8:1111:2222:3333:44ff:fe55:6666 -> <null>
2021-08-27T00:31:06 ntpd[93283] 2001:470:19:301::123 local addr 2001:db8:1111:2222:3333:44ff:fe55:6666 -> <null>
2021-08-27T00:31:06 ntpd[93283] Deleting interface #10 ix0_vlan10, 2001:db8:1111:2222:3333:44ff:fe55:6666#123, interface stats: received=5839, sent=5882, dropped=0, active_time=983992 secs


I'm currently using this feature in Opnsense (and previously with pfSense) to achieve split-horizon DNS with Unbound. It just came to my attention that 21.7 onward will no longer support it. May I ask why? I'm afraid this would be the deal breaker for me and some other users.

My ISP only delegate single /64 subnet to my router, to make SLAAC works i give that whole subnet to VLAN 20 via Track interface. But a Windows 10 PC on VLAN 10 still see its IPv6 addresses, although IPv6 routing isn't working on this VLAN:



pfSense has same problem.

Is this normal behavior? I guess router advertisement somehow works on all interface and not only the interface that got IPv6 enabled.

I've been seeing strange behavior with my OpnSense router. Occasionally, my gaming PC (on VLAN 10) got kicked out of online game server, active SSH session from VLAN 20 to a local server on VLAN 30 is dropped with 'broken pipe' error. These events always occur at same time. It's almost like i go to Firewall > Diagnostics > States Reset on Web GUI and click big Reset button.

Frequency of this problem varies from zero in 10+ hours to several occurrences within hour at evening.

How do I narrow down the cause of this strange issue? Could hardware (bad cables, bad NIC, ....) be the reason that triggered the reset of firewall states?

Recently I upgraded the link between Opnsense router and switch to 10G, the NIC is X710-DA2. Since then I've had bad network experience: Kicked out of online games, "broken pipe" SSH connection to local server on another VLAN, local streaming and file operations from NAS are interupted.....

Occurrence of these drops can vary from 0 in whole day to consistent disconnect every several seconds.

I believe the switch is not issue because i tried replacing it with another 10G switch laying around, so it must be Opnsense router.

I'm not sure if this is 21.1.5 issue because I had this NIC briefly before upgrading OpnSense to 21.1.5.

Is there any thing I can do to fix this? System turntables? Another driver instead of default one? Or just buy another NIC (X520 ???).

Thanks!

Most ISPs delegate new IPv6 prefixes to router (and subsequently to all clients that track interface) upon reconnection, this creates problem that firewall rules with existing prefixes become useless once new prefixes are pushed.

This is also a much desired feature in pfSense for years, but it seems they are targeting 2.6.0:

https://redmine.pfsense.org/issues/6626

For me this is the only feature currently preventing me from deploying full dual-stack for all internal hosts. Does OPNsense plan to implement similar feature that allows users to input only 64bit suffix of the hosts in rules and forget about the prefix? Hopefully the answer is yes because i don't want to go back to pfsense  :).

Thank you!

... got this message from Paypal:

https://imgur.com/e82fUzk

I chose donating with credit/debit card because I don't have a Paypal account. Is this on OPNsense's or Paypal's end.

I'm planning to build my home network around router-on-stick fashion with Opnsensen installed on a C3558 board, but i don't now what's the throughput Opnsense can route between network segments, mainly from my workstation to NAS in another VLAN.

I looked at performance of Netgate XG-7100 because it has same CPU and both projects probably are similar in routing capability. It says 18 Gbps routing and 6 Gbps firewall but i'm not sure what those number means. With several simple access/deny rules I have in each VLAN, can I reach 10 Gbps? Or perhaps the number will just be 5-6 Gbps as XG-7100 advertised? Would increasing amount of RAM from 8GB to 16GB improve this routing performance?