Messages

I've come across this blog post, which also confirms that the DEC750 wouldn't be capable of reaching 10Gbps in my use case

https://blog.shade.sh/index.php/archive/2116

I've turned on hyperthreading in BIOS and applied these settings which allow all 8 cores to process interrupts as described in the post. This got my internet iperf3 performance up to 6.2Gbps, speedtest.net to 5Gbps, which is a small improvement, but I guess this is as fast as it will get.

Hey there ;) Glad that my Posts are still somehow useful. I did a lot of tests on my Init7 10G line and never got over the maximum posted on my blog.
But im open for other missing optimisation vaules, i maybe had overseen. My personal opinion is, that you need at least the DEC850 to reach true 10G

Smooth as silk. New Dashboard looks easy to customize.
As I have heard, this release was not easy and smooth as silk ;).

And that's exactly why: Many thanks to all developers and contributors!

First of all. 192.0.0.0/24 is not a RFC1918 (e.g. its a public ip range), so somewhere its "correct" routed to public internet. Before you can test the NAT you need to solve the routing issue. Is the Opnsense the only default gateway used on the 10.0.0.2 side? Do you see a routing table entry on the opnsense for both networks going into the tunnel? Are there two SA created for it under the ipsec section?

I have AirVPN configs downloaded to my laptop and iPhone and they are blazingly fast.

Try to play with the MTU (On both sides same value - Dont know if your VPN service published their MTU).
Something between 1412 and 1380 should do the trick.
It also depends a bit on IPv4 only or IPv6.
You can try it by hand or follow this guide and test it with iperf: https://gist.github.com/nitred/f16850ca48c48c79bf422e90ee5b9d95

Try to add a SNAT Rule on the dedicated to be inside the 10.90.0.0/24, if this net is included in the wireguard tunnel, it should work. Because now it seems that the public client ip from the request goes into the tunnel. You have to translate the request into something "private" which is included in the tunnel.

Hi,

I know that there are plenty problems with this combination but mine should be "fixable".
Every night I found out that my PPPoE goes down, maybe because of the forced disconnect by Telekom Deutschland, anyway after this disconnect it seems DHCPv6 are not longer working. Is somehow alive:

Code Select Expand

root@gw:~ # ps auxww | grep dhcp
root 85069   0.0  0.1  12796   2244  -  Is   08:38       0:00.14 /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid

But the web interface shows a red stop sign and its not possible to start it from there. The only way to bring it back to life is to kill it and start it again both via CLI.

Code Select Expand

root@gw:~ # kill -15 85069

root@gw:~ # ps auxww | grep dhcp
root 50303   0.0  0.0    432    248  0  R+   08:21       0:00.00 grep dhcp

root@gw:~ # /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid

root@gw:~ # ps auxww | grep dhcp
dhcpd  5501   2.3  0.5 22600 10364  -  Ss   08:21       0:00.02 /usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid re1_vlan2 re1
root   6550   2.2  0.1 12652  1768  -  Ss   08:21       0:00.00 /usr/local/sbin/dhcpleases6 -c /usr/local/sbin/configctl dhcpd update prefixes -l /var/dhcpd/var/db/dhcpd6.leases
root  94878   0.0  0.1 12796  2100  -  Ss   08:21       0:00.00 /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid

The relevant log just stops here:

Code Select Expand

<190>1 2022-07-07T03:29:00+02:00 gw.shade.sh dhcpd 7982 - [meta sequenceId="2"] Reply NA: address 2003:cd:d705:a100::1b2d to client with duid 00:01:00:01:25:1e:c1:c1:b8:27:eb:2f:cf:98 iaid = -349188200 valid for 7200 seconds
<190>1 2022-07-07T03:29:00+02:00 gw.shade.sh dhcpd 7982 - [meta sequenceId="3"] Sending Reply to fe80::783c:69eb:a1:416b port 546


To solve things like this:

Code Select Expand

dig @8.8.8.8 heise.de   
;; reply from unexpected source: 10.20.30.4#53, expected 8.8.8.8#53
;; reply from unexpected source: 10.20.30.4#53, expected 8.8.8.8#53
;; reply from unexpected source: 10.20.30.4#53, expected 8.8.8.8#53

Where 10.20.30.4 is one of my internal DNS server.

Hey,

after upgrading to 21.1 the system cannot be upgraded to newer versions.
I always get a mismatch in freebsd version for different packages.
E.g.

Code Select Expand

root@gw:~ # pkg update
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB   6.4MB/s    00:01   
Processing entries:   0%
Newer FreeBSD version for package php73-pear-channel-horde:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1202000
- running kernel: 1201000
Ignore the mismatch and continue? [y/N]:
pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Error updating repositories!
root@gw:~ # uname -a
FreeBSD gw 12.1-RELEASE-p12-HBSD FreeBSD 12.1-RELEASE-p12-HBSD #0  3c6040c7243(stable/21.1)-dirty: Mon Jan 25 12:27:52 CET 2021 root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP  amd64

Looks like for now "Disable State Killing on Gateway Failure" is a solution for that. I have to test what happens when my main line is down ;) - Would be really nice to have such a feature only for the non active gateway.

I already tried with different priorities (255 on LTE backup and 254 on main line). No change in behavior when the LTE backup reached the threshold e.g. is offline.

Could be "Disable State Killing on Gateway Failure" a solution for that?

My problem is, i have a lot MQTT devices in different VLANs, every time the LTE Backup have a problem, the MQTT devices also disconnects because the OPNSense is the gateway and firewall for my VLANs at home.

Looks like there is already a discussion about this: https://github.com/pfsense/pfsense/pull/4159

Same problem here with LTE as backup... the whole gateway has a short hicup when the Backup Line is dead or has reached the threshold.

https://forum.opnsense.org/index.php?topic=16666.msg76127#msg76127

Are you sure you're using a Active / Standby Setup? I have here a similar setup (VDSL with LTE backup). If my VDSL is stable for a long time, i only have a very few data (from the ping monitoring) on my LTE WAN. There should be no DNS resolving on Tier2 (WAN2) if you're using it as standby line. It's not recommended to disable gateway monitoring if you're using a multi wan setup. Afaik you have to set gateway priority only if you're using a active / active setup with load balancing over both lines.

The Rule "let out anything from firewall host itself" you are searching is under "Floating" Rules Tab and there on the upper right you'll find a symbol named "Automatically generated rules".

And... I do not have syslogd on any potential receiving server, but only systemd-journald. Can I use that also?
Thank you.

Don't think so... you need at least rsyslogd or syslogd installed and configured to receive logs from remote devices.

Should be listed there, look at the screenshot.
Btw. syslog-ng is for remote-logging and syslog for local logging.