Messages

Good afternoon,

starting today afternoon around 18:40 UTC+2 my update script for the package mirror of Opnsense is not able anymore to sync with the main mirror.

Error message:

Code Select Expand

Aug 23 18:39:46 aigle docker[13800]: @ERROR: max connections (25) reached -- try again later
Aug 23 18:39:46 aigle docker[13800]: rsync error: error starting client-server protocol (code 5) at main.c(1657) [Receiver=3.1.3]
Aug 23 18:39:46 aigle systemd[1]: mirror.service: Main process exited, code=exited, status=5/NOTINSTALLED
Aug 23 18:39:46 aigle systemd[1]: mirror.service: Failed with result 'exit-code'.

It seems that the main server is somehow overloaded with connections or an another mirror is spawning to many connections.
Can someone of the Core team have a look to that?

Thanks,

Alex


PS. Sorry to spam the forum with that "internal" stuff of Mirror business...

Hallo,

ich wieder mal mit lustigen VPN Problemen ;)

Ich hab mich gerade ein wenig mit der DNS Auslösung über einen OpenVPN Tunnel gespielt und bin da über was drüber gefallen, was mir wenigstens etwas komisch vorkommt:
Wenn ich die Interfaces der OpenVPN Server als Listen-Interfaces des Unbound hinterlege, verwendet er nicht die Netze des VPN Servers in der Access-List, sondern nur das Interface (siehe Bild).

Quiz-Frage: ist das so gewollt oder sollte hier nicht das Netz verwendet werden (wie bei LAN)?

VG,

Alex

Hallo zusammen,

mit komme mit guten Nachrichten zurück aus dem Wochenende: ES GEHT!
Ich hab mich heute morgen ein wenig gespielt und bin über die Standard-Firewall Rule, die jeden Ausgehenden Internet Traffic rauslässt, gefallen.
Und siehe da: da ist der Fehler mit drin...

Ich hatte vor einiger Zeit (so ca. nen Jahr her) eine Gateway-Gruppe zwischen unserer Standleitung und einer ADSL-Anbindung aufgebaut und dort als GW eingetragen.
Das übergeht aber die System-Routing-Tabelle und ergo ist der Traffic für den VPN Traffic über die GW Gruppe geschickt worden.

Kaum war dort wieder das GW auf "default" eingetragen, geht die VPN Verbindung wie sie soll :-D

@Jörg: Vielen Dank für deine tolle Hilfe. Wenn du Hilfe bei dem HowTo brauchst, sag bescheid ;-)

VG;

Alex

Wenns bis zum Wochenende Zeit hat, dann kann ich Dir berichten. Die Umstellung von IPFire auf OPNSense und die Ablösung der eigenen VPN Instanz mit Strongswan bei AWS ist bei mir am Samstag

Mal schauen wer schneller ist ;)
Aktuell sind wir überlegen, den Opnsense Business Support zu buchen; vielleicht kommen wir dann der Lösung näher...

Dann editiere die Route und trage das Gateway ein. Es fängt mit vgw-xxxxxx an

Naja, auf AWS Seite ist alles eingetragen, und auch die Opnsense hab ich dazu gezwungen, jetzt die IP des VPN Endpoints zu verwenden.
Ergebnis: geht nicht.

Interressant ist auch, dass er mit eingetragener Route auf der Opnsense den Traffic in Richtung Standleitung (also Standard-GW) schickt, da ich von dem Gateway der Standleitung den Fehler bekomme, er kennt das Zielnetz nicht.

Aus meiner Sicht liegt der Fehler darin, dass die Opnsense den Traffic stur auf die Standleitung schießt und jede Route etc übergeht.

Da sollte die ID vom virtual private gateway drin sein

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html#vpn-create-vpg

Du sagst es: sollte...

Das kann nicht stimmen. Der Traffic aus dem AWS VPC muss über die interne IP eurer Firewall gehen

