Recent posts

#1

Hardware and Performance / Re: Inseego MiFi Pro M4 as WAN...

Last post by Greg_E - Today at 03:09:51 PM

This device says it can offer IPPT (IP passthrough) so I think that would be as close to bridge as possible. But it might also be restricted by the carrier, should know more soon. There seem to be a lot of business oriented features in the OS, I'm guessing this is a pretty common thing to use for backup or other remote office.

I wish it had Netbird built in, there are some more common vpn choices, but didn't see anything I'm currently able to use.

Would also be nice if this could be POE powered, but I didn't see that in the manual either. Would just make my lab system easier to handle. It does have a battery that can be removed for in place uses like business backup wan. It also has a battery saver mode for constant power connection that keeps charge between 70 and 80 percent, might end up using this feature.

Bought the 100GB plan, that will probably be plenty as I look at what I actually use in a month at home and this will get less use.

#2

26.1, 26,4 Series / Re: Unable to achieve 2.5Gbps ...

Last post by sternchen45 - Today at 03:07:41 PM

Multi-Gig-Modes (2.5 and 5Gbps) are not a mandatory part of an implementation of 10GBaseT. In other words, if one interface advertises the mode and the other doesnt know it, they cannot link in that mode, but only in the highest common mode.

There is no way of adding the mode if the interface doesnt know it (usually, in production).

#3

Zenarmor (Sensei) / Re: Install/Deinstall Loop (li...

Last post by ureyni - Today at 02:40:51 PM

Hi Mlenje,

Could you please update the repositories using the force parameter?

root@OPNsense:/usr/local/etc/pkg/repos # pkg update -f
Updating OPNsense repository catalogue...
Fetching meta.conf: 100%    179 B   0.2kB/s    00:01   
Fetching data.pkg: 100%  328 KiB 335.5kB/s    00:01   
Processing entries: 100%
OPNsense repository update completed. 931 packages processed.
Updating SunnyValley repository catalogue...
Fetching meta.conf: 100%    179 B   0.2kB/s    00:01   
Fetching data.pkg: 100%   21 KiB  21.1kB/s    00:01   
Processing entries: 100%
SunnyValley repository update completed. 14 packages processed.
All repositories are up to date.

root@OPNsense:/usr/local/etc/pkg/repos # pkg search -r SunnyValley libdeflate
root@OPNsense:/usr/local/etc/pkg/repos # pkg search -r SunnyValley graphite2
root@OPNsense:/usr/local/etc/pkg/repos #

Please note that libdeflate and graphite2 are not present in the Sunnyvalley repo.

Could you try reproducing the issue again via WebGUI → Firmware Status?

 

#4

26.1, 26,4 Series / Re: [SOLVED - ONT Failure] Deg...

Last post by nero355 - Today at 01:49:45 PM

Now to return all the shit I bought when troubleshooting back to Amazon... -_-

Hehehe! Good luck! :P

And congratulations on the new ONT !!! WooHoo !!! ^_^

#5

25.7, 25.10 Legacy Series / Re: Disable hardware TCP segme...

Last post by Dark-Sider - Today at 01:12:07 PM

Hi,

I'm running opnSense on a china-box with intel 1Gbit/s NICs (igbn).

What's the CPU model exactly ?

PPPoE depends a lot on the Single Core Performance of the CPU when using FreeBSD based software !!

Yeah I know that pppoe on FreeBSD is limited by a single core - sadly. The CPU in question is a "Intel(R) Core(TM) i7-5550U CPU @ 2.00GHz". After tweaking around I hadn't had any issues on any of my opnSense installations to get speeds of >1 Gbit/s through a PPPoE link.

I was just wondering why the segmentation offloading seems to interact with using PPPoE.

#6

General Discussion / Re: Wireguard as (Multi-)WAN: ...

Last post by inkeliz - Today at 12:16:48 PM

You have to go in the firewall-rule on your WireGuard-interface, which allows the traffic, tick advanced mode and then set the reply-to to your gateway of choice: WireGuard.

I didn't see the 'Advanced' toggle in `Rules [new]` dialog.

Editing each rule and adding Reply-To to 'WAN_WIREGUARD_GW' works. Thank you.

#7

26.1, 26,4 Series / Re: ISC DHCPv6: Router chain: ...

Last post by Monviech (Cedrik) - Today at 11:37:23 AM

Also consider using KEA for the dynamic prefix delegation to stay in the supported scope:

https://docs.opnsense.org/manual/kea.html#prefix-delegation-ia-pd

Additional to the above documentation I also answered some question about it here recently:
https://forum.opnsense.org/index.php?topic=52169.0

#8

General Discussion / Re: Wireguard as (Multi-)WAN: ...

Last post by Bob.Dig - Today at 11:33:10 AM

So you testing externally, ok. A network diagram could help, especially what is ULA and what is GUA.
None the less, WireGuard-interfaces don't have reply-to by default. You have to go in the firewall-rule on your WireGuard-interface, which allows the traffic, tick advanced mode and then set the reply-to to your gateway of choice: WireGuard.

You have a lot of other variables though, so good luck. :)

#9

General Discussion / Re: Wireguard as (Multi-)WAN: ...

Last post by inkeliz - Today at 11:11:20 AM

If I send one UDP/TCP/ICMP packet to 2001:my:isp:1111::4242 I get a reply from the same 2001:my:isp:1111::4242.

What does this even mean. You ping your own IP-addresses? This is not a valid test I would guess.

That means that it works, because the reply is from the same IP of the target. If I send a ping to 1.1.1.1 I get a reply from 1.1.1.1.

The issue is: when you ping 1.1.1.1 and get a reply from 2.2.2.2 (because 2.2.2.2 is the other WAN). That happens because of multi-WAN, the output uses another WAN (2.2.2.2) instead of the right WAN (1.1.1.1).


I will clarify, I have the following interfaces:
- WAN_MEO          (i.e 2111::/56)
- WAN_NOS          (i.e 2222::/56)
- WAN_WIREGUARD    (i.e 2333::/56)

I have one LAN:
- LAN               (fdcc::/64)

I'm pinging from the internet (example: https://fra-de-ping.vultr.com):

2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2111::1234 (WAN_MEO) -> fdcc::1234 = Works
2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2222::1234 (WAN_NOS) -> fdcc::1234 = Works
2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2333::1234 (WAN_WIREGUARD) -> fdcc::1234 = Fail

The Wireguard fails because the reply/response uses WAN_MEO or WAN_NOS instead of WAN_WIREGUARD.

Basically, you (in the internet) send ICMP to 2333::1234 and receives a ICMP reply from 2111::1234, of course it doesn't work. I can't find a way to force the exit to match the input. The "reply-to" works for WAN_NOS and WAN_MEO, but doesn't apply to WAN_WIREGUARD.

#10

26.1, 26,4 Series / Re: ISC DHCPv6: Router chain: ...

Last post by dseven - Today at 11:02:20 AM

Your prefix delegation range looks wrong. It needs to be the start of a /59 prefix - "::a0" is (obviously?) not that...