Messages

leider muss ich hier zu Hause zur Zeit die OPNsense hinter meiner Fritzbox betreiben und nicht direkt mit dem extra gekauften Vigor 130

Welchen Grund hat das? Einen technischen kann ich mir fast kaum vorstellen.

Selbst wenn sie sich nicht in einem /24 Block befinden, weiß das die OPNsense ja nicht und es kann ihr auch egal sein.

Letztendlich muss sowas ja auch nur der verantwortliche Router für den Block wissen, um ins richtige Netz zu routen, sowie ein direkt angeschlossener Client um zu wissen, ob die Anfrage ins LAN oder ans Gateway geht.

Wenn du nen komplettes /24 Netz durch die Firewall lässt, gleicht er bei eingehender Verbindung ohnehin nur ab, ob sich besagte IP im definierten Netz befindet. Daher sollte es trotzdem funktionieren. Für deine Firewall ist der 1und1 IP Block eh extern und geht übers Gateway der OPNsense.  Die Netzmaske wird ja bei der Kommunikation nicht in IP Paketen gespeichert.

Aber lass mich wissen, ob die Umstellung auf einzelne IPs was nutzt.

Welche Version hast du vorher genutzt? Bin von 17.1.2 auf 17.1.3 gegangen und habe kein Problem.

Bist du sicher, dass du alle SIP, RTP und STUN Adressen von 1und1 zulässt? Eine aktuelle Liste habe ich im folgenden Post zusammengestellt: https://forum.opnsense.org/index.php?topic=4712.msg18404#msg18404

Durch das Bridging im Vigor130 ist es ohnehin so, dass das Modem transparent ist. In dem Sinne schließt du die OPNSense ja direkt ans Providernetz an. Alles was das Modem macht ist, jeglichen Verkehr vom LAN Port in VDSL zu verpacken und über die Leitung zu schicken. Der DSLAM beim Provider demoduliert das ganze dann wieder und speist es in das Konzentratornetz (Providernetz) ein, das dann auch wieder ein Ethernet/IP-Netz ist.
Andernfalls würde ja PPPoE nicht funktionieren.

IP Pakete als Ethernet-Frames durch ne 2-adrige Telefonleitung zu jagen wird nicht von Erfolg gekrönt sein :-D

FIX für etwas Sicherheit:

Ports kann ich leider nicht eingrenzen, sind sehr random.
Aber die IP Addressen, die 1und1 für RTP, STUN und SIP verwendet konnte ich mittels opnsense Paketfilter herausfinden. Es sind sau viele, aber wenn ich die Destination auf diese IPs einschränke dann sollten nur 1und1 Server Zugriff bekommen.

Code Select Expand


