Some issues with Starlink bypass mode

@stephenw10 I've just changed the monitoring IP address to 8.8.8.8, and it's still the same - shown as offline, packet loss 100%.

I've restarted the service and no changes unfortunately.

Gertjan

@eoin

Hummm.
The app says : "all is well, and online"

and it also the shows this :

which stands for : just 200 bytes were send, and no bytes came back for you.
Yeah .... that's a pretty solid "no connection" indicator.

Can you hook up a PC, using the default DHCP settings, to this 'starlink' device.
It should work right away, as DHCP is used.
Does it work ?

Can you hook up a PC, using the default DHCP settings, to this 'starlink' device.
It should work right away, as DHCP is used.
Does it work ?

@Gertjan I'm afraid I can't do so. The Starlink router doesn't have any Ethernet ports and it's running with bypass mode, which I believe the same meaning as bridge(?).

I've just rebooted the pfSense and still the same. Strange thing is its public IP address didn't change. I believe Starlink business uses dynamic public IP address. When I rebooted the pfSense multiple times during the day, IP address changes but not this time.

Gertjan

@eoin said in Some issues with Starlink bypass mode:

its public IP address didn't change.

Look at the DHCP logs, the dhcpc ( ? ) entries (from the DHCP client, the one that uses the WAN to obtain your IP/gateway/Dns etc)

@eoin said in Some issues with Starlink bypass mode:

The Starlink router doesn't have any Ethernet ports

A router without Ethernet ?
Can you tell more ?

Use the search function of this forum, enter the magic word.
( starlink )

There are other threads about Starlink + pfSense.
Some just work plain out of the box.
Other never manage to get it working.
Have a look at these threads.

@eoin said in Some issues with Starlink bypass mode:

uses dynamic public IP address

What is a dynamic public IP address ? Isn't that what are doing more then half of all ISPs ?

@Gertjan This is the log. It looks like pfSense grabbed the same IP address this time.

The Starlink router coming with the kit is a Wi-Fi router, it doesn't have Ethernet port at all. To implement a bypass mode, a separate Starlnk Ethernet adapter was purchased and connected to the router. A video tutorial in this article is basically what I followed.

Some ISPs allow the same public IP address to be assigned to the same router all the time. I heard Starlink doesn't do that. So, still public IP address will be assigned but it can be different when re-connected. That's what I meant.

Gertjan

@eoin said in Some issues with Starlink bypass mode:

Some ISPs allow the same public IP address to be assigned to the same router all the time. I heard Starlink doesn't do that. So, still public IP address will be assigned but it can be different when re-connected. That's what I meant.

Ok, get it. That rather typical.

This :

means you'll see a DHCP WAN renewal every 150 seconds .... that's very often, and controlled as per DHCP server (somewhere on the Starlink side).

Something I recognized from way back in the past, when I was using PPPoE :
To reach the RFC1918 IP of my modem device ( also 192.168.100.1 ) I had to add a route like proposed in the guide you used :

Network destination: 192.168.100.0
Subnet Mask: 255.255.255.0
Gateway: 192.168.100.1
Interface: WAN

From what I make of it, this already happens during DHCP negotiation.

It ... just doesn't seem right to me ... ( I could be mistaken of course )

@Gertjan I think I found the root cause and fixed it although I don't know yet.

I went to the site again this morning, rebooted Starlink and pfSense to check, still no luck. However, I found the server that pfSense was installed was getting the public IP address on its out-of-band management interface. It was configured to share the network connection with the first NIC on the server, which is the WAN port.

I changed the configuration of OOB interface not to share the network connection and since then, pfSense started working charm. I rebooted Starlink and pfSense few times to make sure. So far so good.

I suspect upstream ARP table might be confused because of this sharing setup. At the moment, I am waiting for the evening to come because this was when the issue started. If pfSense still works, I will be able to conclude my theory is correct. Fingers crossed.

Gertjan

@eoin

pfSense runs in a VM ?

@Gertjan No, it's a physical 1RU server. I've just checked the connection and it's still working okay. Therefore, I believe the OOB interface configuration would have been the issue.

I'll check again a couple of hours later tonight.

stephenw10

Yup, you definitely don't want interface sharing on he WAN like that. Better to have a discrete NIC for OOB but if it must be shared make sure that's not the WAN!

Checked the connection last night and this morning again, confirmed it's still good. So, I believe this was the issue 100%.

Glad I can go home with no worries. Thanks guys.