Messages

>>My use of OPNSense is actually *above* the M470, using the exact same modules and fibre leads.

Can you expand on this? Do you mean *above* physically in the picture?

Thanks for the input.

No, I mean above the watchguard as in the M470 is downstream of multiple OPNSense routers.

In my picture the 3 little black routers (R86S) all run OPNSense, One for each separate 10G leased line (MultiWAN with BT and Virgin in the M470) and the 3rd one at the bottom is for routing IPv6 as the WG is crap with IPv6.

Does this module look like the same part as yours?

It is indeed that exact module that I use.....
I use MMF Fibre between the Firebox and my 10G Unifi switches. 
My use of OPNSense is actually *above* the M470, using the exact same modules and fibre leads.

Dont know if this will work, but here is a picture:
https://ibb.co/B5m6xxHG
If that doesnt work try this:
https://postimg.cc/wyc7sZJH

Not that this helps you much, but I also have a Watchguard M470 with a 4 port SFP+ module and I'm using it as designed, so its running Fireware 12.11.4.

It's easily pushing 5Gbps through the SFP+ without a sweat, and I use the Cisco SFP-10G-SR Compatible 10GBASE-SR SFP+ 850nm 300m DOM Duplex LC/UPC MMF Optical Transceiver Module from FS.com.

So the device itself is capable of those speeds.

Ahhh, solved.  It was the \r \n formatting in the key.

Got it working now

$keyPem  = (Get-Content -Raw $PrivKeyPath)   -replace "`r`n","`n"

I'm trying to use the API to import a new TLS certificate for the WebGUI.

I keep getting:
HTTP 500
{"errorMessage":"Invalid private key provided: cannot parse private key data","errorTitle":"Certificate error"}

The certificate is an EC certificate that is accepted manually by the GUI, but is there something in the API that wont accept an EC private key?
e.g.: -----BEGIN EC PRIVATE KEY-----

I've got a feeling this will work with an RSA certificate, but as I don't have one, its hard to test.

TIA

Well, that was scary, but I've successfully updated all mine from EEPROM V2.17-0 eTrack 0x80000308 to EEPROM V2.32-0 eTrack 0x80000425.

I used the reboot.sh method for the in use NIC's which worked *perfectly*.

Everything seems to be great.....

Thanks everyone for this extremely useful post.....

I had a similar issue with portal.azure.com

My issue was because I get IPv6 over WireGuard Tunnel and the issue was MTU size.

Reducing the MTU to 1280 made it work.

Not that it helps you, but I've upgraded 4 OPNSense routers from 25.7 to 25.7.1 with no issues whatsoever.

If it helps anyone, I've successfully upgraded:
A CWWK N100, AliExpress jobber with os-cpu-microcode-intel installed
Numerous R86S N100's with os-cpu-microcode-intel installed

So far, all have upgraded with no issues. (3 done so far, 1 to go)

Upgraded my spare R86S router, with basic config, with no issues.

Entire process was smooth.

Will start upgrading the other 4 in least important order :)

I guess because I saw on X "OPNSense 27.5 released..." and assumed it would be there? :)

Same, and I'm not using a mirror...

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q3/008804.html

This was where any RIO discussion seemed to have ended in a non implementation of it.

That kind of explains it all :)

What's interesting is their comments on how different OS's deal with RIO's does not match my experience :)

I'll stick with OPNSense RADVD......let's hope it stays around forever.

One day, maybe my ISP will support IPv6, and I can just launch GUA's out and forget about this experience.......

Completely agree.

As I say, I'm back with OPNSense's RADVD now and its working perfect.

Shame really, as would be nice to house everything in DNSMasq, but DHCP and DNS will do for now......

Thanks for everyones help with this....

Thanks,

The issue I am seeing is as follows:

In my home lab, I get my IPv6 from a VPS over Wireguard on OPNSense.

I am using ULA on my LAN, with NPTv6 to get out to the internet.
I do this almost to depreference IPv6, as most OS will choose IPv4 over an IPv6 ULA. (IPv6 slower link over wireguard, and data caps)

This actually works really well with OPNSense's built in Router Advertisements.

When trying to use DNSMasq, it seems the route info option (24), or lack of, is a critical part of making what I do work.

What was happening last night, was when I started using DNSMasq to advertise, the lack of RIO (24), allows other devices on my network to announce a ULA prefix.
Namely, an Amazon Echo Studio.  It started advertising an fd35: prefix, which gets picked up by my Linux server, which now has both (fd35, and my advertised fd76)
As I mention, iOS and Windows seem to cope with this, but Linux prefers the ULA with RIO (24) as its source address and thus....no access outbound.
Deprefrencing the fd35 address (lft 0), and it then works.

When using OPNSense Router Advertisements, it includes RIO(24), and the Amazon echo, on seeing this, stops advertising its own prefix, and my Linux server starts to work.

As I said, the way I do IPv6 is horrible, but better than not having it at all.

For now, I'm back to using OPNSense RA's, and everything is working.

My head hurts a lot from deep diving tcpdump.....