rtpproxy1-ngn.1und1.de - 212.227.124.2
rtpproxy2-ngn.1und1.de - 212.227.124.3
rtpproxy3-ngn.1und1.de - 212.227.124.66
rtpproxy4-ngn.1und1.de - 212.227.124.67
rtpproxy5-ngn.1und1.de - 212.227.124.4
rtpproxy6-ngn.1und1.de - 212.227.124.68
stun.1und1.de - 212.227.67.34
stun.1und1.de - 212.227.67.33
sipbalance1-1.1und1.de - 212.227.67.131
sipbalance2-1.1und1.de - 212.227.67.132
sipbalance3-1.1und1.de - 212.227.67.133
sipbalance4-1.1und1.de - 212.227.67.134
sipbalance5-1.1und1.de - 212.227.67.135
sipbalance6-1.1und1.de - 212.227.67.136
sipbalance7-1.1und1.de - 212.227.67.137
sipbalance8-1.1und1.de - 212.227.67.138
sipbalance9-1.1und1.de - 212.227.67.139
sipbalance10-1.1und1.de - 212.227.67.140
sipbalance1-2.1und1.de - 212.227.67.201
sipbalance2-2.1und1.de - 212.227.67.202
sipbalance3-2.1und1.de - 212.227.67.203
sipbalance4-2.1und1.de - 212.227.67.204
sipbalance5-2.1und1.de - 212.227.67.205
sipbalance6-2.1und1.de - 212.227.67.206
sipbalance7-2.1und1.de - 212.227.67.197
sipbalance8-2.1und1.de - 212.227.67.198
sipbalance9-2.1und1.de - 212.227.67.199
sipbalance10-2.1und1.de - 212.227.67.200
sipbalance1-3.1und1.de - 212.227.18.131
sipbalance2-3.1und1.de - 212.227.18.132
sipbalance3-3.1und1.de - 212.227.18.133
sipbalance4-3.1und1.de - 212.227.18.134
sipbalance5-3.1und1.de - 212.227.18.135
sipbalance6-3.1und1.de - 212.227.18.136
sipbalance7-3.1und1.de - 212.227.18.137
sipbalance8-3.1und1.de - 212.227.18.138
sipbalance9-3.1und1.de - 212.227.18.139
sipbalance10-3.1und1.de - 212.227.18.140
sipbalance1-4.1und1.de - 212.227.18.201
sipbalance2-4.1und1.de - 212.227.18.202
sipbalance3-4.1und1.de - 212.227.18.203
sipbalance4-4.1und1.de - 212.227.18.204
sipbalance5-4.1und1.de - 212.227.18.205
sipbalance6-4.1und1.de - 212.227.18.206
sipbalance7-4.1und1.de - 212.227.18.197
sipbalance8-4.1und1.de - 212.227.18.198
sipbalance9-4.1und1.de - 212.227.18.199
sipbalance10-4.1und1.de - 212.227.18.200


Edit:
Wäre es doof, statt 40 IPs freizugeben einfach die 3 Klasse C Netze freizugeben?
Das wären dann 212.227.18.0/24, 212.227.67.0/24 und 212.227.124.0/24.
Natürlich weiß weder ich noch die opnSense die tatsächlichen Netzmasken, die 1und1 zugeteilt sind, aber um diese IPs als Destination "zusammenzufassen" wäre es doch imho egal, ob es wirklich 24er Netze sind. Die opnSense schaut nur, ob die entsprechende IP im durchzulassenden Netz ist und gut ?!? Und ich vermute jetzt einfach stark, dass all diese Blöcke zu 1und1 gehören.

Ich danke dir sogar fürs "doof nachfragen"
Ich hatte es anders als mit der Any-Einstellung leider nicht hinbekommen. Vielleicht hab ich aber auch einen Denkfehler.

Wichtig ist, dass auf UDP die Ports 5060, 5070-5079 und 30000-30019 eingehend zur Kommunikation frei sind und auf die FritzBox geleitet werden. Wenn ich allerdings nur diese Ports outbound weiterleite, dann höre ich niemanden und kann nicht gehört werden. Ich nehme an, dass dann der RTP Stream nicht durchkommt.

Frage mich ohnehin, wozu ich das outbound nat brauche. normalerweise sollte doch eh alles, was aus meinem LAN ins WAN geht genattet werden, oder ?!?

Hallo,

ich verwende eine Fritz!Box hinter meinem opnSense als Telefonanlage (IP 10.0.0.3)
Jetzt möchte ich, dass Anrufe nicht gestört werden, wenn jemand zB. eine riesige Datei herunterlädt, oder, dass der Download langsamer wird, wenn ich einen Anruf starte.

Ich habe eine 50/10 Leitung (MBits/s Down/Up). Davon möchte ich fest 6.000 kBits/s Down und 2.000 kBits Up für allen Traffic reservieren, der von 10.0.0.3 kommt oder dahin geht.

