Messages

Can confirm that the patch worked as well for my OpenVPN client I had running and that did not come back up with todays update.

Level 5 logs just show <code>got control cmd quit</code> for every thread, so not much more info there.

Code Select Expand


2022-07-30T00:22:10 Informational unbound [12754:0] info: server stats for thread 0: 198 queries, 61 answers from cache, 137 recursions, 0 prefetch, 0 rejected by ip ratelimiting
2022-07-30T00:22:10 Debug unbound [12754:0] debug: comm_point_close of 36: event_del
2022-07-30T00:22:10 Debug unbound [12754:0] debug: cleanup.
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 7
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 7
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 6
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 6
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 5
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 5
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 4
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 4
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 3
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 3
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 2
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 2
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join success 1
2022-07-30T00:22:10 Debug unbound [12754:1] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:6] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:7] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:0] debug: join 1
2022-07-30T00:22:10 Debug unbound [12754:5] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:3] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:4] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:2] debug: got control cmd quit
2022-07-30T00:22:10 Debug unbound [12754:0] debug: stop threads
2022-07-30T00:22:10 Informational unbound [12754:0] info: service stopped (unbound 1.16.1).
2022-07-30T00:22:09 Informational unbound [12754:3] info: send_udp over interface: 127.0.0.1
2022-07-30T00:22:09 Debug unbound [12754:3] debug: using localzone . transparent
2022-07-30T00:22:09 Informational unbound [12754:3] info: receive_udp on interface: 127.0.0.1
2022-07-30T00:22:09 Informational unbound [12754:5] info: send_udp over interface: 127.0.0.1
2022-07-30T00:22:09 Debug unbound [12754:5] debug: using localzone localdomain. transparent
2022-07-30T00:22:09 Informational unbound [12754:5] info: receive_udp on interface: 127.0.0.1


Same here, except it seems to be every 45 minutes, see attachment. I increased verbosity, maybe something comes up.

Applied the patch, reactivated the rules, looking good so far!

Had to deactivate all IPv6 related outbound NATs (and to be safe firewall routes) that are related to selective routing through VPN, at least VPN over IPv4 is working again now. No idea whats wrong with IPv6 though.

First, congrats on the new version!

Just did an upgrade at home and I use OPNsense as mullvad client over wireguard and an openvpn client to one of my work clients. After the upgrade, wireguard is offline in the interface monitoring, openvpn shows up, but none of the routes work.

Most of the setup is based on the opensense manual, like https://docs.opnsense.org/manual/how-tos/wireguard-client-mullvad.html and others.

I can't seem to find any hint why none of the VPN routes work anymore. The only logfile entry that seems relevant are build like this:

Code Select Expand


Error firewall There were error(s) loading the rules: /tmp/rules.debug:116: syntax error - The line in question reads [116]: nat log on ovpnc1 inet6 from (igb0:network),fe80::/10 to $vpn_XXX_targets -> (ovpnc1:0) port 1024:65535 # LAN to XXX IPv6 NAT


Any clue what changed from 22.1 to 22.7 that could be related to this?

Yeah same here. The manufacturer mentions trim support for the NVMe model number, I assumed it should work.

Coming from Debian myself, it's quite the jungle sometimes. hdparm is not available, sdparm -l -a /dev/nvme0 does not show anything worthwhile in that category.

Maybe trim -N -q /dev/nvd0 would return an actual exit code > 0 if the device does not support TRIM, but I'm at a loss.

Thanks, I just tried to check it with the command you mentioned, but it does not accept any device name given and I'm not really sure what the device unit name would be or how to list them, here is what I tried:

Code Select Expand


> camcontrol devlist
# no output

> geom disk list
Geom name: nvd0
Providers:
1. Name: nvd0
   Mediasize: 256060514304 (238G)

> camcontrol identify nvme0
> camcontrol identify /dev/nvme0
> camcontrol identify nvd0
> camcontrol identify /dev/nvd0
# tried with the common ones listed in /dev, all end up with the same error
camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
cam_lookup_pass: No such file or directory
cam_lookup_pass: either the pass driver isn't in your kernel
cam_lookup_pass: or nvd0 doesn't exist


I did manually enabled it with the following commands during single user mode

Code Select Expand


fsck -y
tunefs -t enable /
reboot


and it seems to stick.

Strange that the device was delivered with it turned off. Same for noatime which was not set, but it is mentioned in the docs. Was wondering why the device gained about 10-20GB written per day in a small home office setup. After some debugging it turned out that the RRD data was mostly responsible for that.

What is the best way to go about this, contact Deciso support directly, not sure if they aware of that?

I've gone through some SMART details and reviews and on a test device I've seen that TRIM is disabled on a DEC750.

Code Select Expand


root@OPNsense:/usr/ports/sysutils # tunefs -p /
tunefs: trim: (-t)                                         disabled


The device itself is of the model TS256GMTE652T2 NVMe and it should support trim.

The current written units are ~680GB after 60 days.

If I work with the web proxy feature, should TRIM be enabled and if so, what would be the correct way to do so?

So, if anyone else has this problem with a samey setup: Fiddle with the guest isolation enforced by the unifi devices, that's the point where the traffic gets dropped. Solved the case for me.

Hi there,

tried to get a captive portal demo working on a VLAN 30, with the parent being the LAN interface, on a DEC750, OPNsense 22.1.5-amd64.

