Messages

Thanks for posting this (and the update!) I had a client down due to this yesterday, and could only isolate it to something going on with Starlink.

I found this reddit post that suggests if you boot the dishy up connected to the stock router, once it's been up for a few minutes, you can remove it and put your own 3rd party router back in. Then it should work until the next time the dishy reboots: https://www.reddit.com/r/Starlink/comments/1bjr8yf/how_i_mostly_got_back_to_normal_with_a_gen1_the/

Also found this unofficial starlink-related site stating the problem: https://www.starlinkhardware.com/firmware-updates/

Hopefully this gets fixed soon.

Clean install / reconfigured from scratch a relatively simple setup: Static WAN, LAN, WLAN, HE TunnelBroker, OpenVPN Server Instance. Everything is working great!

Of course, windows is very exploitable in general. This is not news. The issue is how you protect it. Your internal machines should never be reachable from the internet. That's something any firewall can accomplish, when properly configured, including opnsense, like codera said. You need to set up the correct rules to prevent inbound connections and avoid using technologies that bypass them like port forwarding, pinholes, upnp, cloud based remote access, etc.

Back up your config and start from a clean install - primary WAN and LAN only with default rules. Add Plex and Jabber for family harmony and test the ping again.

Add features back in until it breaks, then analyse what broke it.

I agree with bartjsmit. This could be any of many possibilities with your network configuration. We won't find it by guessing. The best way to find out is by backing up your current configuration, resetting to defaults, and configuring again, checking at each step for broken ping. Then you can analyze what it is about that step that's preventing the ping from working. If things get too hairy, or it takes too long, you can always restore your old working configuration from backup and be right back where you were before.

Your screenshots look similar to mine. I use Unmanaged (SLAAC only) instead of Assisted (SLAAC + DHCPv6) but that's a matter of preference and shouldn't make a difference.

When you say "clients do not receive ipv6", do you mean they don't get IPv6 addresses assigned? Double-check RADVD and DHCPDv6 services are running in System-Diagnostics-Services. Also, double-check client NIC configuration- is IPv6 enabled as a protocol?

Also- you did not share screenshot of LAN Interface Configuration/Overview. Make sure it is configured with and has a static IPv6 address in the /64 you need your clients to receive addresses in.

Hope that helps!

Well, two and a half weeks later and the IPv6 addresses and prefixes have not changed since installing the patch. So I can't say whether or not this works for us or not. But stable prefixes are even better!

Moral of the story is... I guess you never know what to expect with the "better than nothing beta" Starlink.  :)

Hi, you followed this guide? https://docs.opnsense.org/manual/how-tos/proxytransparent.html

You probably need to import the certificate into the Firefox Browser and not the OS. Or enable Firefox to search and import OS CA's: https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox

I got the client's firewall upgraded and the patch has been applied. I'll update here the results here when the prefix changes for future people finding this topic by search.

Thanks, Franco!

Unfortunately, I get this:

Code Select Expand

Fetched 3cb2dd7669a via https://github.com/opnsense/core
1 out of 1 hunks failed while patching etc/inc/plugins.inc.d/dhcpd.inc

I assume it's because I'm not updated with 23.1 yet, correct?

Configuration details below. As in the title, the IPv6 delegated prefix is never getting updated for LAN devices. I'm not using DHCPv6 on the LAN, I only want SLAAC addresses. This works for the most part. But for some reason, when the delegated prefix changes (thanks, Starlink), the prefix is updated on the (tracking) LAN interfaces but RADVD never gets updated.

If on Interfaces/Overview/WAN I click reload for DHCPv4/v6, then it immediately updates and the devices are all happy with correct IPv6 addresses. Is there something wrong in the config below, or is this a known issue? I checked github for issues and some of them seem like they could apply but I am not sure.