Fragen:
- Habe ich das anhand der angehängten Regeln korrekt implementiert?
- Reicht es, den VoIP Traffic zu priorisieren? In den opnSense Dokus (https://docs.opnsense.org/manual/how-tos/shaper.html) geben sie auch Pipes und Rules für allen anderen Traffic an
- Kann jemand einfach die Pipe-Masken source und destination erklären?

Gruß Nasq

Hallo,

ich schreibe dieses kleine Tutorial, weil ich leider selbst nirgendwo fündig geworden bin und einiges ausprobieren musste, um es zum Laufen zu bekommen.

Um die opnSense richtig auszureizen betreibe ich sie direkt hinter einem reinen VDSL-Modem. Die Fritz!Box hängt am LAN Switch und ist zur Telefonanlage und WiFi AccessPoint kastriert. (IP-Client Modus)

Wie man die Box konfiguriert, darauf gehe ich selbst nicht ein. AVM bietet da aber auch Anleitungen für. Hier geht es darum, die Firewall einzurichten um eingehende und ausgehende Gespräche durchzulassen.

1. Aliase einrichten
Firewall->Aliase->Ansicht --> Neuen Alias hinzufügen (Typ: Ports)
Hier werden 1 Port und 2 Portbereiche definiert:
5060 -> SIP
5070:5079 -> VoIP Sprache (von 1und1 genutzte RTP Ports)
30000:30019 -> VoIP Fax (wenn benötigt)

Firewall->Aliase->Ansicht --> Neuen Alias hinzufügen (Typ: Hosts)
Alle IP Adressen vom verlinkten Post hinzufügen.
https://forum.opnsense.org/index.php?topic=4712.msg18404#msg18404

2. Portweiterleitung
Firewall->NAT->Portweiterleitung --> Hinzufügen
Schnittstelle: WAN
Version: IPv4
Protokoll: UDP
Ziel: WAN Adresse
Zielportbereich: angelegter Alias
Ziel-IP umleiten: IP der FritzBox
Zielport weiterleiten: Angelegter Alias

3. Outbound NAT
Firewall->NAT->Ausgehend

Zuerst Manuelle Erstellung ausgehender NAT Regeln auswählen und speichern.
Dann eine neue Regel anlegen:
Schnittstelle: WAN 
TCP/IP Version: IPv4 
Protokoll: UDP
Quelle: FritzBox IP
Quellport: jeglich
Ziel: jeglich
Zielport: jeglich
Übersetzung / Ziel: Schnittstellenadresse
Haken bei statischer Port <-- wichtig!

Verschiebt diese Regel jetzt noch an den Anfang der Liste (hinzugefügten Eintrag auswählen (Checkbox) und den Pfeil nach Links in der ersten Regel klicken.

So, es scheint jetzt zu klappen.
Ich habe für die WAN Schnittstelle eine kleine Änderung vorgenommen.
Ich habe den Haken bei "Nur einen IPv6-Präfix anfordern" gesetzt.
Laut Internet mag es mein Anbieter nicht, wenn für das WAN Interface eine IP Adresse angefordert wird.
https://forum.pfsense.org/index.php?topic=119409.msg681098#msg681098

Nach der Umstellung habe ich opnSense neu gestartet. Es kamen trotzdem Abbrüche beim VPN.
Nach einem  weiteren Reboot scheint jetzt alles zu klappen. Traue dem Braten aber noch nicht 100%
Ich werde es die Tage beobachten und dann hier noch mal berichten.

Hi Franco,

nein, habe keine Firewall Schedules.
Cronjobs habe ich nur alle 5 Minuten DynDNS Update und morgens um 4 Interface Reset am WAN.

Das Problem habe ich aber auch bei deaktivierten Crons reproduzierbar.

Okay, problem is not directly related to OpenVPN service.
Problem is, that every 15 minutes the newwanipv6 script restarts the vpn server. however, there is no new wan ip. so why is it constantly triggering this?

Code Select Expand

16:24:37 kernel: ovpns1: link state changed to DOWN
16:24:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:24:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:24:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:24:33 configd.py: [f5309844-dd64-4989-920f-3bc2a70d1684] Reloading filter
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Code Select Expand

16:39:37 kernel: ovpns1: link state changed to DOWN
16:39:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:39:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:39:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:39:33 configd.py: [aa01dc9b-32db-4b10-94d0-8b4c47ffae67] Reloading filter
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Code Select Expand

16:54:37 kernel: ovpns1: link state changed to DOWN
16:54:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:54:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:54:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:54:33 configd.py: [dbbdaa94-191c-4a93-9c83-1eb01491a478] Reloading filter
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Da das Problem nicht an OpenVPN liegt, sondern daran, dass alle viertel Stunde das newwanipv6-Script der Meinung ist den OVPN-Service neu starten zu müssen, wäre das Thema hier erledigt.
Sollte ich für das Grundproblem ne Lösung finden verlinke ich sie aber hier noch.

Also, laut Syslog wird dieser newwanipv6 Service alle 15 Minuten ausgeführt.

Code Select Expand

16:24:37 kernel: ovpns1: link state changed to DOWN
16:24:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:24:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:24:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:24:33 configd.py: [f5309844-dd64-4989-920f-3bc2a70d1684] Reloading filter
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Code Select Expand

16:39:37 kernel: ovpns1: link state changed to DOWN
16:39:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:39:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:39:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:39:33 configd.py: [aa01dc9b-32db-4b10-94d0-8b4c47ffae67] Reloading filter
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:39:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Code Select Expand

16:54:37 kernel: ovpns1: link state changed to DOWN
16:54:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
16:54:36 opnsense: /usr/local/etc/rc.newwanipv6:
16:54:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
16:54:33 configd.py: [dbbdaa94-191c-4a93-9c83-1eb01491a478] Reloading filter
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
16:54:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Seltsamerweise - nein, korrekterweise - ändern sich ja keine IPs. Es sei denn mein Provider würde mich mit 15 minütigen IP Updates nerven. Frage ist also: Warum zum Teufel wird alle Nase lang das WAN Interface neu konfiguriert, obwohl das nicht nötig wäre?

Ich bin jetzt die Systemlogs zum Zeitpunkt eines VPN-Ausfalls (Mar 3 16:24:37) durchgegangen und habe glaube ich herausgefunden was passiert.

Code Select Expand


Mar 3 16:24:37 kernel: ovpns1: link state changed to DOWN
Mar 3 16:24:37 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
Mar 3 16:24:36 opnsense: /usr/local/etc/rc.newwanipv6:
Mar 3 16:24:36 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /conf/dyndns_wanroute53'home.theqserver.de'0.cache: 87.158.148.163
Mar 3 16:24:33 configd.py: [f5309844-dd64-4989-920f-3bc2a70d1684] Reloading filter
Mar 3 16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::230:88ff:fe04:5a3%pppoe0
Mar 3 16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 87.186.224.157
Mar 3 16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:86:8d7f:cadc:201:2eff:fe65:8c73) (interface: wan) (real interface: pppoe0).
Mar 3 16:24:33 opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting pppoe0.

Ich kenne mich leider nicht so gut aus mit IPv6, aber es sieht hier so aus, als würde der newwanipv6 Service einen Restart von OpenVPN verursachen. Ich frage mich aber, wieso das alle paar Minuten passiert, wenn ich eine OpenVPN Verbindung aufbaue. Ich spiele weiter Detektiv.

Laut meinen Beobachtungen tritt der Fehler nur dann auf, wenn meine WAN Schnittstelle eine IPv6 Adresse zugewiesen hat.

Im OpenVPN Server selbst ist IPv6 deaktiviert. Selbst, wenn ich es dort aktiviere flieg ich nach 5 Minuten raus.
IPv4+6 ist in der Firewall im OVPN Netz komplett erlaubt, ICMP ist auf WAN auch freigeschaltet.