- I've created the DHCP for guests to be 192.168.111.1/24.
- I followed the setup guide to come up with a reduced "no authentication" / splash screen setup.

Everything works when I do not activate the captive portal, browsing is possible, correct IP is assigned.

I then add a captive portal on the VLAN 30 interface, no auth, no enforced group. The client connects, gets an IP assigned via DHCP, gets redirected to http://192.168.111.1:8000/index.html and runs into a block / hanging connection that times out.

I also add an "allow everything on guest" rule just to be sure.

I can curl http://192.168.111.1:8000 from LAN and on the opnsense shell itself and get the template as response. A curl from the guest client runs into the block.

If I add the client mac to the allowed list of the captive portal, I can browse everything from the client, but still not access http://192.168.111.1:8000.

I've enabled a log for all known firewall rules but there is no relevant entry in the firewall live view.

Any idea what I'm doing wrong?

What is a no can do? You quoted a document that is specifically designed for DoD/NSS/DIB and their stakeholders.

The thing is, what is your budget to discuss and secure your requirements with a security professional? Finishing a target specification would need to be done, tests need to complete, samples need to be taken, users must be briefed. What do you exactly expect to be done for what exact budget, what happens on rule changes or exceptions to same?

Do not underestimate the cost of IT security. Try to learn it yourself if it is for small / self employment, things are not insecure by default, you just need to come up with the right exceptions. Last time I had a Cisco-guy under my desk for a day was above just short over 3k.

Nur dem Verständnis wegen: Das Problem ist die Daten über HTTP/HTTPS nicht korrekt transportiert werden, ICMP und andere Protokolle funktionieren einwandfrei wenn ich das richtig lese korrekt?

Du hast keinen Webproxy aktiviert und verteilst auch keine DHCP-Optionen die einen Webproxy vorschlagen, der dann nicht erreichbar ist?

Adguard DNS ist bei dir selbst gehostet oder verwendest du deren Public DNS-Server und wenn ja, welche Variante / welche Filterlisten gehen da rüber?

Bei dir geht das Repo selbst langsam, die Webseite absolut gar nicht?

Weder opn-repo.routerperformance.net noch www.routerperformance.net sind über IPv6 erreichbar, von daher sollte es tatsächlich kein Problem damit sein, es sei denn dein Anbieter muss IPv4 tunneln, was durchaus eine Fehlerquelle sein könnte.

Rein vom Nameserver-Eintrag her sehe ich auch kein Problem

Code Select Expand


www.routerperformance.net. 3600 IN      CNAME   web03-01.max-it.de.
web03-01.max-it.de.     86400   IN      A       81.24.64.215


sonst dürfte es schon mit der Auflösung Probleme geben.

Was bedeutet "mit Hängen und Würgen" bei einem Upgrade, was genau ist denn das Problem? Verwendest du Hardware- oder Software Offloading für die Netzwerkkarten?

Hast du ausgeschlossen das es nicht einfach nur am Server von routerperformance.net liegen könnte? ICMP ist einfacher beantwortet als ein überlasteter NGINX, der auf einem 5€ Host läuft mit gedrosselter CPU/Bandbreite.

Was genau passiert wenn du über cURL eine Verbindung aufbaust von einem Client der Probleme macht?

Code Select Expand


curl -i --trace - https://opn-repo.routerperformance.net

== Info:   Trying 46.16.78.247:443...
== Info: TCP_NODELAY set
== Info: Connected to opn-repo.routerperformance.net (46.16.78.247) port 443 (#0)
== Info: ALPN, offering h2
== Info: ALPN, offering http/1.1


Hast du geprüft das es nicht ein Problem mit einer deiner beiden WAN-Leitungen sein kann?

Ansonsten kann ich da nicht mehr raus lesen, da das echt viel gleichzeitig ist was da schief gehen könnte. Du schreibst zwar das du über eine Link Local-Adresse auf die FritzBox routest am Gateway, aber bei der Fritzbox erwähnst du keine. Dein LAN scheint ULA, PD und DHCPv6 gleichzeitig zu nutzen, eventuell hängt das mit dem MutliWAN zusammen, aber warum dann ULA überhaupt bei einer statischen IP?

Ich bin absolut kein IPv6-Profi, von daher weiss ich nicht ob irgendwas davon hilft, aber generell würde ich mit Wireguard mal schauen was zur Hölle mit den Paketen passiert, wer und über welche IP / welches Interfaces die gehen "wollen" bei den Protokollen die rumspinnen und ob dir da eventuell ein ungewolltest NAT in die Quere kommt.

Wer stellt denn die beiden FritzBoxen, sind das deine die du konfigurieren kannst oder die vom Vermieter?

Ich würde versuchen den Edgerouter durch OPNsense zu ersetzen, dort Multi-WAN einzurichten, die Fritten auf Bridge umzustellen und dann LAN/VLANs durch das eine Kabel zu leiten, direkt in den Switch.

Was ist denn der Grund warum du noch einen Edgerouter vor OPNsense einsetzen willst/musst?

Nur eine Idee, hast du in der ACME-Plugin Automation Regeln hinterlegt OPNsense und NGINX nach einem Zertifikatswechsel neu zu starten? NGINX tauscht Zertifikate nicht einfach im laufenden Betrieb aus.