Messages

> Devs will say: Wrong config, will break some day.

No, but what we're saying is:

> "Name does not resolve: `xx.yyy.de:51820'

That's a DNS error. No dev can reasonable resolve xx.yyy.de for you.


Cheers,
Franco

xxx.yyy.de of course is a valid URL - just removed here ---

Did some more testing:
changing from FDQN to IP does not change anything.

But I made one additional observation:

After reboot, I get log-entries like

/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg3' '/usr/local/etc/wireguard/wg3.conf'> returned exit code 1 and the output was "Name does not resolve: `xx.yyy.de:51820' Configuration parsing error"


I would be fine with a comment like "wrong config" if someone could tell me what is wrong all the sudden and how to correct ...

It is configured both ways. Which ever side is first establishes the tunnel.

Using the IP for the clients is not an option sue to dynamic IPs.

Hi there,

since some time I noticed a strange behaviour:

On every reboot WireGuard does not start up correctly - even the log claims it does. None of the Tunnels are working. 100% reproducible.

When I then have to dis-activate and re-activate Wireguard once -> working stable until next reboot.

The WireGuard log does not give any clue, everything looks usual.

Any hints?

@meyergru: LAN allready is configured as 10.1.1.1/22 - so this can't be the reason.

Ups.

I'll check this!

Only renewing ACME certificates.

Hello!

Since exactely 0:00 tonight I got a problem which leaves me completely clueless:

My config consists of severel VLANs and VPN.
All the VLAN and VPN works as usual.
BUT: from my base LAN all the suden OPNsense refuses any access. No access to the config WEB, no routing to anywhere, not even a ping to OPNsense itselve - while DHCP on the LAN still works.

This now leaves me completely clueless.
Any hints?

Well, getting more strange:

After I'm now trying to chase down the problem it is gone all the sudden as it came, without any change.
And no, it was not only one device, it was all in this network ...

Speechless

On any other device the FDQN is correctly resolved to it's IP6 address - as it was before the update to 25.7.5.

Hello together,

Sunday I updated my appliance from 27.7.3 to 27.7.5.

Everything works fine beside Wireguard. When trying to start, the following error is in the log:


"/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command '/usr/bin/wg syncconf 'wg3' '/usr/local/etc/wireguard/wg3.conf'' returned exit code '1', the output was 'Address family for hostname not supported: `peer.blabla.de:55525'

Multiple times ending in in "Configuration parsing error".

Nothing changed in my config which was working before.

What I see in parallel, the same is happening now when I try to ping the address from a console. The address is only IP6, so this might be the reason.

Any hints how to fix this?

Regards

Carsten

Hallo!

Ich hatte das selbe Problem. Als ich dann die SIP-Verbindungen von UDP auf TCP umgestellt habe lief wieder alles.
Auf die Idee das dies plötzich am IDS liegen könnte bin ich nicht gekommen, zumal ich auch extra nochmal FW rules eingerichtet hatte die explizit UDP Verbindungen zur FB erlaubt hatten .....

Yes, in and out everything allowed.

BTW, access to 10.1.1.0/24 works fine ...

So,
if I understand right:

peer: 1
  endpoint: 10.98.0.12:51820
  allowed ips: 10.98.0.12/32
   persistent keepalive: every 25 seconds

peer: 2
  endpoint: 10.98.0.11:51820
  allowed ips: 10.98.0.11/32
  persistent keepalive: every 25 seconds


should work (10.98.0.0/24 is only used for WG peers).

So far so good. Now I have a new effect:

10.98.0.11 can ping 10.11.1.1 (Endpoint of VPN), but not access it's Webpage.
If peer 2 is the only peer, and allowed ips: 10.0.0.0/8 is used this works.
Any hints?

Somehow I still don't get it.

My complete network is 10.0.0.0/8 - consisting of the local LAN, some VLANs, some other VPN connections (via IPsec).

Which config is needed so each Wireguard client is allowed to reach any IP of this 10.0.0.0/8 network?

Maybe I have a missunderstanding on my side.

I understand "allowed IPs" are the IPs the client is allowed to access on the remote side.
Is this wrong?

Regards
CDS