Messages

[For people that have this issue:]

I figured it out. You were right franco, thanks. It was an invalid configuration that was allowed through the opnsense validator at some point in the past.

For people that have this issue: Check if you've assigned a static ip address to your wireguard interface. You would be able to see this under Interface->[Your wireguard interface].

If you go to this page and press save without making ANY changes, opnsense will yell at you with an error message. Make the fix (in my case, don't assign a static ip address), then press save, apply the changes, and then restart wireguard. The routes will now get propagated.

I feel like the page should not have had "Static IPv4" as a drop down option if it's a wireguard interface.

Is there anything in opnsense that could find invalid configuration entries like that in the future? I did a health check previous to this and that said everything looked good.

I suspect it's related to commits on:

https://github.com/opnsense/core/issues/7304

Routes are no longer being propagated in Wireguard since the update. Statically adding the routes is a workaround, but there is a bug in opnsense:

Configuration:

Code Select Expand


root@router:~ # cat /usr/local/etc/wireguard/wg1.conf
####################################################
# Interface settings, not used by `wg`             #
# Only used for reference and detection of changes #
# in the configuration                             #
####################################################
# Address =  192.168.10.2/24
# DNS =
# MTU =
# disableroutes = 0
# gateway =

[Interface]
PrivateKey = ...
ListenPort = ...

[Peer]
# friendly_name = ...
PublicKey = ...
PresharedKey = ...
Endpoint = ...:...
AllowedIPs = 192.168.10.1/32,192.168.20.1/24


I can successfully ping the remote "Wireguard transfer net IP"

Code Select Expand


root@router:~ # ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=60.482 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=28.849 ms
^C
--- 192.168.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.849/44.666/60.482/15.817 ms


I can't ping the remote network

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss


The remote network is not showing up in the routing table even though its in the "Allowed IPs"

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.10.0/24    link#15            U           wg1


Manually adding the remote network as a static route to the wireguard interface

Code Select Expand


root@router:~ # route add -net 192.168.20.1/24 -interface wg1
add net 192.168.20.1: gateway wg1


Confirming it's there

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.20.0/24    link#15            US          wg1
192.168.10.0/24    link#15            U           wg1


Now I can ping the remote network as it's getting routed through the wireguard interface

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=29.310 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=30.184 ms
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.310/29.747/30.184/0.437 ms


I would love a better workaround for this until it's fixed as I don't want to be manually adding static routes.

Seeing the same issue here. WG site to site worked fine until I upgraded.

Code Select Expand

# opnsense-revert -r 24.1.4 opnsense

does not fix it.

I noticed that the OS routing table is not showing any of the allowed IPs I have under the Site to Site peer. I can successfully ping the remote "Wireguard transfer net IP" when I SSH into the router but that's about it.

"Disable routes" is Unchecked and I've rebooted multiple times.

I looked at `/usr/local/etc/wireguard/*.conf` and everything looks good.

Performing a traceroute on the router, I can see that the issue is that because the routes from the "Allowed IPs" are not getting propagated to the OS the packets are exiting the WAN / default gateway interface instead of going to the wireguard interface.

Anything under Wireguard->Peers->Allowed IPs should be showing up when I do a `netstat -rn` on the router, correct? I think there was a regression introduced and that's the bug.

I just found this post and figured it would be helpful to people here who are watching it for any updates / progress.

For people who are doing MAC spoofing, the port flapping was caused by a bug that was introduced in 22.1.2.

It's been fixed as of this commit thanks to Franco:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

[EDIT:]

I changed:

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {

to

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif))) {

and that fixed it as it used $interface with legacy_interface_details() in get_interface_mac() because $ifconfig_details is null.

Wow, I can't believe mac spoofing has been broken that long and nobody complained! I guess nobody uses that feature.

EDIT:

Saw your commit here:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

Thanks.

Code Select Expand

    /*
     * Don't try to reapply the spoofed MAC if it's already applied.
     * When ifconfig link is used, it cycles the interface down/up,
     * which triggers the interface config again, which attempts to
     * spoof the MAC again which cycles the link again...
     */
    if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {
        mwexecf('/sbin/ifconfig %s link %s', [$realhwif, $wancfg['spoofmac']]);
    }

I believe this is the code that keeps calling ifconfig and cycling the interface up and down. New logic was added in the conditional that broke this check:

https://github.com/opnsense/core/commit/13388839e7e

Even the comment above it describes the issue that is popping up.

I tried a few different versions and discovered that it works on 22.1.1. I believe it's one of these two commits that broke mac spoofing:

https://github.com/opnsense/core/commit/13388839e7e
https://github.com/opnsense/core/commit/84cd38adb558

My bet is on the former since it specifically has to do with mac spoofing.

I'm using the latest opnsense (21.7) and I have a Deciso DEC850 and decided to try out specifying a custom MAC on the WAN port.

When I do this, the WAN port flaps. The interface goes up then down, then up, then down. It continues to do this until I remove the MAC spoof and then it starts working normally again.

Has anyone ever seen this issue before?

I installed the intel-em-kmod package / driver from FreeBSD but no luck, it still flaps.

I would be curious if someone who has a DEC800 series router could try to specify a custom MAC address on igb0 and let me know if it flaps.

I am running the latest Opnsense and decided to run zpool upgrade. Here was the result:

root@router:~ # zpool upgrade zroot
This system supports ZFS pool feature flags.

Enabled the following features on 'zroot':
  userobj_accounting
  encryption
  project_quota
  allocation_classes
  resilver_defer
  bookmark_v2
  redaction_bookmarks
  redacted_datasets
  bookmark_written
  log_spacemap
  livelist
  device_rebuild
  zstd_compress
  draid

Pool 'zroot' has the bootfs property set, you might need to update
the boot code. See gptzfsboot and loader.efi for details.

Is there anything I need to do, or can I reboot? I am worried that I'm going to brick my opnsense install by not updating "the boot code".

Well, this is news to us too so we asked Insyde what this is all about. I'll report back as soon as we know.


Cheers,
Franco

Did Insyde get back to you guys?

There were 23 CVEs that were published that are part of the InsydeH2O UEFI firmware:

https://www.bleepingcomputer.com/news/security/uefi-firmware-vulnerabilities-affect-at-least-25-computer-vendors/

I saw that the DEC appliances sold by Deciso use that firmware:

https://www.insyde.com/press_news/press-releases/insyde%C2%AE-software-powers-opnsense%C2%AE-network-appliance-leveraging-amd-epyc%E2%84%A2

Is there anywhere to download the security updates for these devices?

Are the following two equivalent if I am trying to max out performance:

1. PowerD disabled
and
2. PowerD enabled with setting Maximum

If they are equivalent, why is Maximum even a setting? Isn't the only use case of PowerD to save power?

If anyone is curious, I reached out to Deciso and they said it wasn't considered a stable configuration. The solution (if I really want 1gbE) is to just use a 1gb SFP module. This isn't an issue for me since I was just testing the ports and eventually plan to put 10gbE into that SFP+ port in the future.

I appreciate that. I didn't realize that this wasn't the official channel for getting support. I will reach out to Deciso directly. Thanks again.