Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - SEi

#1
Hello Frank,

sorry for my late answer.
I was not lucky, igmpproxy 0.2.1 does not start with a Bridge Interface as upstream.

As a workaround, I switched my DSL modem to router mode and bypassed my opnsense Firewall with a weird VLAN to my media Receiver. So my media Receiver has a direct  Internet Connection as only device.

At the Moment I cannot do anything other than wait and hope for a working igmpproxy >= 0.2.1 for PPPoE Interfaces.


Regards
Sven
#2
Same here, igmpproxy 0.2.1 on a PPPoE upstream is not starting.
After reverting to igmpproxy 0.1, igmpproxy starts, but it only supperts IGMP v2, but for Deutsche Telekom EntertainTV I need IGMP v3, which means igmpproxy 0.2.1.

Best solution would be to fix the problem in the upstream-release of igmpproxy for FreeBSD.

As a dirty workaround, I will try this idea when I am back home today:

1. Setup an virtual IP on the ethernet Interface for the PPPoE-connection.
2. Brigde virtual IP and PPPoE, which should give me a static Interface as upstream for igmpproxy 0.2.1
3. igmpproxy 0.2.1 hopefully starts and provides LAN side IGMP v3


best regards,
Sven
#3
German - Deutsch / Re: IPSEC Rätsel
February 13, 2017, 02:36:31 PM
Danke für die Antworten!
Mittlerweile bin ich auf OpenVPN umgestiegen.
#4
German - Deutsch / Re: IPSEC Rätsel
February 11, 2017, 05:58:15 PM
Danke für die schnelle Antwort, hilft mir allerdings nicht wirklich weiter.

Es existiert doch für jedes Interface eine implizite "Default deny rule" und Log-Einträge davon sehe, wenn ich die entsprechende Logging-Option setze.
allow log LAN to VPS ICMP loggt mir entsprechende Ping-Versuche ausgehend. Aber der VPS scheint das ipsec-Paket nicht zu wollen.
#5
German - Deutsch / IPSEC Rätsel
February 11, 2017, 05:27:43 PM
Hallo zusammen,

ich habe seit gestern OPNsense 17.1.1 amd64 auf einer Black Dwarf laufen. Die Installation hat super funktioniert und ich bin mit allem glücklich. Tolle Arbeit! :)
Eine Sache gibt mir allerdings Rätsel auf. Vielleicht habe ich aber auch nur etwas triviales vergessen.
Ich bekomme keine Pakete über meinen IPSec-Tunnel.
Szenario: OPNsense WAN PPPoE, LAN privates Netz, Remote VPS mit fester IP-Adresse.
IPsec-VPN zwischen OPNsense und dem VPS auf Basis IKEv2 mit Zertifikat-Authentifizierung.
Der Tunnel wird aufgebaut, ipsec statusall sagt auf beiden Rechnern (FW und VPS) ESTABLISHED... INSTALLED ... lokale IP === Remote
Ich bekomme allerdings keinen Ping oder SSH durch den Tunnel, weder von der Firewall noch vom LAN.
Mit tcpdump sehe ich ipsec-Pakete jeweils in beide Richtungen.
In den Firewall-Logs steht nichts.
Ich bin mit meinem Latein am Ende  ???
Das gleiche Setup hat mit pfSense funktioniert.
Es funktioniert auch, wenn ich den Tunnel über einen Linux-Server mit strongswan im LAN hinter der Firewall über Port-Forwards aufbaue. Allerdings hätte ich den Tunnel lieber über die Firewall laufen, das macht das Routing einfacher.
Ich bin für jede Idee dankbar.

Viele Grüße
Sven
#6
Quote from: monstermania on February 06, 2017, 08:16:31 AM
Trotzdem sollte OPNSense problemlos laufen. Ich nutze OPNSense 16.7.xx schon einige Monate auf einem VIA Eden 500 MHz mit CF-Karte.
Für die Firewall und Webproxy reicht die Leistung aus. Der Start dauert halt etwas und das GUI läuft manchmal etwas zäh. Ein Neustart des WebProxy z.B. dauert halt ein paar Minuten.  ;)
So 50-60Mbit schaffe ich mit dem Teil. Mehr als genug für meinen DSL8000-Anschluss.

Das wäre für meine Bedürfnisse ja auch vollkommen ausreichend.
Vielleicht probiere ich mal ein 16.7. NanoBSD-Image.
Hat jemand Erfahrung mit dem Update von 16.7. auf 17.1 bei den NanoBSD-Images im Hinblick auf die Änderung der Slices. Bekommt das der Update-Prozeß hin?
#7
Hallo zusammen,

kurzer Zwischenstand:
ich konnte die SD-Karte mit dem NanoBSD-i386-Image auf meinem Notebook mit GhostBSD mounten (muss beim booten schon eingesteckt sein, aber das ist eine andere Geschichte).
So konnte ich in loader.conf vty auf vt setzen. Aber leider ohne Erfolg.
Auf der VGA sehe ich die gleichen Ausgaben wie auf der seriellen.
Ich vermute fast, er kommt garnicht bis zum lesen der loader.conf.

Mein nächster Versuch war die Installation des NanoBSD-i386-serial-Image von einem USB-Stick auf die SD-Karte.
Hat ewig gedauert, lief aber durch.
Den anschließenden Boot-Versuch habe ich nach über 30 Minuten abgebrochen, als er dann immer noch nicht das Web-UI geladen hatte.
Mein Fazit soweit: Die Hardware ist wohl echt zu schwachbrüstig für OPNsense.
Rein interessehalber: Wo liegen die großen Unterschiede zur pfSense, die sich so massiv auf die Performance auf der kleinen Hardware auswirken?


Viele Grüße

Sven
#8
Vielen Dank für die Antworten soweit.

Ich hoffe, dass ich am Wochenende Zeit finde, mich der Sache nochmal zu widmen.
Falls ich neue Erkenntnisse gewinne, werde ich sie hier teilen.

Viele Grüße,
Sven
#9
Hallo zusammen,

als *sense Neuling möchte ich erstmal die Community grüßen und mich für die großartige Arbeit bedanken.

Kurz zum Hintergrund: Ich wollte meinen betagten Linksys WRT54GL an meinem privaten DSL-Anschluss durch etwas softwaremäßig neueres ersetzen. Also habe ich ein altes Via Epia M-II (C3 600MHz CPU, 1GB RAM) abgestaubt und auf eine 8 GB SD-Karte das OPNsense 17.1 i386 Nano Image geschrieben.
Eingeschaltet, serielle Verbindung, erster Boot, alles gut soweit. Es hat zwar gedauert, aber es ging.
Nur jetzt hängt das System beim booten kurz nach den ersten Ausgaben auf der seriellen Konsole "FreeBSD i386...".
Ich vermute, dass es etwas mit der vt-Konfiguration, ähnlich wie bei stormy im 17.1-Forum, zu tun hat.

Nun meine Frage: Ich vermute, dass ich den vt-Parameter in der bootloader-Konfig-Datei ändern muss.
Nur wie mache ich das? Mein Linux-Desktop erkennt die Partitionen auf der SD-Karte nicht, genauso wie ein GhostBSD 10.3. Gab es da Änderungen in 11.0?

Die Hardware funktioniert grundsätzlich. Auf einer zweiten SD-Karte habe ich die aktuelle pfSense, die läuft ausreichend schnell für meinen Bedarf. Allerdings würde ich lieber OPNsense verwenden, in der Hoffnung, dass die i386 Nano Images noch etwas weiter leben dürfen.

Viele Grüße
Sven