Messages

1

General Discussion / Re: Firewall pass rules don't work

« on: March 26, 2023, 05:30:23 pm »

Yes, I found that also to be true: OpnSense firewall rules are essentially worthless because they do not work at all!



No, seriously, you essentially give no information:

1. You do not show your rules, if they are inbound or outbound, what order and whatnot.
2. You do not specify any networks or interfaces or from what client you try to reach what.
3. I can only assume that 100.100.100.100 is a stand-in for a real address - as such, it is a bogon address which may get filtered by a checkbox ("Block bogon networks") in the interface section.

2

Hardware and Performance / Re: Simple L3 traffic flood leads to CPU denial of service

« on: March 25, 2023, 02:45:02 pm »

I can only say:

1. I think that any remote ISP I can try to send to my OpnSense box prevents source spoofing, so that I cannot really test this remotely.

2. When I test this locally from a Linux client on my LAN connected over 10 Gbps, I can see a clear difference between syncookie protection on and off. With syncookie protection on, state table does not fill up and CPU load rises to about 50%. With syncookie protection off, state table usage ramps up as does CPU load (100%). I have seen kernel traps in this situation - currently, I cannot reproduce it, probably because I limit the target to the local LAN interface. Probably, this would change if I targeted some outside address, but I fear to down my outside line again.

3

Hardware and Performance / Re: Simple L3 traffic flood leads to CPU denial of service

« on: March 25, 2023, 12:02:50 pm »

Syncookies ARE related because you request a TCP SYN attack via -S. This essentially simulates a DOS attack, not from different IPs, but that does not matter.

The difference with the setting is if there will be further processing of these packets or not - you can see this in the rising number of state table entries if syncookie protection is disabled. At least I can see relevant CPU load and rising number of state table entries only if I use the default setting of "disable".

This is to be expected if a large number of packets must be processed. In this case, each packet has a length of 64 bytes, such that even with onlöy 30 Mbit/s, there will be 60000 packets per second in your case. I tested it over a 10 Gbps local connection, this gives you up to 19 million packets per second.

So, essentially, high CPU load and state table exhaustion is exactly what syncookie protection should prevent. I do not know if your hardware is so weak that it suffers from high load even if syncookie protection is on.



However: What I did not expect is a kernel fault and even with that, it should give a reboot, which it does not - and I call that a catastrophic failure, which is way worse than what you intially asked for.

I have original Deciso hardware, so this should not happen. I have checked againt a VM under proxmox, that one does not show this behaviour. Thus, I am unsure if this is a driver issue for the ax driver or related to other recent reports of kernel faults. I will fire up another hardware-based instance with different NICs to check if this happens only on ax hardware.

4

General Discussion / Re: IPv6 and the new ddclient

« on: March 25, 2023, 12:28:03 am »

As far as I know, ddclient is only able to do one of either IPv4 or IPv6 at a time. You could use two entries to do both separately if the DynDNS provider supports that (probably by using another endpoint name for IPv6 plus autodetecting the sending IP and thus updating the same entry for IPv4 and IPv6 accordingly).

Also, in order to use IPv6 at all, you have to use the "general" tab, advanced mode, enable IPv6.

For Strato, the resulting entry is just:

Code: [Select]

use=if, if=pppoe0, \
protocol=dyndns2, \
server=dyndns.strato.com, \
login=user, \
password=pass \
xyz.strato.com

I do not see real Strato support in ddclient because they expect to have both IPs updated in one request via parameters.

5

Hardware and Performance / Re: Simple L3 traffic flood leads to CPU denial of service

« on: March 24, 2023, 06:49:28 pm »

Difficult to say what you missed, and you did not specify what you did. For example: Did you use Firewall->Settings->Advanced->Enable syncookies?

There was no impact when I tried that from external to my box, but I am unsure if that traffic is filtered somewhere on the way.

P.S.: Attention viewers: Do NOT try this from home:
When I did this from my LAN to the OpnSense interface without syncookie protection, my boxes hung up completely with no automatic reboot.

On my DEC 750, I saw this endless loop:

Code: [Select]

Tracing command kernel pid 0 tid 100033 td 0xfffffe001e7b6ac0
sched_switch() at sched_switch+0x6f9/frame 0xfffffe001b7bae20
mi_switch() at mi_switch+0xc2/frame 0xfffffe001b7bae40
_sleep() at _sleep+0x1fc/frame 0xfffffe001b7baec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xb1/frame 0xfffffe001b7baef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe001b7baf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001b7baf30
--- trap 0x82c16fe0, rip = 0xffffffff80c30e8f, rsp = 0, rbp = 0x3000000020 ---
mi_startup() at mi_startup+0xdf/frame 0x3000000020

