Some issues with Starlink bypass mode

@stephenw10 I didn't touch any default settings. Below is the current setup.

Gertjan

I think he is :

I just checked, 8.8.8.8 is still responding to ping.

So this boils down to a classic connection loss.

@eoin : normally, when the "dpinger", the process that monitors the WAN connection, detects a significant ping loss, it will take action.
dpinger : you can see it log lines in the system log.

The 'action' is : it will take the WAN down, and UP again.This will start a (new) DHCP client DHCP request, so that a new (or the same) IP, gateway, DNS etc can be obtained.
This will work out just fine if the connection actually works.
If it doesn't : doesn't have Starlink some sort of GUI where you can see the satellite alignment, connection quality etc ?

stephenw10

Those static routes are added because they are set as DNS servers.

But, yes, try setting 8.8.8.8 as the monitoring IP and see if it changes.
If it is some upstream block you might need to reboot to clear it. Or just wait.

@Gertjan Thanks, I changed some parameters and this is the graph I got.

I don't get it.
You created an inbound rule, so you can ping 'to' pfSense (over the Starlink WAN connection) using another local internet connection, for example the data connection of your phone ?

Yes, I added inbound rule to WAN interface and pinged from my laptop using a different internet source. pfSense responded okay.

I didn't touch any gateway monitoring setup. WAN interface received IP address via DHCP and that's it. No configurations were touched.

stephenw10

Sure sounds like an upstream blocking rule for your outbound traffic.

@Gertjan I've just taken a screenshot from the phone.

The app says it has an unobstructed view of sky. I believe this means clear sky.

@stephenw10 That sounds really strange. It's almost 11 pm here. Does Starlink blocks traffic in night time? Also, it doesn't explain why my OpenVPN connection attempt not working either in my eyes.

@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.