Messages

@_Alchemist_ I realize this is 4 years later, and we have instances instead of servers now. But shouldn't

Code Select Expand

- Interface                                WAN2
- Protocol                                 UDP
- Destination                            WAN1 address
be

Code Select Expand

- Interface                                WAN2
- Protocol                                 UDP
- Destination                            WAN2 address
?

Thanks, franco!

I have a couple of clients with multi-wan on 25.1, they are not upgraded yet (thanks for posting!). Please do update when you find a fix.

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)"