Tracing command kernel pid 0 tid 100034 td 0xfffffe001e7b63a0
sched_switch() at sched_switch+0x6f9/frame 0xfffffe001b7b5e20
mi_switch() at mi_switch+0xc2/frame 0xfffffe001b7b5e40
_sleep() at _sleep+0x1fc/frame 0xfffffe001b7b5ec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xb1/frame 0xfffffe001b7b5ef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe001b7b5f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001b7b5f30
--- trap 0x82c16fe0, rip = 0xffffffff80c30e8f, rsp = 0, rbp = 0xffffffff82c16fc0 ---
mi_startup() at mi_startup+0xdf/frame 0xffffffff82c16fc0
kernload() at 0xb7b49003/frame 0xfffffe0000000100

Tracing command kernel pid 0 tid 100036 td 0xfffffe001e7b5560
sched_switch() at sched_switch+0x6f9/frame 0xfffffe001b7abe20
mi_switch() at mi_switch+0xc2/frame 0xfffffe001b7abe40
_sleep() at _sleep+0x1fc/frame 0xfffffe001b7abec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xb1/frame 0xfffffe001b7abef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe001b7abf30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001b7abf30
--- trap 0x82c16fe0, rip = 0xffffffff80c30e8f, rsp = 0, rbp = 0xffffffff82c16fc0 ---
mi_startup() at mi_startup+0xdf/frame 0xffffffff82c16fc0
kernload() at 0xb7b49003/frame 0xfffffe0000000100


6

23.1 Production Series / Re: NAT issue with VoIP/SIP/RTP

« on: March 22, 2023, 10:27:49 pm »

Try enabling the outbound NAT rule 'static-port' setting. Also, the voice RTP port range seems excessively large to me. Are you sure these are correct?

And should the NAT address of the outbound NAT rule not match the pub.pub.pub.181 address that is in the incoming rules? Or the other way around, if pub.pub.pub.178 is your VIP.

7

23.1 Production Series / Re: Intel X550-T2 problem with 2.5 Gbps link speed

« on: March 22, 2023, 10:18:33 pm »

In an ideal world, it should be selectable in the interface section, but I do not know for sure, since I do not have that type of adapter running in OpnSense.

8

German - Deutsch / Re: VDSL Modem Zugriff

« on: March 22, 2023, 11:14:54 am »

Du könntest theoretisch eine Firewall-Regel einrichten, die den Zugriff vom LAN aus erlaubt. Höchstwahrscheinlich ist das bereits durch eine "allow any" vom LAN aus erledigt.

Aber typischerweise ist es so, dass solche Modems oder ONTs statisch konfiguriert sind mit einer Default-IP, aber keine Route gesetzt haben. Damit sind sie nur aus der selben Collision Domain erreichbar, deswegen klappt es von der OpnSense aus, aber nicht aus gerouteten Netzen.

Der übliche Trick, um das Problem zu lösen, ist eine Regel für Outgoing NAT vom LAN aus einzurichten, die den Zugriff auf 192.168.16.0/24 ermöglicht. Dabei wird dann als Absendeadresse die Interface-Adresse der OpnSense genommen.

9

23.1 Production Series / Re: Intel X550-T2 problem with 2.5 Gbps link speed

« on: March 22, 2023, 09:14:56 am »

I found this to happen under Linux and Windows, too. For some reason, the advertised speeds are 100, 1000 and 10000 for those Intel adapters, whereas the supported speeds are 2500 and 5000 as well. The Intel reference documentation even states that autonegotiation is not supported for 2500 Gbps.

Under Linux, this looks like so if the other side can only do 100,1000 and 2500:

Code: [Select]

# ethtool eth4
Settings for eth4:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

Since the latter two modes are not advertised, they will not get negotiated, but must be set explicitely. After setting 2500, ethtool says:

Code: [Select]

# ethtool eth4
Settings for eth4:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
                                2500baseT/Full
                                5000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

I do not know if pfSense does something special in their driver to advertise more modes or if they just try different modes from highest to lowest until they succeed, however, that is not standard behaviour for this hardware. I have read something to the extent that 2500 Gbps is not stable depending on the link partner.

