Dual WAN (DHCP + VLAN) mit einer physikalischen NIC
-
@_igor_ Also in deinem Setup wäre ich davon ausgegangen - sofern das inogy wirklich so mitgeteilt hat - dass VoIP auch nur auf dem VOIP Interface geht, dass also eine Verbindung auf dem WAN abgelehnt wird. Aber vielleicht solltest du da einfach sicherheitshalber nochmal nachfragen, was da genau Phase ist. Ich kenne das nur von anderen Kunden von anderen Providern so, dass bei unterschiedlichen VLANs bzw. extra "VoIP WAN" es wie folgt läuft:
WAN: ganz normal konfigurieren wie benötigt (e.g. PPPoE, DHCP o.ä.)
VOIP_WAN: wird auf das VLAN konfiguriert, dass der ISP angibt, meist mit DHCP. Bekommt oft andere externe IP oder sog. private IP aus Providernetz.LAN oder extra VoIP Netz für Telefonanlage oder Telefone:
Dort wird dann abgehend die Regel(n) so angepasst, dass sie über das Gateway VOIP_WAN rausgehen, damit die TK Anlage bzw. die Telefone auch wirklich nur über VOIP WAN sprechen. Wenn eingehend VOIP benötigt wird/soll, dann wird ein Port Forwarding auf dem VOIP_WAN konfiguriert (5060, 5061, je nachdem was der ISP braucht/will) auf die TK Anlage o.ä. Ausgehend wird in der Outbound NAT entweder im manual oder hybrid Mode eine Regel angelegt, die die VoIP Ports der Providers (unterschiedlich, 5060, 5061, udp/tcp) abgehend mit "static Port" auf VOIP_WAN(!) mappt, nicht auf das WAN. Daher nutzen wir hier fast immer Manual mode, da hier alles nicht gewünschte/unnötige NATting gleich weggelöscht werden kann (im Normalfall will man bspw. nicht, dass LAN -> VoipWAN spricht oder VoIP_LAN > WAN!).Default Route bleibt eigentlich WAN (nicht automatisch) und daher können alle anderen Regeln (LAN, DMZ etc.) ganz normal mit Gateway "*" (default) angelegt werden. Eigentlich muss nur das VoIP_LAN->VoIP_WAN fix in der Regel konfiguriert werden und ein dazu passendes NAT existieren (mit static port).
Wie das aber im Speziellen Fall bei inogy aussieht, das kann ich nicht wissen, daher besser nochmal genau nachfragen, denn wenn die VoIP Verbindung augenscheinlich über WAN auch aufgebaut werden kann, verstehe ich das ganze Theater mit extra VLAN nicht.
-
@JeGr
Danke für die Erklärung! Das hilft. Allerdings funktioniert das hier nur mit der LAN-Regel für die VOIP-Ports mit GW=WAN und die Outbound-Regel auch mit WAN als IF.
Regel VOIP-Ports via VOIP-GW macht nur ausgehend Gespräche möglich (Tonübertragung).
Die Einstellung der Outbound-Regel ist hier egal, Interface WAN, LAN oder VOIP, keine Änderung.
Nur wenn ich die LAN-Regel & die Outbound-Regel mit WAN anlege, funktioniert alles.
Allerdings habe ich netcologne, nicht innogy. Das Prinzip ist denke ich ähnlich. Mir gehts hier ums Gesamtverständnis, VLANs sind neu für mich.
Beim Packet-Capture laufen die Verbindungen richtig über das VOIP, nicht via PPPOE.
Ach so, die Fritz hat in den Einstellungen für VOIP auch VLAN 20 eingetragen.
Ich denke, daß diese Einstellung dazu beiträgt, daß die Pakete richtig reisen.
Daher ist für mich jetzt erstmal alles gut hier. Ich weiß etwas mehr von der Materie als noch vor einer Woche. Das ist schonmal ein gutes Ergebnis. -
Hab den Beitrag hier gesehen und stehe gerade vor dem gleichen Problem. Ebenfalls NetCologne.
Ich habe 2 Schnittstellen WAN_Daten (VLAN 10) und WAN_VoIP (VLAN 20) angelegt. Beide erhalten eine IP-Adresse vom Provider.
Intern habe ich ebenfalls ein LAN (VLAN 1) und LAN_VoIP (VLAN 20).Internet funktioniert und das IP-Telefon hat eine Adresse im 20er Netz.
Was mir jetzt noch nicht ganz klar geworden ist, sind die benötigten (oder eben auch nicht) Regeln in der Firewall...
Ich habe eine Regel definiert:
ERLAUBE alles IPv4 von LAN_VoIP nach WAN_VoIP mit GW WAN_VoIP_DHCP.
Außerdem habe ich eine Regel Outbound NAT:
Für Schnittstelle WAN_VoIP statischer Port auf Schnittstellenadresse für alle Protokolle IPv4 aus 192.168.20.0/24 (VLAN 20)...Aber noch connected sich mein IP-Phone nicht...?!?
-
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
Ich habe 2 Schnittstellen WAN_Daten (VLAN 10) und WAN_VoIP (VLAN 20) angelegt. Beide erhalten eine IP-Adresse vom Provider.
Intern habe ich ebenfalls ein LAN (VLAN 1) und LAN_VoIP (VLAN 20)Oh das klingt falsch. Du kannst doch nicht 2 VLANs mit gleicher ID aber mit anderem Zweck/Interface auf der Sense auflegen? Das führt doch zu Verwirrung :)
Aber noch connected sich mein IP-Phone nicht...?!?
Dann gibt es andere Probleme denn der Connect oder nicht, spielt noch nicht wirklich mit VoIP/Static Port zusammen. Dann klappt was am Anschluß noch grundlegend nicht, denn static port kommt erst ins Spiel wenn Anrufe wirklich reinkommen, die Anmeldung an SIP klappt meistens auch ohne auch wenns holpern kann.
-
Jetzt bin ich irgendwie ausgestiegen...?!?
Wieso mit gleicher ID?
Netcologne verlangt Daten auf VLAN 10 und VoIP auf VLAN 20.
Erstere habe ich als PPPoE angelegt, zweite als DHCP. Das ist doch auch genau das, was oben auch beschrieben wurde, nur mit VLAN 132 und 232 bzw. bei igor als
WAN: PPPOE via em1.10 (VLAN 10)
VOIP: DHCP via em1.20 (VLAN20)Genau so ist es bei mir auch eingerichtet...
-
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
Ich habe 2 Schnittstellen WAN_Daten (VLAN 10) und WAN_VoIP (VLAN 20) angelegt. Beide erhalten eine IP-Adresse vom Provider.
Intern habe ich ebenfalls ein LAN (VLAN 1) und LAN_VoIP (VLAN 20).Demnach haben doch WAN_VoIP und LAN_VoIP dieselbe VLAN ID.
ERLAUBE alles IPv4 von LAN_VoIP nach WAN_VoIP mit GW WAN_VoIP_DHCP.
"WAN_VoIP" ist lediglich das Subnetz, in dem sich das Interface befindet. Darin befindet sich aber wohl nicht das gewünschte Ziel.
Wenn das Ziel unbekannt ist, musst du "any" dafür angeben. -
Ach so meinst Du das mit gleiche ID...
Aber es sind ja unterschiedliche Netze: WAN bekommt von Netcologne 'ne 10.x.y.z und intern habe ich 'ne 192.168.10...Ok, das mit der Regel ist ein Argument, die sollte ich mal ändern...
-
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
Aber es sind ja unterschiedliche Netze: WAN bekommt von Netcologne 'ne 10.x.y.z und intern habe ich 'ne 192.168.10...
Du meinst, unterschiedliche Interfaces / Netzwerksegmente.
Ja, sollte eigentlich gehen, aber ich denke, das hat @JeGr gemeint. -
Ok, ich hab - zur besseren Unterscheidung, da gebe ich ja Recht - die VLANs intern jetzt auf 11 und 12 geändert...
Mein IP-Phone bekommt jetzt die 192.168.11.20 für Daten sowie die 192.168.12.20 für VoIP. Beide kann ich anpingen.
Ich kann auf dem Phone-Browser surfen, Namensauflösung, etc funktioniert.Aber:
- der PC am PC Port bekommt immer noch eine 192.168.10er Adresse, sollte aber - laut Konfiguration - eine 192.168.199er (Gast-Netz) Adresse erhalten.
- Das SIP-Konto für NetCologne wird nicht registriert...
-
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
der PC am PC Port bekommt immer noch eine 192.168.10er Adresse, sollte aber - laut Konfiguration - eine 192.168.199er (Gast-Netz) Adresse erhalten.
Hast du sie erneuert und bekommt er diese wirklich, oder hat er die eben noch. Wenn du da nicht selbst aktiv wirst, behält er die DHCP IP solange als das Lease gültig ist.
Von diesem Gast-Netz hattest du übrigens bislang noch nichts verraten. Ist das ein eigenes Interface, an dem der PC angeschlossen ist?
Und welche Konfiguration sprichst du oben an?Das SIP-Konto für NetCologne wird nicht registriert...
Dafür sind andere Leute zuständig.
-
Nein, ich habe alle Leases erneuert...;-)
Stimmt, da hast Du Recht, falsches Forum.
Ich hatte parallel im anderen Forum die Frage bezüglich des Gast-Netzwerkes an dem IP-Phone gestellt... -
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
Stimmt, da hast Du Recht, falsches Forum.
Es gibt schon kompetente Leute hier, allerdings gehör ich da nicht dazu.
-
@volvog said in Dual WAN (DHCP + VLAN) mit einer physikalischen NIC:
Das SIP-Konto für NetCologne wird nicht registriert...
SIP Konto worauf? Am PC? am IP Phone?
Ansonsten wärs ggf. noch die Frage wohin der sich verbindet und ob diese Verbindung dann sauber über das WAN_VOIP läuft und nicht versehentlich übers normale, das hört sich ein wenig so an. -
Ja, SIP-Konto auf dem IP-Phone.
Das weiß ich eben noch nicht. Denke, ich muss mal den Wireshark anwerfen und schauen, was da eigentlich genau passiert.