Messages

Hallo Community,

ich habe eine opnsense-Installation die als Client eine openvpn site-to-site Verbindung zu einem debian-server aufbaut. Die VPN funktioniert auch einwandfrei.
Ich würde nun gerne die Clients am LAN-Interface (re1) der opnsense per dhcp-relay mit IPs vom DHCP-Server der anderen VPN-Seite versorgen.
DHCP-Relay-Dienst ist eingerichtet.
Der DHCP-Request des Clients kommt am DHCP-Server an und dieser gibt auch einen Reply raus.
Der Reply kommt auf der opnsense auch an. Zumindest seh ich ihn im tcpdump auf dem ovpn-interface reinkommen. Leider kommt er aber nicht auf re1 (LAN-Interface) raus.
Ich habe gesehen, dass er von der Firewall auf dem "IN" vom ovpn weggeblockt wurde.
Aber auch nach Regelertellung, dass Port 67 und 68 UDP erlaubt sind (Sowohl openvpn IN und OUT als auch LAN IN und OUT), kommt der Reply nicht bis re1.

Ich finde aktuell nichts im Firewall-Log wo das Paket gedroppt wird.
Im Log vom DHCP-Relay finde ich leider gar keine nützlichen Informationen.
Ich bin gerade ziemlich ratlos wo ich als nächstes suchen soll.
Hat hier jemand noch einen Tip wo ich suchen kann, bzw. was ich falsch mache?

Viele Grüße
Uli

I had similar issues on a gigabyte GA-J3455N-D3H an solved it by disabling c-states in the cpu-settings in the bios.
After that it runs realy fast!

Greetz
Uli

Hallo Zusammen,

mein Name ist Uli und ich bin zwar recht neu in opnsense (und auch freebsd) allerdings nicht neu im Bereich der
IT-Technik, Linux, Firewalls und Vernetzung, etc.

Ich suchte für die Vernetzung meines Heimnetzwerks mit meinem Mini-Netzwerk im RZ (FW mit OpenVPN und Syno-NAS inkl. div. Diensten) neue Hardware die mehr ovpn-Performance bietet als mein derzeit genutzes System mit zwei mit openwrt geflashten Routern. Von einem Arbeitskollegen wurde mir OPNsense empfohlen und machte ab Anfang an einen sympatischen und soliden Eindruck ;)

Zum Testen habe ich mir mal zwei Mini-ITX-PCs mit GIGABYTE GA-J3455N-D3H Mainboards zusammengebaut.
Bei diesen hatte ich am Anfang ziemliche Performance-Probleme (Installation von USB-DVD auf SSD ca. 6 Std, Startzeit ca. 4 Min) bis ich festgestellt hatte, dass die C-States der CPU dafür verantwortlich waren. Nach deaktivieren der C-States im BIOS lief es auf den Systemen wie geschmiert. Startzeit des Systems nach frischer Installation ab Knopfdruck 53 Sekunden bis Login-Prompt. ovpn-durchsatz mit AES-256-CBC und SHA512 ca. 13/14 MB/s Datenübertragung im Test über einen Switch verbunden. Damit kann ich arbeiten  8)

Bei meinen weiteren Recherchen bin ich über die APU-Boards von pcengines gestolpert und habe mir auch mal 2 Stk. APU3B2 Bundles mit der 16 GB msata SSD bestellt, da die einfach so schön klein sind auch auch einen recht soliden Eindruck machen.
Die erste Installation mit 17.7.5 lief soweit erstmal durch (BIOS 4.0.7 glaube ich war original installiert). Allerdings fiel mir auf, dass der Start von der msata wesentlich länger dauerte als vom USB-Stick. Nach diversen Recherchen habe ich mal noch ein Bios-Update gemacht (sowohl mal auf die coreboot mainstream-version als auch auf die von pcengines-angepasste.)
Danach hatte ich cam-Fehler, und bei einer Neuinstallation, dass der Installationsprozess im Setup irgendwo zwischen 38 - 65 % hängen blieb, bis ich auf die Lösung aus folgendem Thread gekommen bin.

https://forum.opnsense.org/index.php?topic=6366.msg27937#msg27937

Mit den entsprechenden zeilen in der /boot/loader.conf.local läuft die Installation wieder einwandfrei durch und ich habe sauber laufende Installationen. BIOS ist aktuell auf dem apu3_v4.0.12.rom.
Allerdings habe ich immer noch die langsame Startzeit. Ein kompletter Start ab Strom rein bis zum Login-Prompt dauert etwa. 2:43 Min. Die Kernelmodule werden von der msata wesentlich langsamer geladen als vom USB-Stick (Laden der Kernel-Module vom USB-Stick ca. 13 Sek., von der SSD 1:04 Min)

Hat jemand noch Tipps für mich, was ich noch anpassen könnte oder erwarte ich einfach zu viel?  ::)
Schon mal vielen Dank für eure Mühen

Viele Grüße
Uli