FW10.40Rel, HSVPN und SIP-PBX Leitungen (2x 1783VAW)

[Fourty2]

Hallo zusammen,

falls man die obige Kombination verwenden möchte, um SIP-Leitungen auf einer per VPN Verbundenen zweiten Lancom zu registieren, geht das nur mit Trick 17:

- Router B (externe Leitung hier registriert), Netz 192.168.2.0/24, VLAN/ARF 1002
VPN-Route mit TAG 1002 auf 192.168.2.0/24
- Router A (mochte mit Router B telefonieren), Netz 192.168.1.0/24, VLAN/ARF 1001
VPN-Route mit TAG 1001 auf 192.168.1.0/24
- HSVPN-Tunnel mit (1001,1002)

Gibt man der SIP-PBX-Leitung (auf Router A) Routing-Tag 1002, passend zur VPN-Route, versucht das Routerchen A Namesauflösung auf @1002 - das geht natürlich im Netz 1001 schief. Umbiegen des DNS-Resolvers mit @1002 hilft nicht (vollständig).

Was nur geht ist:
- SIP-PBX-Leitung auf ARF-TAG des lokalen Netzes (hier 1001)
- zusätzlich IP-Route nach 192.168.2.0/24 @ 1001
- Passende Firewallregeln.. (z.B. auf Router B für Pakete mit @1001 für VoIP).

Denke, die SIP-PBX-Leitung bräuchte Quell- und Routing-Tags damit das "intuitiv" funktioniert.

Grüße,
Stefan

[Fourty2]

Das eigentlich Problem ist offenbar, daß die den HSVPN-Tunnel betreffenden Regeln "ACCEPT-VPN" benutzten.

In diesem Falle ist zwar das Netz hinter dem Router (Remote) sichtbar (192.68.2.1-192.168.2.253), der Router (Remote, 192.168.2.254) aber nicht. Im Firewall-Log des Routers (lokal) findet sich dann sowas:

Code: Alles auswählen

[Firewall] 2020/08/17 14:40:41,512
Packet matched rule AR_LAN-IE_(1002)=>LAN_INTRANET
DstIP: 192.168.1.254, SrcIP: 192.168.2.254, Len: 384, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 14552

test next filter (no matching condition)

[Firewall] 2020/08/17 14:40:41,513
Packet matched rule DT_ALL=>WAN_DENY-ALL
DstIP: 192.168.1.254, SrcIP: 192.168.2.254, Len: 384, DSCP: CS6 (0x30), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 14552

no route for 192.168.1.254@1002, packet rejected

Weitere Regeln beachten war nicht aktiv.
Schaltet man auf "ACCEPT" um, funktioniert es für das komplette Remote-Netz wie erwartet.
Keine Klimzüge nötig. Bug, würde ich mal vermuten.

Stefan

[backslash]

Hi Fourty2,

durch das HSVPN sind die Tags der beiden Seiten nicht mehr unabhängig voneinander und somit hast hier das Problem, daß du den Kontext wechseln mußt: Das Paket kommt mit Tag 1002 rein, soll aber die Adresse des Geräts im Netz mit Tag 1001 ansprechen.

Hier brauchst du entweder eine Regel, die das Paket umtaggt oder aber du nimmst im VCM des Routers A als Ziel-Adresse die Adresse des Routers B im Kontext 2002

Gruß
Backslash

[Fourty2]

Hallo backslash,

das ist klar. Hab auch schon beide Möglichkeiten (Umtaggen ausgehend / eingehend) auf beiden Routern durch. Beide zeigten so ihre individuellen Fallstricke.

Für mich war jetzt die beste Lösung ausgehend zu Taggen, wie auf der Default-Route, also Quell-Tag = Routing-Tag, dann ist es da durchgehend.

Das einzige Problem, was sich dadurch ergibt, ist, man braucht (eine) zusätzliche Route(n) im IP-Router, denn das VoIP möchte 'ne Extrawurst (bzw. benutzt die umtaggende Firewall-Regel nicht):