OPNsense 22.7.11_1-amd64
ISP: Starlink with CGNAT and IPv6: WAN Address stays the same, but delegated prefix changes every few days
WAN IPv6 Configuration Type: DHCPv6
Request only an IPv6 prefix: Checked
Prefix delegation size: 56
Send IPv6 prefix hint: Not Checked
Use IPv4 connectivity: Not Checked
Use VLAN priority: Not Checked
LAN  IPv6 Configuration Type: Track Interface
Track IPv6 Interface: WAN
IPv6 Prefix ID: 0x0
Manual configuration: Allow manual adjustment of DHCPv6 and Router Advertisements : Checked
Enable DHCPv6 server on LAN interface: Not Checked
Available prefix delegation size: 57 bits (informational only field)
Router Advertisements: Unmanaged
Router Priority: Normal

I just upgraded from 19.1 to 19.7 Jazzy Jaguar. I was reviewing the upgrade log and noticed this:

Code Select Expand

Message from opnsense-19.7.1:

Roar!


Nice easter egg!  8)

Deciso DEC600 A10 Dual Core
OPNsense 19.1.4-amd64
FreeBSD 11.2-RELEASE-p9-HBSD
OpenSSL 1.0.2r 26 Feb 2019

Scratching my head on this one. What are the proper combination of settings to enable hardware assisted crypto in OpenVPN?

Is this help still valid under Miscellaneous: Settings: Cryptography settings: Hardware acceleration (Current setting: AES-NI CPU-based Acceleration (aesni))

"... OpenVPN should be set for AES-128-CBC and have cryptodev enabled for hardware acceleration."

VPN: OpenVPN: Servers: Hardware Crypto shows "No Hardware Crypto Acceleration" and no other options can be selected for that field.

From the hardware documentation:

"Hardware acceleration:    SoC has integrated AESNI instructionset including support for GCM"
"Hardware Assisted Encryption: 600Mbps IPsec (AES256GCM16)"

I tried siwtching it between none and track.  It worked at the time.

Awesome!

Also didn't know that THAT is what the prefix ID is for, and why when I changed it I got a different prefix that still started with 2601.  The last 4 of the prefix were different, which means comcast is probably giving me at least a /48 prefix, right?

Did all four hex characters in the fourth quartet change? If so, then I would think so. But your PD (prefix delegation) would be specified in your Comcast Gateway's configuration pages and in your account on their website.

And if SLAAC can't do DNS at all, what would the best method be for syncing them to DNS records?

That's an area I haven't delved into yet. You may want to start a new thread for that.

Edit: I misunderstood your post, so I'm re-replying after re-reading.

Your clients should be creating their own IP addresses based on the RAs (router advertisements) from your OPNsense router through NDP (neigbor discovery protocol). The RAs should be based on the router's LAN address they are seeing on their LAN (or VLAN). If they are constructing their IPv6 with SLAAC starting with 2601, then that's probably the advertisement they are getting from OPNsense. Is OPNsense's LAN address starting with 2601 or 2001? If that's what you meant at the end where you said "Track Interface" was obtaining the old prefix of 2601, then maybe this will help:

I think I remember reading somewhere you can work around DHCP issues somehow by changing the "IPv6 Prefix ID" field on the LAN Interface settings. Usually you would just leave it at 0. But depending on how many /64s you can get out of your prefix delegation, you can change it to select the 2nd /64 prefix, or the 3rd, etc. going up by integers in hex. So I've got a /59. That means there are 5 bits left for subnetting, giving me 2^5 or 32 subnet/prefix IDs. So I can have anything between 0 and 1F there for prefix ID (if my hex math is right). The idea is this: if you change your prefix ID, you can get the service provider's DHCP server's attention when somehow before you were not.

You also could try toggling your LAN IPv6 settings between "None" and "Track Interface" to try to clear it that way.

Regarding DNS, that would be handled via DHCPv6 or static configuration on the host. As far as I know, SLAAC doesn't do DNS. Maybe someone else could chime in on this one.

Earlier, you stated "I have my WAN configured to use DHCPv6 to request only a /64 prefix". You may need to change this by clearing that "Request only an IPv6 prefix" checkbox for the DHCP process to work.