Topics

Hi there,

Looks like there is a cap on the amount of WG local configurations you can create in the UI (20).
The following error is reported if you attempt to create any more:
Maximum number of instances reached

It appears this limit is enforced here:
https://github.com/opnsense/plugins/blob/f8f3975e00560425bd1de3136320d181a83e4f84/net/wireguard/src/opnsense/mvc/app/models/OPNsense/Wireguard/Server.xml#L20

Just wondering why this limit is so small or fixed at all?

OPNsense 21.7.7
os-wireguard 1.9

Regards,
Adam

[SOLVED]
https://github.com/opnsense/plugins/issues/2314#issuecomment-851009622
Upgrade to 21.1.6 fixed the issue.


Hi there,

I have been using OSPF over WG for over a year, but it seems to have broken in one of the past few releases, 21.1.3 I believe I started seeing my issue.

I'm currently 21.1.5 in a VM.

It appears the initial messaging for OSPF is having the problem, as no neighbours are discovered, and some very ugly messages in the logs:

May 20 15:57:37 <host-removed> frr_carp[90878]: FRR received carp configuration event.
May 20 15:57:37 <host-removed> ospfd[21850]: [EC 100663299] setsockopt_so_sendbuf: fd 8: SO_SNDBUF set to 2097152 (requested 8388608)
May 20 15:57:37 <host-removed> ospfd[21850]: [EC 100663299] setsockopt_so_recvbuf: fd 8: SO_RCVBUF set to 2097152 (requested 8388608)
May 20 15:57:37 <host-removed> ospfd[21850]: ASBR[default:Status:1]: Update
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] setsockopt_so_sendbuf: fd 13: SO_SNDBUF set to 2097152 (requested 8388608)
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] setsockopt_so_recvbuf: fd 13: SO_RCVBUF set to 2097152 (requested 8388608)
May 20 15:57:37 <host-removed> ospfd[2077]: ASBR[default:Status:1]: Update
May 20 15:57:37 <host-removed> zebra[83367]: client 19 says hello and bids fair to announce only ospf routes vrf=0
May 20 15:57:37 <host-removed> frr_carp[19057]: FRR received carp configuration event.
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_ADD_MEMBERSHIP (fd 13, addr 169.254.0.1, ifindex 7, AllSPFRouters): Can't assign requested address; perhaps a kernel limit on # of multicast group memberships has been exceeded?
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_ADD_MEMBERSHIP (fd 13, addr 169.254.192.2, ifindex 8, AllSPFRouters): Can't assign requested address; perhaps a kernel limit on # of multicast group memberships has been exceeded?
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.0.1, ifindex 7): Operation not supported
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.192.2, ifindex 8): Operation not supported
May 20 15:57:37 <host-removed> ospfd[2077]: [EC 100663299] *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 64, interface wg1, mtu 1420: Network is unreachable
May 20 15:57:37 <host-removed> ospfd[2077]: LSA[Type5:0.0.0.0]: Not originate AS-external-LSA for default
May 20 15:57:38 <host-removed> frr_carp[19057]: FRR trigger OspfdEventHandler event.
May 20 15:57:47 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.0.1, ifindex 7): Operation not supported
May 20 15:57:47 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.192.2, ifindex 8): Operation not supported
May 20 15:57:47 <host-removed> ospfd[2077]: [EC 100663299] *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 64, interface wg1, mtu 1420: Network is unreachable
May 20 15:57:57 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.0.1, ifindex 7): Operation not supported
May 20 15:57:57 <host-removed> ospfd[2077]: [EC 100663299] can't setsockopt IP_MULTICAST_IF(fd 13, addr 169.254.192.2, ifindex 8): Operation not supported
May 20 15:57:57 <host-removed> ospfd[2077]: [EC 100663299] *** sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 64, interface wg1, mtu 1420: Network is unreachable

The WG links are up, set up as gateways with monitored pings.  Static routing works fine over the links, just OSPF seems to now struggle.

Configuration of one side:

Building configuration...

Current configuration:
!
frr version 7.4
frr defaults traditional
hostname <host-removed>
log syslog informational
!
interface wg0
ip ospf area 0.0.0.0
ip ospf network point-to-point
!
interface wg1
ip ospf area 0.0.0.0
ip ospf network point-to-point
!
router ospf
ospf router-id <ip-removed>
redistribute kernel
passive-interface lo0
passive-interface vtnet0
passive-interface vtnet1
passive-interface wg5
passive-interface wg7
passive-interface wg8
passive-interface wireguard
!
line vty
!
end

And a second node (3 nodes in a ring):

Building configuration...

Current configuration:
!
frr version 7.4
frr defaults traditional
hostname <host-removed>
log syslog informational
!
interface wg0
ip ospf area 0.0.0.0
ip ospf network point-to-point
!
interface wg1
ip ospf area 0.0.0.0
ip ospf network point-to-point
!
router ospf
ospf router-id <ip-removed>
redistribute kernel
passive-interface lo0
passive-interface vtnet0
passive-interface vtnet1
passive-interface wg5
passive-interface wg7
passive-interface wireguard
!
line vty
!
end

Just wondering if anyone has any tips on troubleshooting this further?

Thanks,
Adam

Hi all,

Just wondering if anyone has tried Wireguard with the Captive Portal?

My attempts to get it to work have ended in misery so far, essentially once the WG tunnel is set up, all packets can get through without needing to use the Captive Portal.

I have a feeling this might be due to the Captive Portal only being able to see the individual wgX interfaces. The Firewall section only seems to have an effect on the parent "WireGuard" interface that doesn't get listed in the Interfaces section (a general frustration with the WG plugin, FW rules on the individual WG interfaces wg0, wg1 etc don't have an affect).





Kind Regards,
Adam

In reference to post https://forum.opnsense.org/index.php?topic=17151.0 to bring this to 20.7.

It isn't possible to modify the cipher list with the Nginx plugin, as it is hardcoded in a template.  The current release is using weak ciphers as determined by SSLLabs.

We have written a patch which adds a drop-down list to the HTTP Server configuration for cipher selection.

Commit: https://github.com/opnsense/plugins/commit/a694ac4cb65481df9abf7138c0eb7693a9e36d11

Hi all - a quick FYI for intensive wireguard users.

OPNsense: 20.7.1

Currently the "Save" button in Wireguard actually restarts the entire WG service, causing an outage to existing tunnels, so if you add an endpoint for example, you still get an outage on other unrelated tunnels (the "reconfigure" api endpoint also).

I raised this bug report:
https://github.com/opnsense/plugins/issues/1951

We created a pull request to address this, so instead of restarting the service, it performs a reload (which in turn calls the wg syncconf to merge the config while running).
https://github.com/opnsense/plugins/pull/2008

Seems to be working well for us now, feel free to test out and leave feedback, hopefully this can be merged in to a future release.

Cheers,
Adam

Hi there,

The dns_me.sh provided with os-acme-client is outdated and cannot determine the domain id from DNSMadeEasy when communicating via the API.

The fix is in a later release of the acme.sh/dnsapi/dns_me.sh which I have tested to work (after checking out manually and replacing on OpnSense).

OPNsense 20.1.4-amd64
FreeBSD 11.2-RELEASE-p18-HBSD
OpenSSL 1.1.1f 31 Mar 2020
Plugin: os-acme-client: 1.3.0
Package: acme.sh: 2.8.5_2

Fixed version of acme.sh: 2.8.6

Is it possible to get the acme client updated to the latest?

Regards,
Adam