Messages

I still need to manually update the standard source code of if_em.c driver (e1000) to add my WOL enhancements to it.

As I now also need the RSS feature, I recognized, that my modified drivers are not fully working correct anymore. Therefore I verified my compiled code with the one of the OPNsense package. And they differ without any change in the source code.

Following differences I detected:

• RSS flag is not set in manual compilation; missing reference to methods rss_get_indirection_to_bucket and rss_getkey
• Instead of method sx_xlock_hard the method sx_xlock is referenced
• Reference tp method lockstat_enabled is not compiled

Adding #define RSS 1 and #define LOCK_DEBUG 0 solved the first two items. How to solve item #3 and is there an easier way to get the same result just using some compile options?

Thanks,
Michael ...

Check my solution for this topic. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238411

From my perspective it's not an OPNsense issue, it's a FreeBSD issue (I call it bug). With my own adapted & compiled network driver WOL is working like a charm.

kr/m

I use IP-Tables using Alias -> External (advanced). The tables you can specifiy in your firewall rules and via bash-scripts or PHP you can add, remove resp. restore after boot entries in these IP tables using commands like

Code Select Expand

/sbin/pfctl -t ex_accessible_destination_IPs -T add 0.0.0.0/0 2>&1
/sbin/pfctl -t ex_accessible_destination_IPs -T remove 0.0.0.0/0 2>&1

No need to update any firewall rule. Immediately after you changed the IP-Table it's valid.

I use it to lock access for all clients or sometimes only for specific IP's. Consider to negate rules as an option.

Maybe it helps!

Hi!

I have a similar setup as you and from my tests I did, I would say it's working; I don't need to double the rules (what in my sense makes also no sense, as one data packet can/should only be counted once!).

The only difference I have: in the queues I have specified mask "destination" for download queues and "source" for upload queues. When two clients are downloading the get a 50:50 share and the pipe's limit is not exceeded.

Would be interested about your test results.

Anbei ein einfache Darstellung meines Testaufbaus an dem ich mich hocharbeite und alle Teile einzeln durchteste, bevor ich den ganzen Haushalt inkl. VLAN's umstelle.

              +------------------------------------+
              -                                    -
DSL-Modem ----- 10.0.0.26            192.168.1.21  ------- LAN 1 (VLAN 1,5,8) ----- Switch --- Client VLAN-1 (192.168.1.10)
10.0.0.20     -              OPN     192.168.5.21  -                                            - Gateway 192.168.1.21
              -                      192.168.8.21  -                                            - DNS 192.168.1.21
              -                                    -
              --------------------------------------


Im Grunde bietet mir der Web Proxy zwei interessante Features, die ich gerne genutzt hätte; alle anderen Funktionalitäten sind aktuell nicht notwendig für mich:

• Logging der aufgerufenen URL's bei HTTP und HTTPS
• Einfaches blacklisten von URL's

Den Traffic-Shaper will ich für drei Funktionalitäten verwenden:

• eine bestimmte Bandbreite im u/l und d/l Traffic wie z.B. ICMP-Verkehr und bestimmten Datenverkehr fix reservieren
• die restliche Bandbreite im u/l und d/l fair auf alle Clients verteilen
• anhand der ipfw Statistik könnte ich je Client (= Destination bzw. Source) eine Regel im Traffic-Shaper bauen, anhand der mir die verbrauchten Pakete und Datenbytes mit protokolliert werden; diese würde ich in einem regelmäßigen Intervall per Skript auslesen und könnte so eine Statistik über den Datenverkehr je Client auf Stunden, Tages und Monatsebene erstellen (habe dazu leider kein Plugin gefunden, der das einfach aktuell anbietet); nur das alte bandwidthd, das nicht mit VLAN umgehen kann

Wenn ich den transparenten Proxy mit SNI und den Traffic Shaper nicht gemeinsam zum Laufen bekomme, werde ich wohl auf den WebProxy verzichten müssen.

Und ja, ich habe im Forum gesucht. Es gibt auch Beiträge zu dem Thema - aber keine Lösung oder Alternative.

Als Workaround fiel mir eben die Variante nun ein, tlw. die LAN-Seite für das Datenvolumen heranzuziehen (weil nur dieser die Client-IP beim Proxy-Verkehr kennt, welchen ich brauche, um den Datenverkehr fair auf die Clients aufzuteilen). Wie schon im ersten Beitrag geschrieben klappt das auch bei der d/l Seite. Nur um u/l finde ich das Paket nicht im Traffic Shaper. Aber klar, das ist nur ein "grauslicher" Workaround.

LG,
Michael ...

Hallo,

ich versuche den Traffic-Shaper mit dem transparenten Web-Proxy auf einer OPNsense Box gleichzeitig zu betreiben. Schließen sich diese beide Funktionalitäten aus oder gibt es eine Workaround?

Ich habe versucht, statt alle Traffic Shaper Rules auf das WAN Interface zu legen, es aus einem Mix mit WAN und LAN zu machen. Das klappt auf der Download-Seite eigentlich recht gut, weil ich hier bei "LAN out" in den Shaper-Rules auf die Zielports 3128/ 3129 und Ziel-IP filtern kann. Ist sicher kein perfekter Workaround, kommt aber der Realität schon recht nahe.

Aber auf der Upload-Seite schaffe ich es einfach nicht die Pakete zu selektieren, die von den Clients über den LAN-Port zur OPNSense gehen und via NAT Port Forward an den transparenten Proxy geleitet werden. Egal ob ich Port 443, 3129 oder any nehme, sie tauchen im Traffic Shaper nicht auf.

Ich verstehe nicht, wieso man diese Pakete nicht filtern bzw. identifizieren kann.

Hat hierzu wer eine Idee?

Danke,
Michael ...