Messages

Did you set in the LAN default any to any rule the WAN_GROUP as Gateway?

It points to the default gateway in default settings.

Thanks much.

Seeking advice from community to learn about this setup:

• OPNsense 25.7.7_4-amd64
  
• working Multi-WAN setup with Gateway Group failover WAN1 -> WAN2
  
• WAN2 has CGNAT
  

Code Select Expand

WAN1[DSL]
         \
          --OPNSense---Lan---WG-Roadwarrior
         /
WAN2[SAT]

Yesterday WAN1 went down. Seemingly all connections have been successfully moved over to WAN2 incl. established connections (as expected <3)
except my one client with a wireguard road warrior setup. The wg0 on this machine showed 100% packet loss.
Config on the VPN Server on the internet has no endpoint config for the road warrior,
config on the road warrior has endpoint VPN Server IP address configured as endpoint. So the lan client road warrior should establish the connection to VPN Server... even - or especially when - the default gateway on OPNSense has been switched.

I had the impression that this config would make wg on the road warrior to re-establish the connection over the new default gateway.

Why is it not happening even over wireguard service restarts? OPNSense is the default gateway in the LAN, the physical gateway has been switched correctly, Default Gateway Switching is enabled, all connections worked, but wireguard.

Any hints? What am I missing?
Seeking your wisdom,
highly appreciated.

[not]

Mine went well, too,
however, it was a bit scary when the UI told me during upgrade process at pkg #13 "unkown error" occured and then went to http 403 forbidden error.
I was still able to login via SSH, but it only showed the welcome banner

Code Select Expand

------------------------------------------------
|       Hello, this is OPNsense 25.7           |           :::::::.
|                                              |           :::::::::.
|  Website:     https://opnsense.org/          |        :::        :::
|  Handbook:    https://docs.opnsense.org/     |        :::        :::
|  Forums:      https://forum.opnsense.org/    |        :::        :::
|  Code:        https://github.com/opnsense    |         `:::::::::
|  Reddit:      https://reddit.com/r/opnsense  |           `:::::::
------------------------------------------------
and nothing more.
Took 2min to automatically recover. Internet access was not affected during this process.

I copy that

Resolved:

Latest Starlink Update fixed the situation. Everything went back to normal, confirming the issue on SL side.

Is the MAC from your modem?
I have the same error on my box (with different MAC/IP) with MAC from my Starlink Router since changing to 24.x, however, this is not true. Starlink Router does hold the MAC but _not_ the IP!?
It is not affecting me in any case as far as I can see, though.

I always do a fresh install,
then on the webUI I upload my existing config file (that is automatically backuped daily) and reboot. Done!

Works all the time...

;)

Thanks franco for your reply!
Highly appreciated.

RE SL: This was my concern, too. Unfortunately you get no information, about their frequent changes. I however tried to manage from my end with arp -S, which was not successful anyway. The only way to have it working for now is deactivating Gateway monitoring. No other setting works around.
I don't like SL that much, but there is no alternative where I live when you demand more bandwidth.

I can confirm this issue on StarLink WAN: https://forum.opnsense.org/index.php?topic=40613.0

As temporary workaround I deactivated gateway monitoring for SL WAN

Although my error messages are a little different compared to
https://forum.opnsense.org/index.php?topic=40664.0
https://forum.opnsense.org/index.php?topic=38603.msg199209
It indeed IS dpinger in combination with StarLink problem. Dpinger on DSL WAN works as expected.

Workaround: deactivate SL gateway monitoring

Did more analysis with exact timing things...

It's breaking when this happens:

Code Select Expand

024-05-24T08:30:48 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:48 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:48 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:47 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:47 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:47 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:47 Notice dhclient dhclient-script: Reason ARPSEND on em0 executing
2024-05-24T08:30:47 Notice dhclient dhclient-script: Reason PREINIT on em0 executing
2024-05-24T08:30:47 Notice kernel <7>arpresolve: can't allocate llinfo for 100.64.0.1 on em0
2024-05-24T08:30:46 Notice dhclient dhclient-script: Reason EXPIRE on em0 executing

which makes me think that this is somehow related to:
https://github.com/opnsense/core/issues/7191
https://github.com/opnsense/core/issues/7224
even though both issues are closed already.
:-\

I just observed, that since this problem exists, I also see another connectivity problem that occured at the same time.

I am ping checking the non StarlinkWAN from a LAN Host regularily. When this problem started I also see that sometimes, I cannot ping the DSLWAN temporarily from the LAN Host. Gateway is always up, Connectivity is ok.

Code Select Expand

apunkt@relion1801:~$ ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) Bytes Daten.
^C
--- 192.168.2.2 ping-Statistik ---
2 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 1003ms

apunkt@relion1801:~$ traceroute 192.168.2.2
traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 60 byte packets
1  fritz.box (192.168.2.2)  0.659 ms  0.997 ms  1.530 ms



After a couple of min I can ping again.
::)

Portforwarding am LTE WAN?
Das LTE ist doch selbst geNATed.
Läuft das? Wie?

Activate "Sticky Connections"
Deactivate "Shared Forwarding"