Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Some issues with Starlink bypass mode

    Scheduled Pinned Locked Moved General pfSense Questions
    24 Posts 3 Posters 8.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • GertjanG
      Gertjan @A Former User
      last edited by

      @eoin

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

      and it also the shows this :

      6a047207-4c9c-4dde-b88d-637759ca6588-image.png

      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 ?

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

      ? 1 Reply Last reply Reply Quote 0
      • ?
        A Former User @Gertjan
        last edited by

        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.

        GertjanG 1 Reply Last reply Reply Quote 0
        • GertjanG
          Gertjan @A Former User
          last edited by

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

          No "help me" PM's please. Use the forum, the community will thank you.
          Edit : and where are the logs ??

          ? 1 Reply Last reply Reply Quote 0
          • ?
            A Former User @Gertjan
            last edited by

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

            02078357-b314-4502-a26f-1221b461935c-image.png

            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.

            GertjanG 1 Reply Last reply Reply Quote 0
            • GertjanG
              Gertjan @A Former User
              last edited by 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 :
              4f94a9ac-4e50-4363-bce1-1092183620f1-image.png

              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.

              4e38a04e-f363-4d31-a00e-22dd9ee609a6-image.png

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

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              ? 1 Reply Last reply Reply Quote 0
              • ?
                A Former User @Gertjan
                last edited by

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

                GertjanG 1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan @A Former User
                  last edited by

                  @eoin

                  pfSense runs in a VM ?

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  ? 1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User @Gertjan
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      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!

                      1 Reply Last reply Reply Quote 0
                      • ?
                        A Former User
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.