Messages

I've added your suggestion to opnsense-update. It will be updated as soon as the next base/kernel update is needed. I don't think there's any need before this, right?

Ich komm hier nicht mit ohne Versionsnummern. Wir haben keinen Status Unterschied zwischen Dev und Release sowohl bei 15.7.18 als auch 15.7.19. Die Konfiguration hat sich auch nicht geändert, es ist also bis auf den Status Ausfall, denn du bei 15.7.18 gesehen hast alles konsistent solange nicht Pakete von 15.7.18 und 15.7.19 gemischt werden... Eine neue Installation von 15.7.18 und wechsel auf opnsense-devel ist nämlich nicht gut, weil dann das 15.7.18 System ein 15.7.19 Development Paket hat und das geht definitiv nicht.

Bitte also noch mal geordnet... Wo find es an und wie hast du getestet? Wie kam 15.7.18 ins Spiel zum Gegentesten?


Gruss
Franci

Moin,

Ja, das war auch unsere Vermutung. Der Code-Teil war spezifisch für die System-Konfiguration und wenn die fehlt, dann sollten noch ganz andere seltsame Dinge auftreten. Ich selbst hatte gestern auch probiert es nachzustellen, aber ohne Erfolg. Ist also gelöst? :)


Gruss
Franco

There is a bit more at the end here about magic host reboot and finding out the path and what happens with dom0 on those cases:

http://discussions.citrix.com/topic/151301-internal-error-another-frontend-device-is-already-connected-to-this-domain/

Beyond that I'm not much of help here. Sorry. We do have a few Xen users, maybe they can help still.

Muss nicht sein, opt9 ist der interface key, der bleibt, hieße aber es wurden mindestens 11 Interfaces angelegt. Schwer zu sagen ob da noch alte Interface mit falscher Konfiguration drin hängt.

Die config.xml kann heruntergeladen werden und editiert werden. Alle XML Tags von interfaces die du nicht benutzt sollte raus, genau wie IPsec Konfigurationen. Leider ist es schwierig nach der XML per Mail zu Fragen wegen IPsec Keys usw.

15.7.18 kann folgendermaßen gepatcht werden:

# cd /usr/local/opnsense/mvc/app/models/OPNsense/Core
# fetch https://raw.githubusercontent.com/opnsense/core/81f012d736ad4cf142d259715f31e6a67c467a44/src/opnsense/mvc/app/models/OPNsense/Core/ACL.php

Alternativ auch die Datei herunterladen und per sftp/ssh hochladen oder einen URL-Shortener benutzen. :)

Dazu müssen wir zuerst wissen, dass ein Neustart auch wirklich notwendig ist. Das ist besonders schwierig mit den Services, die im alten Codezustand nie neu gestartet werden. Da funktionierte *jedes* Update so: Update -> Neustart. Wöchentliche Updates machen so einen Neustart recht unangenehm, deshalb haben wir diese außer beim großen Betriebssystem-Update ausgeschalten.

Beste Praxis beim Update: Immer Rebooten, auch wenn nicht zwangsläufig möglich. Eine Überarbeitung dieser Philosophie ist erst bis 16.7 vorstellbar. Der korrekte Ansatz wäre hier auch das Basissystem in Plugins zu schnüren, die dann per Update auch genau wissen, dass sie neu gestartet werden müssen. Dazu brauchen wir auch erstmal den letzten Schub für das Plugin-System. :)

Ich hatte ein OPT9 gesehen, das hatte mich verwundert... Vielleiht habe ich mich auch getäuscht.

Intern hatten wir das noch etwas diskutiert soeben, hast du Tunnel, die im Status als nicht verbunden angezeigt werden? Auf Grund von Fehlkonfigurationen scheint Strongswan einfach zu blockieren wenn es so eine Verbindung sieht und das wirkt sich schlecht auf den Backend-Timeout aus. Wenn du Netzte hast die nicht funktionieren hilft vielleicht schon ein Deaktivieren derer.

Habe die Vermutung das liegt an den vielen IPsec Tunneln, ich seh deine Config nicht, aber es sind mehr als 2-3, richtig?

Hängt vermutlich nicht am IPsec selbst, sondern am geänderten Interface Caching Code im PHP. Kriegen wir aber wieder hin mit Ad's Hilfe. :)

Ich erinnere mich an einen Crash Report. 15.7.19 hat folgenden Fix dafür:

https://github.com/opnsense/core/commit/249c74c6d661c75e5d9c5231031cfda6d719de90

Also vorher updaten und noch einmal probieren? Falls das Problem damit nicht behoben ist haben wir zumindest die besten Voraussetzungen nun: Die Schritte zum Reproduzieren. Besten Dank. :)


Gruss
Franco

Das klingt nach einem kleinen Bug im Code. Mit welcher pfSense Version funktionierte dies?

Um welchen Port geht es denn? Und wenn es um Port 80 oder 443 geht, ist das Webinterface auf der OPNsense verschoben auf Alternativ-Ports, z.b. 8080 und 8443?

Ich verstehe die Frage noch nicht ganz. Der PC soll ein Router sein, aber wie läuft da OPNsense drauf? Nativ oder als VM?

Atheros macht dazu Probleme unter FreeBSD 10.

Have a look at this (bottom of the page):

http://wiki.xenproject.org/wiki/Xen_FAQ_Linux,_Running_on#Booting_a_guest_complains_about_trying_to_use_an_already-mounted_block_device.2C_but_it_isn.27t_mounted.3F.21

Let me know if that solves your issue. :)

Mentioning gateway monitoring has me worried, it is really not up to the task, see: https://forum.opnsense.org/index.php?topic=1359.0

GitHub is the most traceable option and has good response time, forum works too, emails if need be. I tend to create GitHub issues for forum entries and emails, but these can slip through. It's up to you really and we'll do our best. :)

In any case: providing feedback is key, doesn't matter how.

For direct reference... System: Settings: Networking:

[ x ] Disable hardware checksum offload
[ x ] Disable hardware TCP segmentation offload
[ x ] Hardware Large Receive Offloading
[ x ] Disable VLAN Hardware Filtering

Some settings may or may not have an impact, but it can't hurt to disable all of them and try where that leads you.