Messages

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"

Nur die default rule soll auf die GW Gruppe geändert werden, Du willst Deinen LAN Traffic nicht auf der GW Gruppe haben, das regelst Du intern und deswegen bleibt alles so wie es ist ;)

[everything]

Two problems here:

PING:
You said

But I then insert the WombatHollowGateway into the "Default allow LAN to any rule" (it was set to default) and then I can no longer ping 10.0.0.1

which is exactly the correct behaviour! Why?
You now route everything to the MultiWANGroup incl.. your ping! It never hits the box. Thus you need to setup a DNS rule before default rule otherwise it wouldn't work at all.
IF you want ping, then you just need a PING rule above default rule. Please see attached img.

The Starlink Modem is somewhat special!
It hands out via DHCP an IP in the range of 100.64.0.0/10.
The Modem/Roiuter Statistics however are on the dish with IP 192.168.100.1 which is outside the DHCP provided subnet, thus you need to add a virtual IP on you opnsense box with 192.168.100.2/24 on your WAN interface and setup an outbound NAT rule with target 192.168.100.1/32. Please see attached img.

Is WAN_HA on the same subnet as WAN?
You need a seperate subnet for each WAN afaik.

So,

it seems only the LoadBalancing in MultiWAN stopped working somehow, because:

I can flag the other WAN Gateway as down -> Traffic fails over to StarlinkWAN -> working as expected.
I can add a fw rule for specific MAC to be routed via StarlinkWAN -> working as expected. also stops working after couple of min.