Beweisfoto im Anhang...  :-[

Wenn AWS VPN:
Bist nach dieser Anleitung vorgegangen?

Wir sind genau nach dieser Anleitung vorgegangen.
Nach ein paar Sitzungen heute mit dem AWS Support hat sich folgender Verdacht erhärtet:
Der Traffic wird nicht richtig geroutet.

Die Prüfung der Routing Tabelle zeigt, dass das Subnetz von der Firewall über das externe Interface geroutet wird.
Stimmt das so?

Wurden denn auch entsprechend Regel angelegt? Bei AWS muss m.W. ja auch das verwendete Netz hinterlegt werden etc.?

Bei AWS wurde alles gemäß Vorgaben vom AWS Support hinterlegt.

Hallo zusammen,

wir kämpfen hier gerade mit einem kleinem Problem:

Ziel: Über die Firewall einen IPSec-Tunnel aufzubauen, der unser lokales Netz mit einer AWS VPC verbindet (also Site2Site).
Problem: Der Tunnel steht, aber es gehen keine Daten durch.

Wir haben schon mit dem AWS Support rumgemacht, kommen aber nicht hinter das Problem.
Im Endeffekt steht der Tunnel, aber es gehen keinerlei Daten von beiden Seiten drüber, weder ICMP noch SSH etc.
Auch die Byte-Zahl in der Tunnel-Statistik bleibt auf 0 stehen.

Ich hab die aktuellen Einstellungen von Phase 1 und 2 angehängt; diese wurden gemäß der Vorgaben von AWS hinterlegt (analog zu PFSense).

Hoffentlich weiß jemand von euch Rat.

Merci,

Alex

Hallo,

ich scheitere aktuell an folgender Konfiguration:

Wir haben hier eine Standleitung anliegen, die mit IPv4 und IPv6 IPs ausgestattet ist.
IPv4 wird aktuell schon verwendet und soll um IPv6 erweitert werden.
Idealerweise soll dafür ebenfalls der Datenverkehr nach außen über NATv6 laufen; macht uns die Verwaltung etc erheblich einfacher.
Intern soll DHCPv6 verwendet werden.

Außerdem soll in Zukunft eine OpenVPN-Verbindung von außen möglich sein; diese ist aber nicht dafür gedacht, ins interne Netz zu kommen, sondern nur, um über die Büro-IP nach außen zu kommen.
Dies ist notwendig, da manche externe Services nur von bestimmten IPs erreichbar sind.

Ich hab mich an dieser Konfiguration schon einmal gewagt, aber bin an der IPv6 Konfiguration gescheitert.
Maximal war es möglich, dass die Firewall ins Internet kam, aber kein Client mehr (sowohl über IPv4 als auch IPv6).

Kann vielleicht jemand mir da mal drüber sehen und mir vielleicht den ein oder anderen Tip geben, wie ich das so hinbekomme?

Vielen Dank,

Alex

Dem ist (von meiner Seite aus) nichts mehr hinzuzufügen, danke Franco dafür.
Wie schon gesagt: ich finde eure Arbeit super und es macht jeden Tag Spaß, mit dem was am Ende rauskommt zu arbeiten.

Ernstgemeinte Frage: wie genau kann OPNsense hier besser werden? Welche Kommunikation ist falsch, wie viel darf reagiert werden, wie viel dürfen/müssen wir uns gefallen lassen?

Versteh mich nicht falsch, ihr macht aus meiner Sicht extrem viel super.
Im Endeffekt könnt ihr das Thema nur mit zwei Wegen aus der Welt schaffen: Entweder das Thema aussitzen bis die Gegenseite auf gibt oder dem ganzen mit Offenheit und Geduld begegnen.

Es ist absolut verständlich, dass ihr euch gegen irgendwelche Angriffe wehrt, aber damit erreicht aus meiner Sicht die Gegenseite genau das, was sie erreichen will: Eine Gegenreaktion von euch.

Ich an eurer Stelle würde diese Angriffe mit Offenheit und viel guter Code-Entwicklung begegnen.

Durch deine Antwort vermute ich, dass ihr schon den ein oder anderen Versuch zum Dialog gestartet habt, ohne sichtbaren Erfolg.
Daher würde ich einfach mal die Gegenseite dazu einladen, in irgendeinem Live-Medium oder per Mail in einen Dialog zu treten.
Mit dem Unterschied, dass jeder Satz / jede Nachricht hier im Forum veröffentlicht wird; ergo offen ausgetragen wird.

Ich hatte eine ähnliche Situation mit zwei Entwicklungs-Abteilungen; die Probleme konnten nur durch ein "in einen Raum packen und einsperren" gelöst werden.

Ihr habt damit nicht viel zu verlieren, da OpnSense super ist und ihr ne super Community hinter euch habt.
Nur der aktuelle Zustand tut beiden Projekten nicht gut; er kostet euch Nerven und Zeit und verunsichert Anwender und Entwickler.

VG,

Alex

Ich würde mir ja eins wünschen:
Ruhe zwischen den Projekten und vielleicht irgendwann sogar eine minimale Zusammenarbeit.
Aber so wie das aktuell aussieht befinden wir uns hier in einem Art kalten Krieg zwischen OpnSense und PfSense.

Ich finde es toll, in Zukunft OpnSense über die "Kommerziellen" Versionen zu unterstützen, auch wenn das aus Verständlichen Gründen etwas für Unruhe sorgen könnte.

Trotz alle dem macht OpnSense ne gute Arbeit und sorgt vielleicht auch indirekt dafür, dass sich PFSense weiter entwickelt.

Hallo,

mit dem angegeben Router wird es nicht funktionieren, da OPNSense zwingend x86 kompatible Prozessoren benötigt.

OPNsense® is available for x86-32 (i386) and x86-64 (amd64) bit microprocessor architectures.

Was aber gehen würde ist einen Router wie beispielsweise die von TP-Link nur als AP zu verwenden.
http://www.tp-link.com/en/FAQ-378.html

Oder natürlich ein Board wie die von PC Engine verwenden mit einer WLAN Karte, aber ist wie richtig erwähnt die etwas teure Lösung.

VG,

Alex