Messages

If it works as expected without powerd then my personal solution is "don't run it, then". I mean, the APU series of devices are such low power platforms anyway, there's probably not much to gain.

[after]

I think the documentation explains the processing order quite well:
https://wiki.opnsense.org/manual/firewall.html#processing-order

Automatic rules come first, so they are set to "slow". This means that a later rule provided by you can override them. Whether you set your own to slow or quick depends on if you want additional rules to be checked after this particular one or not.

Slow and quick are not separate rule sets. They are an attribute of the single rule in question. Quick means "if match, terminate rule processing immediately and use this one". Slow means "remember that rule, but examine all following ones if they match, too".

So the rule processing will alway use

• the first quick rule that matches
• only if there is no matching quick rule, then the last slow rule that matches
• only if there is no matching rule at all it's "default deny"

Nope  ;)

Code Select Expand


root@opnsense:/var/log # uptime
5:17PM  up 5 days,  1:37, 1 user, load averages: 0.50, 0.43, 0.38
root@opnsense:/var/log # dmesg | grep 'link state'
root@opnsense:/var/log # grep 'link state' *


I used to have minor problems with 20.7. Initially I bridged all 4 interfaces of my apu4 to use the device as a small home switch - which JeGr despises but I find perfectly reasonable. Sometimes after config changes I would lose connectivity to my desk where my Mac is connected via a Thunderbolt docking station with Ethernet and only a reboot of OPNsense would bring it back.

Since I bought a Cisco 2960-L 16-port switch and connected all servers (2x TrueNAS, 1x OPNsense) to that via LACP and then access ports to other systems in the apartment I have not had any problems.

So I *guess* the device on the other end can play a role, too.

If a quick rule matches, processing of rules is stopped and the rule is applied to the packet in question.
For slow rules the last rules that matches the packet is applied.

So "quick" is the way packet filtering firewalls traditionally work. Apply rules in order, first match wins, stop rule processing for that packet.

I am running an apu4d4 with the 211 chipset and don't experience any issues.

2 of the 4 interfaces are combined in a lagg, plugged into a Cisco switch with LACP, on top of that I run 2 VLANs for LAN and OPT1. The system does not have a WAN interface.

Sorry, sort of - just humming along.

Das würde ja heißen, sobald ein Interface flappt, für die auch eine statische Route hinterlegt ist, würde er diese löschen und sobald das Interface wieder vorhanden ist, die statische Route ja dann nicht mehr haben. Das kann ich nicht ganz glauben, um ehrlich zu sein, wieso sollte das so sein?

Nein, nein. Nur wenn die lokale IP-Adresse komplett verschwindet. Also z.B. bei einem Tunnel, bei dem die "innere" IP-Adresse für die Route genutzt wird. Und auch nur dann, wenn das Interface entfernt und neu angelegt wird, nicht, wenn es flappt.

Ich benutze keine routenbasierten Tunnel, deshalb weiß ich nicht, was die Sense da macht ...

Sollte das Interface, über das der Gateway für diese Router erreicht wird, komplett verschwinden, ist auch die Route bei einem FreeBSD weg. Wie es mit Interface down/up ist, weiß ich grad nicht, müsste ich ausprobieren.

Aber Routen über nicht erreichbare Gateways kann man nicht eintragen und wenn ich mich jetzt nicht ganz arg irre, werden die auch entfernt, wenn das lokale Netz verschwindet.

Geht vielleicht das Interface, über das dire Route führt, down und wieder up?

Was wolltest Du denn sagen? Korrigier den Beitrag doch bitte. der Satz ist komplett unverständlich ...

[os-api-backup]

Du kannst auch das Plugin os-api-backup benutzen.

Z.B. mit einem Shellscript in dieser Art:

Code Select Expand


#! /bin/sh

#
# Configure list of systems and matching parameters.
#
systems="pmh"

pmh_host="opnsense.********"
pmh_key="**************"
pmh_secret="**************"
pmh_file="pmh.xml"

#
# No user servicable parts below.
#
directory="opnsense"
mkdir -p "${directory}" || exit 1

for system in ${systems}
do
eval host="\$${system}_host"
eval key="\$${system}_key"
eval secret="\$${system}_secret"
eval file="\$${system}_file"

curl -s -k -u "${key}:${secret}" "https://${host}/api/backup/backup/download" -o "${directory}/${file}"
done


Das benutze ich innerhalb eines mit git verwalteten Projekts. Also Config damit von der OPNSense holen, dann in git einchecken. Achtung! Da sind dann auch alle Passwörter und VPN-Keys, Zertifikate mit private Keys etc. pp. drin. Also nicht in ein öffentliches Repo auf Github schieben  ;)

Yes, with a web proxy that understands SNI for HTTPS. The HAproxy plugin for example fits the bill.

Hi all,

I have two VLANs on my OPNsense and no WAN connection. The system is more of a VPN gateway, DNS server etc. than a firewall.

Code Select Expand


Internet/Fritzbox
192.168.1.1
      |
      |
     LAN                                     OPT1
192.168.1.4/24 ------- OPNsense ------- 217.29.46.41/29 ------- IPsec tunnel ------- TrueNAS 217.29.44.24
      |
  Graphite
192.168.1.55


The network 192.168.1.0/24 does not know about the other network. If anything from the local network 217.29.46.40/29 needs to access the Internet or anything in the RFC 1918 LAN, the connections are NATed.

Outbound, LAN, Interface address - easy.

The single system in the remote network on the other end of that tunnel - which does not know/route the 192.168.1.0/24 - is supposed to send Graphite data on port 2003. At the moment I have set up HAproxy for that.

Listen on 217.29.46.41:2003 - forward to 192.168.1.55:2003. Works. The Graphite server sees the connection coming from 192.168.1.4, of course.

So ... what's the problem?

How can I build the same with NAT instead of HAproxy? When I configure a port forward on OPT1/217.29.46.41 for port 2003, the initial SYN goes to 192.168.1.55 alright - but with a source address of 217.29.44.24. And the Graphite server does not know that network.

Is there a way to port forward and at the same time NAT the connection on the LAN interface so the Graphite server only sees 192.168.1.4 like with a proper proxy?

Thanks,
Patrick

The procedure will re-mirror the entire content of ada0 onto ada1. Including the boot manager etc. That's why I said it's good OPNsense mirrors the entire disk.

There are other possible setups since GEOMs are stackable. So you could theoretically mirror individual partitions. But that's not the case here. Just go ahead.  ;)

So they are mirroring the whole disk. That makes replacement pretty easy.
Assuming the disk to be replaced is ada1 ...

gmirror remove OPNsense ada1

shutdown system, replace disk, boot again, assuming the new disk is ada1 again

gmirror insert OPNsense ada1


Depending on your system it might be necessary to enforce the new disk is ada1 by switching the cabling if necessary. Possibly the system won't boot if ada0 does not present a proper MBR or UEFI boot environment. So if the disk to be replaced is ada0 you might have to adapt a bit.

Radia Perlman, "Interconnections: Bridges, Routers, Switches, and Internetworking Protocols".