I do not have this NIC under OpnSense, but you can probably manually set 2500 Gbps as well.

10

German - Deutsch / Re: Empfehlung Hardware

« on: March 21, 2023, 11:42:40 pm »

Was ich da nicht ganz kapiere: Du hast das GästeWLAN zweimal eingezeichnet.

Läuft die Fritzbox als IP-Client oder als Router mit eigener NAT?

Wenn sie als IP-Client läuft, arbeitet sie als normaler Access Point und das GästeWLAN ist nicht abgetrennt (also alles im "grünen" Netz). Das wäre dann konsistent zum zweiten GästeWLAN rechts, ich nehme an, da steht mindestens noch ein weiterer AP.

Als Router könnte sie zwar das GästeWLAN abtrennen, aber das normale WLAN wäre so auch nicht wirklich im "grünen" Netz.

Wenn man ein Gast-(W)LAN wirklich abtrennen will und mehrere APs braucht, ist die Fritzbox IMHO nicht die ideale Lösung. Ich verwende die FB nur noch als VoIP-Gateway und nutze VLANs und Access Points von Unifi, die dann die WLANs separieren.

11

23.1 Production Series / Re: Upgrade from 23.1->23.1.3 kernel panic/crashing

« on: March 21, 2023, 10:08:55 am »

What is a connection drop on one OS may as well manifest as a kernel crash on another, just saying.

However, there are few reports of kernel crashes just because of using PPPoE. I have three OpnSense 23.1.3 installations running over it and had no problems at all.

I wonder if other reports share a common factor in hardware where it is more likely to have crashes than with a user-level process like mpd5. For now, information about probable causes in this thread is scarce (e.g. "those mini PC firewalls off of Amazon" use either I210, I211, I225 or I226 or even Realtek) and only shows common symptoms (i.e. kernel crashes).

12

23.1 Production Series / Re: Upgrade from 23.1->23.1.3 kernel panic/crashing

« on: March 21, 2023, 08:11:52 am »

What is your common factor? I226-V as NIC? This does not apply for the APU2C4, so: PPPoE on WAN?

The I226-V FreeBSD drivers are fairly fresh, pfSense does not even support those yet.

And after several I225 generations ridden with problems, there is plenty of indication on several other platforms (Windows, Linux) right now that I226-V might be just as unstable hardware-wise, just google for "I226-V connection drop".

13

German - Deutsch / Re: IPv6 erklärt (für nicht netzwerker)

« on: March 20, 2023, 09:35:12 pm »

Nur ein paar wichtige Pointer, explizit keine Schritt-für-Schritt-Anleitung (Google ist Dein Freund):

Das hängt bei IPv4 von der Richtung des Traffics ab. Mit DS-Lite kannst Du ja ganz normal aus Deinem (IPv4-)LAN heraus auf alles mit IPv4 im Internet zugreifen. Die LAN-IPs werden dabei über eine doppelte NAT (LAN -> ISP-CG-Netz -> Internet) auf eine routebare IP abgebildet.

Umgekehrt geht das nicht, weil Du auf der äußeren NAT-Grenze keine Portfreigaben einstellen kannst - das lässt der ISP nicht zu.

Insofern ist weder Deine OpnSense noch ein Gerät dahinter vom Internet aus per IPv4 "erreichbar" (= es kann von außen keine Verbindung initiiert werden, Antworten kommen schon durch). Nun ist auch klar, dass DynDNS per IPv4 bei DS-Lite keinen Sinn ergibt, weil man ja höchstens eine Public-IP des Providers auflösen könnte, die man sich mit vielen anderen Anschlüssen teilt und auf der kein Port geöffnet ist.

Was IPv6 angeht, gibt es eigentlich keinen Unterschied zwischen DS und DS-Lite: Du erhältst einen IPv6-Range, den Du segmentieren und intern im LAN verteilen kannst (per DHCPv6 oder SLAAC). Deine IPv6-fähigen Clients können dann ins Internet zugreifen, werden aber nicht geNATet, sondern zeigen ihre "echte" routebare IPv6 (entweder die EUI-64 oder wenn unterstützt, eine Privacy-Extension-IPv6) - immer vorausgesetzt, dass die Firewall das zulässt.

