Messages

Maybe, the same issue like this one (Link).

The next days I'll prepare for migration to 23.1. Is the old legacy client still supported or the new one stable enough?

I have not migrated yet. But, two separate entries for the same host name should do the job (similar to the legacy DDNS).

The scenario I have outlined is a compromise of the server, either through an RCE or another possibility with the introduction of malware (e.g. compromised update server for distributing software updates).

The first steps look promising, even if the recursion regarding DNS queries is not yet running smoothly.

However, I found some bugs in the plugin.

• Disabled or removed master zones leave orphaned zone files in the file system
• Disabling entries (records) in master zones is without function

Thanks, I'll try that.

Of course one should be concerned if the server experiences an RCE. It's a second line of defense and should prevent exfiltration of data to a malicious remote endpoint in the internet. Maybe IDS/IPS is the better solution. In fact, I haven't checked out Suricata and its properties as a possible solution yet.

Does nobody has an idea or dealt with DNS tunneling?

To prevent data exfiltration from the server network in case of possible compromise I'd like to prevent DNS tunneling for this network. Actually, I use "unbound DNS" as a local resolver. Compared to the local networks the server network only needs a handful of hostnames to resolve.

As far as I know Unbound does not support black/whitelisting on an interface basis. So, I plan to use "Bind" as a filtering DNS forwarder in front of Unbound to filter DNS requests of the server network. Perhaps, Bind can completely replace unbound in the future. But at first, I don't want to replace Unbound.

Before starting, I like to get your ideas for preventing DNS tunneling. Thanks.

Just installed the Intel x540-t2. Exact same issue.

@eneerge: Have you also tested the performance and possible impact when stopping the services "samplicate" and "strongswan" on the Dashboard?

Why is your OPNsense involved in LAN to LAN traffic? Do you use a LAN bridge instead of a switch? You should definitely get a dedicated switch, then.

Please don't be confused by the term "LAN", I use this in a broader sense (everything behind the firewall compared to WAN). Server and client are both in different LAN segments (VLANs) whereas the Opnsense routes the traffic between them based on pf rules. Additionally, the VLANs are on different physical interfaces, so no sharing of bandwidth is involved.

https://forum.opnsense.org/index.php?topic=31753.msg153441#msg153441

960Mbit upload ...

Testing the throughput in the WAN compared to the LAN can have much more issues which lead to a degraded performance. So, I recommend to start testing the performance in the LAN. I don't want to hijack this thread with my observed problems. But maybe they are related. Regarding my previous post (#15) I did some tests again:

Scenario: Server <-> Opnsense <-> Client:

• Client downloaded a 10GB file from the server via SMB in the LAN
• All LAN links are 1GB/s
• Server CPU load was around 10-15% (all cases)
• Client CPU load was around 10-15% (all cases)
• Opnsense CPU load was around 25% (all cases)

• Result (regular configuration): Download speed was around 40MB/s
• Result (regular configuration and service "samplicate" stopped): Download speed was around 60MB/s
• Result (regular configuration and services "samplicate", "stgrongswan" stopped): Download speed was around 90MB/s

Disabling these both services increases the performance in the LAN a lot. But for me it is not an option to drop IPsec. Unfortunately, this situation of slow data throughput has existed for a very long time with no prospect of improvement.

Edit:
Playing with some tunables from here (#15) increases the performance for the third case from around 90MB/s to 100-105MB/s.

I can imagine. Opnsense has several performance issues. Regarding my Opnsense, routing traffic between different LAN segments (1 GBit/s each) is slow and drops to 40-60 MB/s (especially SMB transfers).

I can't exactly remember anymore. But, if I am right the issues began with version 18.x or 19.x, maybe while migrating to "iflib". The issues are still not solved and I started coming to terms with it. I don't know whether these performance issues are directly related to Opnsense or are the same in PFsense or vanilla BSD.

I noticed that performance increases when disabling IPsec (even if its not related to the routing between the above mentioned networks). Furthermore, "netflow" has a non-negligible negative impact on performance.

See also:

• https://forum.opnsense.org/index.php?topic=19426
• https://forum.opnsense.org/index.php?topic=18754.0

Edit: My Opnsense runs on bare metal (Supermicro A2SDi-4C-HLN4F)

Dein Setup enthält ziemlich viele Regeln, meines habe ich etwas einfacher gehalten:

• NAT Outbound: Wozu dient die 2. WAN-Regel?
• Rules LAN: Wozu dienen die Regeln 3+4 (Sipproxd). Diese werden von Regel 1 überschrieben, falls die Fritzbox im ,,LAN net" liegt.

Ich sehe anhand der Regelbeschreibung, dass Du den Siproxd einsetzt. Benötigst Du diesen wirklich (bei einem SIP-Gerät nicht zwingend erforderlich)?

Eventuell liegt es daran, dass sich aufgrund von NAT der Quellport ändert. Über Details kann ein Paketmitschnitt Aufschluss geben. Ich empfehle, für SIP/RTP/RCTP die Option ,,Static Port" zu aktivieren (Firewall -> NAT -> Outbound).

Ansonsten schreibe hier bitte mal das gesamte Voip-Regelwerk für die Fritzbox hinter der Opnsense rein (Firewall-Regeln, Outbound NAT, Portweiterleitung).

Tritt das Problem nur bei ausgehenden Gesprächen auf?

Opnsense uses mpd5 for years. So, don't worry about CPU load

I did some more tests. And as already mentioned using ECDH with group 31 as key exchange mechanism can be treated as a partial workaround compared to DH with modp8192 in combination with OpenSSL 1.x flavor. So far it looks good.