Anmerkung:
192.168.1.4 (Asterisk, Netz 1001) an 1783VAW hinter VPN (Ziel-Netz 1002)
Asterisk PBX-Leitung mußte auf Routing-Tag 1001, wg. DNS (sonst Leitungsfehler)

Code: Alles auswählen

[SIP-Verbindung] 2020/08/17 17:30:01,787 [SIP UDP Transport (192.168.1.4:5060)]: VCM user agent server proceeds with non-REGISTER request
[SIP-Packet] 2020/08/17 17:30:01,787 [Packet]:
Sending datagram (440 Bytes) from 192.168.2.254:5060 to 192.168.1.4:5060 using UDP (RtgTag 1001):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 192.168.1.4:5060;branch=z9hG4bKPja15fcf6b-fcf2-4664-bdc8-95c98d7522e4;received=192.168.1.4;rport=5060\r\n
From: <sip:*CALLERID*@gw-k9.***.de>;tag=befb3c5d-46ae-47d4-8f65-830680d71f8c\r\n
To: <sip:00170****@gw-k9.***.de>\r\n
Call-ID: e21b533d-012f-4c03-a418-4e2370b987af\r\n
CSeq: 8747 INVITE\r\n
User-Agent: LANCOM 1783VAW (over ISDN) 10.40.0210\r\n
Server: Lancom\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2020/08/17 17:30:01,795 [Packet]:
Sending datagram (495 Bytes) from 192.168.2.254:5060 to 192.168.1.4:5060 using UDP (RtgTag 1001):
SIP/2.0 500 Resource Reservation Failed\r\n
Via: SIP/2.0/UDP 192.168.1.4:5060;branch=z9hG4bKPja15fcf6b-fcf2-4664-bdc8-95c98d7522e4;received=192.168.1.4;rport=5060\r\n
From: <sip:*CALLERID*@gw-k9.***.de>;tag=befb3c5d-46ae-47d4-8f65-830680d71f8c\r\n
To: <sip:00170****@gw-k9.***.de>;tag=999649926-2035223587\r\n
Call-ID: e21b533d-012f-4c03-a418-4e2370b987af\r\n
CSeq: 8747 INVITE\r\n
User-Agent: LANCOM 1783VAW (over ISDN) 10.40.0210\r\n
Server: Lancom\r\n
Supported: replaces,timer\r\n
Content-Length: 0\r\n

Es gab dann natürlich erstmal nur eine Route im entfernten Router für 192.168.1.0/24 mit Routing-Tag 1002.
=> 500 Resource Reservation Failed

Aber gut. Funktioniert jetzt mit zusätzlicher Route für 192.168.1.0/24@1001.

Unabhängig davon ist die "ACCEPT-VPN" Regel (Übertragen; Nur wenn VPN-Route) kaputt.
Erkennung der VPN Strecke funktioniert nicht und läßt dann keine Pakete durch, also auf "ACCEPT" gestellt.
Es gibt auch Meldungen aus dem Router, a la "Session Recovery" aus dem "WAN" zwischen 192.168.2x <-> 192.168.1.x nicht erlaubt.

Grüße,
Stefan

[backslash]

Hi Fourty2,

Das einzige Problem, was sich dadurch ergibt, ist, man braucht (eine) zusätzliche Route(n) im IP-Router, denn das VoIP möchte 'ne Extrawurst (bzw. benutzt die umtaggende Firewall-Regel nicht):

Die IPv4-Firewall greift ja auch nur im Forwarding-Fall.... der VCM arbeitet aber im Gerät, d.h. es handelt sich um den Inbound- oder Outbound-Fall - und da greift Firewall halt nicht. Mit unterschiedlichen Routung-Tags könnte man zwar den einkommenden nTraffic u.U. umtaggen, weil er erst über den Forwarding-Zweig läuft, aber spätetens die Antworten des VCM würden "falsch" laufen, da sie nicht "zurückgetaggt" werden...

Selbst im IPv6, bei dem die Firewall ja Inbound- und Outbound-Zweig hat, ist ein Umtaggen in diesen Zweigen nicht voregsehen. Hier muß die Applikation (also der VCM) immer das korrekte Tag vorgeben

Gruß
Backslash