121
German - Deutsch / Re: Routing Probleme
« on: July 16, 2018, 10:00:15 am »
PS: pfSense ist nicht Voldemort. Solang alles in geordneten Bahnen geht darf man das ruhig schreiben :-D
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.
122
German - Deutsch / OpenVPN Firewall-Regeln - welches Interface
« on: July 13, 2018, 03:22:50 pm »
Hallo,
ich betreibe 2 OPNsense Instanzen unabhängig voneinander. Einmal zu Hause hinter nem Modem und ein mal bei Hetzner als vServer. Beide haben die aktuellste 18.1 Version.
Auf beiden laufen OpenVPN Server (Zwei daheim, einer beim Hoster - auch hier, völlig unabhängig von einander).
Auf jeder OPNsense sind die Server jeweils einem Interface zugeordnet (unter Schnittstellen)
Jetzt das Verwunderliche:
zu Hause:
Firewallregeln des zugeordneten Interfaces funktionieren, auch wenn in "OpenVPN" keine Regeln sind
Hoster:
Firewallregeln funktionieren NICHT. Ich muss explizit das "OpenVPN" Interface nutzen und wenn ich Traffic im zugeordneten Interface durchlasse, aber bei "OpenVPN" nichts drin habe, ist keine Kommunikation möglich.
Wann wird also was genommen?
ich betreibe 2 OPNsense Instanzen unabhängig voneinander. Einmal zu Hause hinter nem Modem und ein mal bei Hetzner als vServer. Beide haben die aktuellste 18.1 Version.
Auf beiden laufen OpenVPN Server (Zwei daheim, einer beim Hoster - auch hier, völlig unabhängig von einander).
Auf jeder OPNsense sind die Server jeweils einem Interface zugeordnet (unter Schnittstellen)
Jetzt das Verwunderliche:
zu Hause:
Firewallregeln des zugeordneten Interfaces funktionieren, auch wenn in "OpenVPN" keine Regeln sind
Hoster:
Firewallregeln funktionieren NICHT. Ich muss explizit das "OpenVPN" Interface nutzen und wenn ich Traffic im zugeordneten Interface durchlasse, aber bei "OpenVPN" nichts drin habe, ist keine Kommunikation möglich.
Wann wird also was genommen?
123
German - Deutsch / Re: dhcpd6 fällt immer wieder aus
« on: July 13, 2018, 01:14:48 pm »
Der Ausfall hängt irgendwie zusammen mit dem Setzen von System DNS Servern.
Ich habe 4 DNS Server eingetragen. 2 IPv4 und 2 IPv6. Die IPv4 gehen auf das IPv4 Gateway und das selbe mit IPv6.
Ständig raucht dann aber der dhcpd6 und openvpn ab.
Ich habe 4 DNS Server eingetragen. 2 IPv4 und 2 IPv6. Die IPv4 gehen auf das IPv4 Gateway und das selbe mit IPv6.
Ständig raucht dann aber der dhcpd6 und openvpn ab.
124
German - Deutsch / dhcpd6 fällt immer wieder aus
« on: July 12, 2018, 10:07:24 pm »
Nabend. Mein dhcpd6 steigt seit Neuestem sporadisch aus. Tritt gefühlt seit 18.1.11 auf.
In der Systemprotokolldatei finde ich dazu nix. Wie kann ich dem Grund auf die Schliche kommen?
Ich weiß nicht mal wann das passiert.
In der Systemprotokolldatei finde ich dazu nix. Wie kann ich dem Grund auf die Schliche kommen?
Ich weiß nicht mal wann das passiert.
125
German - Deutsch / Re: System-DNS-Server
« on: July 09, 2018, 09:30:54 pm »
PS: Wenn man einen Dual Stack hat und manuell DNS Server setzen will muss man darauf achten die DNS Gateways zu setzen. Zumindest für IPv6 Adressen. Sonst geht IPv6 plötzlich nicht mehr.
126
German - Deutsch / Re: DynDNS mit SIM-Karte
« on: July 03, 2018, 03:47:02 pm »
SIM-Karte heißt für mich erstmal Internet über Mobilfunk. In 99,9% aller Fälle steckt hinter der Public IP eines Mobilfunkproviders ein CGNAT Gateway, sodass DynDNS ohnehin nutzlos wäre.
Es sei denn du hast vertraglich eine eigene dedizierte IP Adresse.
Es sei denn du hast vertraglich eine eigene dedizierte IP Adresse.
127
German - Deutsch / Re: Security über ein Bridge Network
« on: July 02, 2018, 02:51:42 pm »
Man kann dein Netzwerksetup aus deinen Beschreibungen nur erahnen.
- Wenn ich das richtig verstehe hast du 4 VLANs.
- diese VLANs sind gebridged und ergeben das Netzwerk das die Endgeräte gemeinsam nutzen
In diesem Falle sind soweit ich das überblicken kann die VLANs zwecklos. VLANs verwendet man zur Trennung von Netzwerken, nicht aber um diese Trennung durch eine Bridge dann wieder zunichte zu machen.
Zumal auf der Bridge alle Geräte dann ohnehin im selben IP Adressbereich und der selben Broadcast-Domäne sind.
Lassen wir das außen vor, so ist zu sagen, dass die VLAN-ID ein Layer-2 Merkmal ist und die Firewall der OPNsense nicht aufgrund von L2-Informationen arbeitet. So ist zum Beispiel auch keine Regel möglich aufgrund einer MAC-Adresse.
Das bedeutet, dass es so wie du es dir vorstellst nicht geht. Du musst deine Firewallregeln so oder so auf Grundlage von IP Adressen oder IP Bereichen aufbauen.
- Wenn ich das richtig verstehe hast du 4 VLANs.
- diese VLANs sind gebridged und ergeben das Netzwerk das die Endgeräte gemeinsam nutzen
In diesem Falle sind soweit ich das überblicken kann die VLANs zwecklos. VLANs verwendet man zur Trennung von Netzwerken, nicht aber um diese Trennung durch eine Bridge dann wieder zunichte zu machen.
Zumal auf der Bridge alle Geräte dann ohnehin im selben IP Adressbereich und der selben Broadcast-Domäne sind.
Lassen wir das außen vor, so ist zu sagen, dass die VLAN-ID ein Layer-2 Merkmal ist und die Firewall der OPNsense nicht aufgrund von L2-Informationen arbeitet. So ist zum Beispiel auch keine Regel möglich aufgrund einer MAC-Adresse.
Das bedeutet, dass es so wie du es dir vorstellst nicht geht. Du musst deine Firewallregeln so oder so auf Grundlage von IP Adressen oder IP Bereichen aufbauen.
128
German - Deutsch / Re: System-DNS-Server
« on: June 29, 2018, 01:22:01 pm »
Die Root-Server resolven doch nicht rekursiv ?!?
Oder macht das der Outbound ausgehend von den Rootservern?
Macht das die DNS Abfragen nicht noch langsamer?
Oder macht das der Outbound ausgehend von den Rootservern?
Macht das die DNS Abfragen nicht noch langsamer?
129
German - Deutsch / Re: System-DNS-Server
« on: June 29, 2018, 11:36:22 am »
Weiß keiner bescheid? 
Hintergrund ist, ich möchte statt des Provider DNS meine eigenen Adressen setzen.
Weiß aber nicht, welche Option ich bei den Gateways eintragen muss.
Hintergrund ist, ich möchte statt des Provider DNS meine eigenen Adressen setzen.
Weiß aber nicht, welche Option ich bei den Gateways eintragen muss.
130
German - Deutsch / System-DNS-Server
« on: June 26, 2018, 10:34:30 pm »
Wenn ich unter System->Einstellungen->Allgemein DNS Server eintrage, wozu ist dann das Feld "Verwende Gateway"
Welche Auswirkungen hat es, wenn ich kein Gateway setze?
Als Info: Ich habe nur eine WAN Schnittstelle und je ein GW für IPv4 und IPv6
Und:
Wozu die Option: Verwenden Sie den DNS-Forwarder/Resolver nicht als DNS-Server für die Firewall
Wenn diese Option aus ist, dann MUSS ja mindestens ein Resolver (dnsmasq oder unbound) aktiv sein, korrekt?
Und wenn es an ist, dann verwendet er die System-Nameserver egal ob ein resolver aktiv ist?
Welche Auswirkungen hat es, wenn ich kein Gateway setze?
Als Info: Ich habe nur eine WAN Schnittstelle und je ein GW für IPv4 und IPv6
Und:
Wozu die Option: Verwenden Sie den DNS-Forwarder/Resolver nicht als DNS-Server für die Firewall
Wenn diese Option aus ist, dann MUSS ja mindestens ein Resolver (dnsmasq oder unbound) aktiv sein, korrekt?
Und wenn es an ist, dann verwendet er die System-Nameserver egal ob ein resolver aktiv ist?
131
German - Deutsch / Re: VoIP Unitymedia
« on: June 21, 2018, 12:04:25 am »
Beim Outbound NAT (Auch S-NAT oder Source NAT genannt) wird die private Quell-IP-Adresse des Pakets auf deine externe IP Adresse umgeschrieben und ein zufällig freier Port des Routers wird gewählt, bevor das Paket den Router verlässt. Diesen Quell-Port merkt sich der Router in einer Tabelle zusammen mit deiner privaten IP.
Die Gegenstelle muss dann die Antwort an deine externe IP und den Port des Routers schicken.
Kommt die Antwort an, weiß der Router anhand des Ports, den er gewählt hat, dass er das Paket an genau den anfragenden Rechner zurückschicken muss.
Der ganze HickHack ist also nötig, weil das private Netz ja via NAT vom öffentlichen Adressraum getrennt wird.
Beispiel: Seitenaufruf Google
Paket auf dem PC -> will zu Google
[ IP | 192.168.178.101 ] -> [IP | 172.217.23.163]
[ Port | 8615 (evtl. zufällig) ] -> [Port | 80 ]
Du siehst oben links deine private IP
Unten links ist ein zufälliger Port. Obwohl Port 80 für HTTP reserviert ist, ist nie gesagt, dass ein Browser diesen bei HTTP Requests als Quellport auch nimmt.
Rechts oben die IP von google.de, rechts unten Port 80. Dieser MUSS 80 sein, da ein Webserver DEFINITIV auf Port 80 lauscht (meistens)
So sendet es dein PC ab und so kommt es dann beim Router auch an. Dein Router macht nun folgendes:
- Er speichert sich deine IP und Quellport
- Er tauscht die Quell-IP mit der externen IP (deine Internet IP) aus
- Er tauscht den Quell-Port mit einem zufällig freien Port aus. (Warum? Weil der vom Client gewünschte Port eventuell schon am Router belegt ist). Nun sieht es so aus:
Paket auf dem Router -> will zu Google
[ IP | 88.130.12.59 ] -> [IP | 172.217.23.163]
[ Port | 12387 (zufällig) ] -> [Port | 80 ]
Der weitere Teil zu Google ist für die Erklärung der statischen Portfunktion nicht erforderlich.
Statischer Port bedeutet: Der Router nimmt den vom Client ausgewählten Quell-Port 1:1 für die Weiterübertragung. Das sähe im obigen Fall so aus:
[ IP | 88.130.12.59 ] -> [IP | 172.217.23.163]
[ Port | 8615 (statisch) ] -> [Port | 80 ]
Aber warum das Ganze? Im Falle des SIP Protokolls will man einfach sicher gehen, dass der Quellport den das Telefon / Softphone / SIP-Client verwendet eben der selbe ist, der auch am SIP-Server ankommt. Der Client kann das selbst bestimmen, dem Router muss man aber sagen, dass er diesen Port zugunsten eines zufälligen nehmen soll.
Die Gegenstelle muss dann die Antwort an deine externe IP und den Port des Routers schicken.
Kommt die Antwort an, weiß der Router anhand des Ports, den er gewählt hat, dass er das Paket an genau den anfragenden Rechner zurückschicken muss.
Der ganze HickHack ist also nötig, weil das private Netz ja via NAT vom öffentlichen Adressraum getrennt wird.
Beispiel: Seitenaufruf Google
Paket auf dem PC -> will zu Google
[ IP | 192.168.178.101 ] -> [IP | 172.217.23.163]
[ Port | 8615 (evtl. zufällig) ] -> [Port | 80 ]
Du siehst oben links deine private IP
Unten links ist ein zufälliger Port. Obwohl Port 80 für HTTP reserviert ist, ist nie gesagt, dass ein Browser diesen bei HTTP Requests als Quellport auch nimmt.
Rechts oben die IP von google.de, rechts unten Port 80. Dieser MUSS 80 sein, da ein Webserver DEFINITIV auf Port 80 lauscht (meistens)
So sendet es dein PC ab und so kommt es dann beim Router auch an. Dein Router macht nun folgendes:
- Er speichert sich deine IP und Quellport
- Er tauscht die Quell-IP mit der externen IP (deine Internet IP) aus
- Er tauscht den Quell-Port mit einem zufällig freien Port aus. (Warum? Weil der vom Client gewünschte Port eventuell schon am Router belegt ist). Nun sieht es so aus:
Paket auf dem Router -> will zu Google
[ IP | 88.130.12.59 ] -> [IP | 172.217.23.163]
[ Port | 12387 (zufällig) ] -> [Port | 80 ]
Der weitere Teil zu Google ist für die Erklärung der statischen Portfunktion nicht erforderlich.
Statischer Port bedeutet: Der Router nimmt den vom Client ausgewählten Quell-Port 1:1 für die Weiterübertragung. Das sähe im obigen Fall so aus:
[ IP | 88.130.12.59 ] -> [IP | 172.217.23.163]
[ Port | 8615 (statisch) ] -> [Port | 80 ]
Aber warum das Ganze? Im Falle des SIP Protokolls will man einfach sicher gehen, dass der Quellport den das Telefon / Softphone / SIP-Client verwendet eben der selbe ist, der auch am SIP-Server ankommt. Der Client kann das selbst bestimmen, dem Router muss man aber sagen, dass er diesen Port zugunsten eines zufälligen nehmen soll.
132
18.1 Legacy Series / Re: OpenVPN with TCP on Port 443
« on: June 20, 2018, 11:51:42 am »If you are running the web interface of TCP/443 it won't work - you have to move it to another port first.
I have a working setup of the webinterface running on port 443 and openvpn also on 443.
Seems OpenVPN just listens for the webinterface on LAN:443 and WAN:443 is free to use.
However, I could not detect any problems with my setup.
133
German - Deutsch / Re: VoIP Unitymedia
« on: June 20, 2018, 07:31:12 am »
(Bild 1, Portweiterleitung)
- Bei den Portfreigaben reicht eine Beschränkung auf UDP Traffic.
- Was ist 192.168.1.121 für ein Gerät?
- Diese Adresse sieht mir sehr nach DHCP-vergeben aus. Wenn du eine Portweiterleitung einrichtest solltest du besser die Adresse für das Gerät statisch vergeben. Es ist nie ganz garantiert, dass ein Gerät immer die selbe Adresse vom DHCP Server bekommt.
(Bild 2, Firewallregeln WAN)
- Auch hier reicht das Durchlassen nur von UDP
- Wenn du die SIP und RTP Server IPs oder IP ranges kennst, dann trage sie in einen Alias und verwende sie als Quellbedingung. Es ist immer schlecht alle (*) durchzulassen.
PS: Nicht zu vernachlässigende Kleinigkeit: Deine Descriptions "NAT" sind aussagekräftig wie das Wort Wurst. Wenn später die Anzahl der Regeln wächst hilft es echt, passendere Beschreibungen zu wählen wie: "Allow Inbound SIP Traffic from UnityMedia" - auf die Weise weißt du in nem halben Jahr noch genau was die Regel macht.
(Bild 3, Outbound NAT)
- Analog zu oben: Schränke deine Zielbedingung ein. Willst du wirklich, dass ALLES von dem Gerät mit statischem Port genattet wird? Auch hier, wenn verfügbar, die Provider IPs mit in Betracht ziehen.
- Quelle und Ziel würde ich hier auch wieder auf UDP beschränken
Du kannst dich auch an anderer Leute Einstellungen hier im Forum orientieren. Es gibt Beiträge zu einigen Anbietern ;-)
Zum Keepalive:
Das ist keine Einstellung, die du beim NAT treffen kannst. Das ist ein "Trick" um die Portweiterleitung zu umgehen.
Die Firewall ist stateful und das bedeutet, dass Verbindungen, die ausgehen, auch auf dem Rückweg wieder zugelassen werden. Wenn dein Gerät jetzt ständig auf UDP zu deinem Anbieter rausfunkt lässt OPNsense die Antwort also durch. Da bei UDP im Gegensatz zu TCP keine verbindungsorientierte Übertragung stattfindet (hierzu lies bitte mal etwas über TCP/UDP nach) kann die Firewall nicht bestimmen, wann eine Verbindung "vorbei" ist, also wann die Firewall wieder eingehenden Traffic blocken soll. Deshalb wird bei UDP einfach eine Karenzzeit gegeben, in der eine UDP Gegenstelle durch die Firewall kommt. Wenn du jetzt also ständig das Keepalive sendest, kann der Anbieter dir jederzeit antworten.
Diese Funktion kenne ich definitiv von der FritzBox.
Wie du das mit deinem Sip Gerät machst weiß ich nicht. Aber von dem aus muss die Keepalive Verbindung ausgehen.
Dennoch: Dieser Weg ist nicht sicherer als ein sauber! an die Situation angepasstes Port-Forwarding. Denn der Effekt ist der gleiche: Der Anbieter (und nur der) kommt durch. Ob das jetzt durch Keepalive, Portweiterleitung passiert ist egal.
- Bei den Portfreigaben reicht eine Beschränkung auf UDP Traffic.
- Was ist 192.168.1.121 für ein Gerät?
- Diese Adresse sieht mir sehr nach DHCP-vergeben aus. Wenn du eine Portweiterleitung einrichtest solltest du besser die Adresse für das Gerät statisch vergeben. Es ist nie ganz garantiert, dass ein Gerät immer die selbe Adresse vom DHCP Server bekommt.
(Bild 2, Firewallregeln WAN)
- Auch hier reicht das Durchlassen nur von UDP
- Wenn du die SIP und RTP Server IPs oder IP ranges kennst, dann trage sie in einen Alias und verwende sie als Quellbedingung. Es ist immer schlecht alle (*) durchzulassen.
PS: Nicht zu vernachlässigende Kleinigkeit: Deine Descriptions "NAT" sind aussagekräftig wie das Wort Wurst. Wenn später die Anzahl der Regeln wächst hilft es echt, passendere Beschreibungen zu wählen wie: "Allow Inbound SIP Traffic from UnityMedia" - auf die Weise weißt du in nem halben Jahr noch genau was die Regel macht.
(Bild 3, Outbound NAT)
- Analog zu oben: Schränke deine Zielbedingung ein. Willst du wirklich, dass ALLES von dem Gerät mit statischem Port genattet wird? Auch hier, wenn verfügbar, die Provider IPs mit in Betracht ziehen.
- Quelle und Ziel würde ich hier auch wieder auf UDP beschränken
Du kannst dich auch an anderer Leute Einstellungen hier im Forum orientieren. Es gibt Beiträge zu einigen Anbietern ;-)
Zum Keepalive:
Das ist keine Einstellung, die du beim NAT treffen kannst. Das ist ein "Trick" um die Portweiterleitung zu umgehen.
Die Firewall ist stateful und das bedeutet, dass Verbindungen, die ausgehen, auch auf dem Rückweg wieder zugelassen werden. Wenn dein Gerät jetzt ständig auf UDP zu deinem Anbieter rausfunkt lässt OPNsense die Antwort also durch. Da bei UDP im Gegensatz zu TCP keine verbindungsorientierte Übertragung stattfindet (hierzu lies bitte mal etwas über TCP/UDP nach) kann die Firewall nicht bestimmen, wann eine Verbindung "vorbei" ist, also wann die Firewall wieder eingehenden Traffic blocken soll. Deshalb wird bei UDP einfach eine Karenzzeit gegeben, in der eine UDP Gegenstelle durch die Firewall kommt. Wenn du jetzt also ständig das Keepalive sendest, kann der Anbieter dir jederzeit antworten.
Diese Funktion kenne ich definitiv von der FritzBox.
Wie du das mit deinem Sip Gerät machst weiß ich nicht. Aber von dem aus muss die Keepalive Verbindung ausgehen.
Dennoch: Dieser Weg ist nicht sicherer als ein sauber! an die Situation angepasstes Port-Forwarding. Denn der Effekt ist der gleiche: Der Anbieter (und nur der) kommt durch. Ob das jetzt durch Keepalive, Portweiterleitung passiert ist egal.
134
German - Deutsch / Re: avm fritz box vs opnsense
« on: June 19, 2018, 09:53:31 am »
Ich habe den Gigaset Support mal angeschrieben - eigentlich wollte ich nur wissen welchen PoE Standard die N510 unterstützt. Ich habe allerdings nicht erwartet mit der völligen Textbaustein-Ignoranz konfrontiert zu werden. (Warum eigentlich nicht? Ich glaube manchmal einfach noch zu viel an die Menschheit)
Also habe ich einen Textbaustein erhalten in dem meine Frage natürlich völlig außer Acht gelassen wurde.
Stattdessen wurde mir mitgeteilt, dass die N510 keine komplette Telefonanlage ist und nicht direkt hinter einem Router betrieben werden kann. Selbst wenn man sich eine Asterisk hinstellt ist der Funktionsumfang laut Gigaset zumindest eingeschränkt.
Also habe ich einen Textbaustein erhalten in dem meine Frage natürlich völlig außer Acht gelassen wurde.
Stattdessen wurde mir mitgeteilt, dass die N510 keine komplette Telefonanlage ist und nicht direkt hinter einem Router betrieben werden kann. Selbst wenn man sich eine Asterisk hinstellt ist der Funktionsumfang laut Gigaset zumindest eingeschränkt.
135
German - Deutsch / Re: avm fritz box vs opnsense
« on: June 18, 2018, 10:12:53 pm »
Tatsächlich habe ich schon ein Auge auf die N510 geworfen. Es gibt sie auch für ca. 240€ im Bundle mit 2 x SL750H Pro. Die Telefone liegen gut in der Hand und da würde ich mein Fritz Fon nicht vermissen, dessen x-Zusatzfunktionen ich eh nicht brauche.
Ich werds mir auf jeden Fall zulegen und dann mal berichten.
Ich werds mir auf jeden Fall zulegen und dann mal berichten.