Von außen nach innen hat man normalerweise eine Regel, die Zugriffe verhindert, es ist aber möglich, einzelne Geräte und Ports zuzulassen. Problem ist dabei, dass die oberen 56 Bits der IPv6 variabel sind, deshalb muss man bei den Firewall-Regeln "Dynamische IPv6"-Aliase verwenden - das geht natürlich normalerweise nur mit dem EUI-64-Suffix des Geräts.

Nun wird es interessant, weil jedes "erreichbare Gerät" seinen eigenen EUI-64-Suffix hat, was bedeutet, dass eben nicht alle Geräte unter dem selben DNS-Namen adressierbar sind. Also sollte die OpnSense einen IPv6-fähigen DynDNS-Dienst nutzen, bei dem man mehrere DNS-Namen (bzw. Hostnamen unter der selben (Sub-)Domain) auf einmal aktualisieren kann und bei denen die niederwertigen EUI-64-Bits inklusive Segment-Präfix jeweils fest vorgegeben werden können - das sind dann die verschiedenen Clients.

Alternativen dazu sind HAProxy (https://forum.opnsense.org/index.php?topic=23339.0) für namensbasierte Auflösung von HTTP-Endpunkten im LAN, wo dann alle Hostnamen auf den selben Alias (nämlich die OpnSense selbst) verweisen und nur aufgrund des Namens verzweigt wird oder aber:

IPv6-Port-Forwards mit dem Ziel "This Firewall" auf den jeweiligen IPv6-Client (auch dort per Firewall-Alias, da es ja immer noch IPv6-Traffic ist).

All das löst aber noch nicht das Problem, dass man per IPv4 "von außen" NICHT erreichbar ist. Wenn man nämlich irgendwo keine IPv6-Unterstützung hat (manche Mobilfunknetze, viele Hotel-, Privat- und Firmen-WLANs), geht das alles eben nicht mit DS-Lite.

Dann braucht man Tunnel-Lösungen wie Cloudflare oder Dual-DNS mit einem virtuellen Server im Internet, der einzelne Ports von IPv4 auf IPv6 umleiten kann.

Alles sehr spaßig und zeitraubend und wenn Du damit fertig bist, bist Du ein Netzwerker.

14

23.1 Production Series / Re: WireGuard speed

« on: March 20, 2023, 10:13:32 am »

I get about 20 MByte/s and I have clamped MSS at 1360 for the Wireguard Group under Firewall->Settings-> Normalization, as this prevents other problems as well (see https://forum.opnsense.org/index.php?topic=23339.msg160282#msg160282)

For reference: I have PPPoE over 802.1q running for the WAN connection, so these add to the Wireguard overhead that is added to the packets and must fit into an ethernet frame which is limited to 1500 bytes.

15

23.1 Production Series / Re: Cron jobs not running on schedule

« on: March 20, 2023, 10:02:00 am »

I am quite sure that you misinterpret that information. I have entries in there that concern "alias", but not the ones that are caused by that cron line. configctl only triggers actions in configd.

Generally speaking, the log output of such events may be split up to different log sections via syslog.

I do see log entries on my Graylog instance every minute like so:

Code: [Select]

2023-03-20 09:54:00.000 OPNsense.mgsoft
OPNsense.mgsoft /usr/sbin/cron[22546]: (nobody) CMD (/usr/local/sbin/configctl -d filter refresh_aliases)

This is log level 6, facility "clock":

Code: [Select]

{
  "gl2_accounted_message_size": 236,
  "level": 6,
  "gl2_remote_ip": "192.168.1.2",
  "gl2_remote_port": 26953,
  "streams": [
    "000000000000000000000001"
  ],
  "gl2_message_id": "01GVZ3KD27JWW7KNSG402PYWGJ",
  "source": "OPNsense.mgsoft",
  "message": "OPNsense.mgsoft /usr/sbin/cron[22546]: (nobody) CMD (/usr/local/sbin/configctl -d filter refresh_aliases)",
  "gl2_source_input": "616dd51a51faec33cacc467a",
  "facility_num": 9,
  "gl2_source_node": "817eaa81-ad8f-46fd-9e6b-ebcb2587dd1d",
  "_id": "c1935573-c6fc-11ed-9893-5254005211e2",
  "facility": "clock",
  "timestamp": "2023-03-20T08:54:00.000Z"
}

What you refer to is /var/log/firewall/*, I have very few entries there at all. So maybe what you are seeing is something different. What happens when you disable the cron line? Does anything change or do the events still occur every 6 minutes? Or try using */30 - do the events occur less often?

Oh, and about email: Obviously, the standard configuration does no email at all.