dyn-DNS, ULAs, NPTv6, IPv6 firewall, ("dropped by ingress filter")

[roell.f]

hallo forum,

in der firewall hatte ich in der vergangenheit einige IPv6-forwarding-regeln erfolgreich eingerichtet, die aber seit kurzem nicht mehr funktionieren. ein trace mit

Code: Alles auswählen

trace # IPv6-firewall

sagt "dropped by ingress filter".

im beitrag kam die meldung wegen einer fehlden IPv6-default-route. bei mir fehlt diese jedoch nicht:

IPv6-routing-tabelle.png

wieso kommt die meldung trotzdem?

beste grüße
frank

[backslash]

Hi roell.f

"dropped by ingress filter" kommt dann, wenn die Route zur Quelladresse des Pakets nicht auf das Interface zeigt, auf dem das Paket empfangen wurde (steht aber auch schin in dem von dir verlinkten Beitrag)...
Eine genauere Antwort ist ohne genauere Angaben deinerseits nicht möglich. Es fehlt die "effektive" Routing-Tabelle. Die bekommst du, wenn du auf dme CLI

Code: Alles auswählen

show ipv6-fib

eingibst.

Desweiteren wäre ein ipv6-router- und ipv6-firewall-trace, der das Problem zeigt, hilfreich - wieder auf dem CLI:

Code: Alles auswählen

trace # ipv6-router ipv6-firewall

Im Allgemeinen gilt aber: die Firewall hat Recht... und du hat einen Fehler in deiner Konfig oder deinem Netzaufbau

Ansonsten gilt bei

in der firewall hatte ich in der vergangenheit einige IPv6-forwarding-regeln erfolgreich eingerichtet, die aber seit kurzem nicht mehr funktionieren.

also bei "ich habe nichts geändert" der Klassiker: überlege dir ganz genau, was du nicht geändert hast und mache das rückgängig...

Gruß
Backslash

[roell.f]

hallo backslash,

also bei "ich habe nichts geändert" der Klassiker: überlege dir ganz genau, was du nicht geändert hast und mache das rückgängig...

an der IPv6-firewall (kurz: FW) hatte ich auch nichts geändert, aber an anderer stelle - was wohl anpassungen an der FW erforderlich gemacht hätte. diese "FW-wirksamen" änderungen habe ich jetzt alle rückgängig gemacht und siehe da: meine alten FW-regeln funktionieren wieder.

anschließend habe ich zu den präfix-options meinen pseudo-ULA-präfix (2001:db8:f2a1::/64) hinzugefügt:

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" "2001:db8:f2a1::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "INTRANET" "::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "INTERNET" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No

ergebnis, die FW lässt

1. eingehenden IPv6-verkehr wie gewünscht durch.
2. ausgehenden IPv6-verkehr nur durch, wenn er von einer GUA kommt (z.B. bei ssh mit parameter "-b" zu erzwingen).
   
   ein "trace + IPv6-firewall" zeigt, dass der ULA-verkehr mangels NPTv6-konfiguration stecken bleibt.

also zu NPTv6 den ULA-päfix hinzugefügt:

Code: Alles auswählen

cd /Setup/IPv6/Firewall/NPTV6 
del *
#    Interface-Name    source-prefix                                mapped-prefix                              
#    ===============================================================-------------------------------------------
add "INTERNET" "2001:db8:f2a1::/56" {mapped-prefix} "::/56"

nun lässt die FW

1. ausgehenden verkehr durch, egal ob von einer ULA oder GUA stammend.
2. eingehenden GUA-verkehr (siehe unten: ...:9228) mapped die FW gemäß der NPTv6-konfiguration auf eine ULA:
   

   Code: Alles auswählen

   [IPv6-Firewall] 2025/05/20 15:28:46,177 [info] : 
   The packet below, received from INTERNET scope global
   Internet Protocol Version 6
     Payload length: 40
     Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
     Next header: TCP (6)
     Hop limit: 59
     Source: 2a01:170:114d:c:864c:ae3a:375f:8d32
     Destination: 2003:c4:872a:950c:20c:29ff:fe06:9228
   Transmission Control Protocol
     Source port: 36786
     Destination port: 22
     Sequence number: 1564081519
     Acknowledgement number: 0
     Header length: 40 bytes
     Code bits: SYN 
     Window size: 64800
     Checksum: 0xec4b
     Urgent pointer: 0
   matched inbound NPTv6 on INTERNET
     map destination to 2001:db8:f2a1:c:1ea3:29ff:fe06:9228
   matched FORWARDING rule ALLOW-VPN
   no matching conditions, test next rule
   matched FORWARDING rule DENY-ALL
   OK
   
   [IPv6-Router] 2025/05/20 15:28:46,177 [INTERNET (5)]
   IP packet, scope global, routing tag 0:
     IPv6: 2a01:170:114d:c:864c:ae3a:375f:8d32 -> 2003:c4:872a:950c:20c:29ff:fe06:9228, Payload-Len: 40
     TCP : 36786 -> 22, Flags: S, Seq: 1564081519, Ack: 0, Win: 64800, Payload-Len: 0
   --> Creating destination cache entry of type firewall forwarding
   --> Creating firewall mirror destination cache entry of type firewall forwarding for address 2a01:170:114d:c:864c:ae3a:375f:8d32 on interface INTRANET (2)
   --> Firewall: dropped/rejected
   

   mit der gemappten ULA geht es aber nicht weiter

ich hatte vermutet, dass es reicht, der FW zusätzlich die interface-ID (IID) der gemappten ULA hinzuzufügen:

Code: Alles auswählen

cd /Setup/IPv6/Firewall/Stations 
del *
#    Name                              Type                    Local-network     Remote-peer/local-host                                            Address/Prefix                             
#    ==================================-------------------------------------------------------------------------------------------------------------------------------------------------------
add "SRV1" {Type} Identifier {Local-network} "INTRANET" {Remote-peer/local-host} "" {Address/Prefix} "::20c:29ff:fe06:9228"
add "SRV1_NPTV6" {Type} Identifier {Local-network} "INTRANET" {Remote-peer/local-host} "" {Address/Prefix} "::1ea3:29ff:fe06:9228"

cd /Setup/IPv6/Firewall/Forwarding-Rules 
del *
#    Name                                  Action                                                            Services                                                          Source-Stations                                                   Destination-Stations                                              LB-Policy                         Flags                                             Prio  Src-Tag    Rtg-tag  Comment                                                         
#    ======================================------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add "SRV1_HTTP+SSH" {Action} "ACCEPT" {Services} "HTTP, HTTPS, SSH" {Source-Stations} "ANYHOST" {Destination-Stations} "SRV1, SRV1_NPTV6" {LB-Policy} "" {Flags} none {Prio} 0 {Src-Tag} 0 {Rtg-tag} 0 {Comment} ""

aber das funktionierte nicht.

wie konfiguriert man die FW richtig, wenn NPTv6 im spiel ist, oder gibt es keine bessere lösung als diese?

warum mapped die FW eingehenden verkehr überhaupt von einer GUA via NPTv6 auf eine ULA? das ziel besitzt doch eine GUA und wäre dank ihr direkt erreichbar - oder?

beste grüße
frank

[backslash]

Hi roell.f

ich hatte vermutet, dass es reicht, der FW zusätzlich die interface-ID (IID) der gemappten ULA hinzuzufügen:

aus dem Bauch heraus würde ich sagen, das müßte funktionieren...

was sagt den ein "show ipv6-filter"? Das zeigt, welche Filter aus den Regeln angelegt werden - und nur das ist maßgeblich...

aber warum so kompliziert... Dein Server hat doch in deinem LAN immer die gleiche Adresse. Da kannst du doch einfach ein passedes Stationsobjekt mit der Adresse "2001:db8:f2a1:c29ff:fe06:9228" erstellen...

Gruß
Backslash

[roell.f]

hallo backslash,

um alle in frage kommenden fälle im hinblick auf die FW-regeln durchzutesten habe ich alle überhaupt auftretenden IPv6-adressen durchvariert und die nachstehenden stationsobjete angelegt.

dass die varianten e) und f) nicht funktionieren, weil dabei aus den ULAs abgeleitet WAN-adressen verwendet werden, hatte ich erwartet.

Dein Server hat doch in deinem LAN immer die gleiche Adresse. Da kannst du doch einfach ein passedes Stationsobjekt mit der Adresse "2001:db8:f2a1:c29ff:fe06:9228" erstellen...

die adresse ...... hatte ich auch schon erfolgs zwar nicht als komplette adresse sondern als interface-ID probiert. grund: s.o. "variante e) und f)." am besten man verwendet b).

ich habe also nun folgendes konfiguriert:

Code: Alles auswählen

# Stations-Objekte
#
# SRV1: server 1
# IID:  Host-Identifier / Interface-ID
# ADR:  IP-Adresse

a) SRV1_GUA_ADR       2003:c4:872a:950c:20c:29ff:fe06:9228
b) SRV1_GUA_IID                       ::20c:29ff:fe06:9228

c) SRV1_ULA_LAN_ADR     2001:db8:f2a1:c:20c:29ff:fe06:9228
d) SRV1_ULA_LAN_IID     identisch zu b)

e) SRV1_ULA_WAN_ADR  2003:c4:872a:950c:e574:29ff:fe06:9228
f) SRV1_ULA_WAN_IID                  ::e574:29ff:fe06:9228

g) SRV1_MAC                              00:0c:29:06:92:28

Code: Alles auswählen

# IPv6-Forwarding-Regeln
#
# GUA: to SRV1_GUA_ADR       2003:c4:872a:950c:20c:29ff:fe06:9228
# ULA: to SRV1_ULA_WAN_ADR  2003:c4:872a:950c:e574:29ff:fe06:9228
#
# ja:   ssh verbindung kommt zustande
# nein: connection refused

a) SRV1_SSH_GUA_ADR

  Dst: 2003:c4:872a:950c:20c:29ff:fe06:9228/128 22-22
  GUA: nein
  ULA: nein

Code: Alles auswählen

b) SRV1_SSH_GUA_IID

  Dst: 2003:c4:872a:950c:20c:29ff:fe06:9228/128 22-22 (LAN ifc INTRANET)
  Dst: 2001:db8:f2a1:c:20c:29ff:fe06:9228/128 22-22 (LAN ifc INTRANET)
  GUA: nein
  ULA: ja

Code: Alles auswählen

c) SRV1_SSH_ULA_LAN_ADR

  Dst: 2001:db8:f2a1:c:20c:29ff:fe06:9228/128 22-22
  GUA: nein
  ULA: ja

Code: Alles auswählen

d) SRV1_SSH_ULA_LAN_IID     identisch zu b)

Code: Alles auswählen

e) SRV1_SSH_ULA_WAN_ADR

  Dst: 2003:c4:872a:950c:e574:29ff:fe06:9228/128 22-22
  GUA: nein
  ULA: nein

  unsinn, weil WAN-adresse.

Code: Alles auswählen

f) SRV1_SSH_ULA_WAN_IID

  Dst: 2003:c4:872a:950c:e574:29ff:fe06:9228/128 22-22 (LAN ifc INTRANET)
  Dst: 2001:db8:f2a1:c:e574:29ff:fe06:9228/128 22-22 (LAN ifc INTRANET)
  GUA: nein
  ULA: nein

  unsinn, weil IID von WAN-adresse.

Code: Alles auswählen

g) SRV1_SSH_MAC            00:0c:29:06:92:28

  Dst: es wird kein IPv6-filter erzeugt.
  GUA: nein
  ULA: nein

wieso wird bei g) kein IPv6-filter erzeugt?

fazit:

IIDs erzeugen FW-regeln für alle präfixe, die auf dem jeweiligen interface (hier: 2 stück auf INTRANET) liegen.

forwarding-regeln auf basis von GUA-stationsobjekten bleiben wirkungslos, vermutlich weil NPTv6 den verkehr mit ziel GUA auf ULAs umsetzt. richtig?

ULA-stationsobjekte funktionieren, solange man als ziel die WAN-adresse angibt, die zur jeweiligen ULA passt.

diese WAN-adressen können die typischen dynv6-dienste aber nicht aus einem präfix und den MAC-adressen ableiten. statt dessen muss jeder host seine WAN-adresse nach jedem präfix-wechsel bei einem dienst w.z.B. ifconfig.me erfragen, um die komplette IPv6-adressesie dann an den dyn-DNS-dienst zu übergeben.

gibt es eine möglichkeit die umsetzung für GUAs, welche auch im LAN existieren (fälle a) und b) ), zu verhindern?

beste grüße
frank

[backslash]

Hi roell.f

wieso wird bei g) kein IPv6-filter erzeugt?

weil MAC-Adressen als Destination nicht erlaubt sind. Das sagt dir auch das CLI, wenn du eine solche dort Regel anlegst. Desweiteren wird das alle 60 Minuten im Syslog vermerkt ("MAC Addresses in the firewall rule's destination column are not supported.")...

IIDs erzeugen FW-regeln für alle präfixe, die auf dem jeweiligen interface (hier: 2 stück auf INTRANET) liegen.

das ist auch das, was ich erwartet hätte. Darum müßte es mit dem Identifier auch funktionieren...

forwarding-regeln auf basis von GUA-stationsobjekten bleiben wirkungslos, vermutlich weil NPTv6 den verkehr mit ziel GUA auf ULAs umsetzt. richtig?

das passiert aber nur, wenn der ULA-Prefix auf den GUA-Prefix gemappt wird, denn das ist doppeldeutig und dann wird NPT bevorzugt.

daraus ergibt sich auch direkt die Antwort auf die Frage

gibt es eine möglichkeit die umsetzung für GUAs, welche auch im LAN existieren (fälle a) und b) ), zu verhindern?

Es darf keine "Konflikte" beim NTPv6 geben... d.h. du mußt dafüre sorgen, daß der ULA-Prefix auf einen anderen öffentlichen Prefix gemappt wird. Dann kommt auch wieder das /64 in der NTPv6-Tabelle zum tragen - mit dem Nachteil, daß der Prüfsummenkorrekturteil in den Indentifier gemappt wird. Dazu trägst du als gemappten Prefx halt nicht ::/64 ein, sondern z.B. 0:0:0:X::/64 - mit X als "Subnet-ID". Diese Subnet-ID muß natürlich zu dem vom Provider delegierten Prefix passen...

Gruß
Backslash

[roell.f]

hallo backslash,

Dazu trägst du als gemappten Prefx halt nicht ::/64 ein, sondern z.B. 0:0:0:X::/64 - mit X als "Subnet-ID". Diese Subnet-ID muß natürlich zu dem vom Provider delegierten Prefix passen...

das habe ich für die ZENTRALE so gemacht:

Code: Alles auswählen

cd /Setup/IPv6/Router-Advertisement/Prefix-Options 
del *
#    Interface-Name    Prefix                                       Subnet-ID            Adv.-OnLink  Adv.-Autonomous  PD-Source         Adv.-Pref.-Lifetime  Adv.-Valid-Lifetime  DecrementLifetimes       
#    ===============================================================----------------------------------------------------------------------------------------------------------------------------------------
add "INTRANET" "2001:db8:f2a1::/64" {Subnet-ID} "2c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No
add "INTRANET" "0:0:0:c::/64" {Subnet-ID} "c" {Adv.-OnLink} Yes {Adv.-Autonomous} Yes {PD-Source} "INTERNET" {Adv.-Pref.-Lifetime} 604800 {Adv.-Valid-Lifetime} 2592000 {DecrementLifetimes} No

Code: Alles auswählen

cd /Setup/IPv6/Firewall/Stations 
del *
#    Name                              Type                    Local-network     Remote-peer/local-host                                            Address/Prefix                             
#    ==================================-------------------------------------------------------------------------------------------------------------------------------------------------------
add "SRV1_GUA_IID" {Type} Identifier {Local-network} "INTRANET" {Remote-peer/local-host} "" {Address/Prefix} "::20c:29ff:fe06:9228"

Code: Alles auswählen

cd /Setup/IPv6/Firewall/Forwarding-Rules 
del *
#    Name                                  Action                                                            Services                                                          Source-Stations                                                   Destination-Stations                                              LB-Policy                         Flags                                             Prio  Src-Tag    Rtg-tag  Comment                                                         
#    ======================================------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add "SRV1_SSH_GUA_IID" {Action} "ACCEPT" {Services} "SSH" {Source-Stations} "ANYHOST" {Destination-Stations} "SRV1_GUA_IID" {LB-Policy} "" {Flags} none {Prio} 0 {Src-Tag} 0 {Rtg-tag} 0 {Comment} ""

Code: Alles auswählen

cd /Setup/IPv6/Firewall/NPTV6 
del *
#    Interface-Name    source-prefix                                mapped-prefix                              
#    ===============================================================-------------------------------------------
add "INTERNET" "2001:db8:f2a1:2c::/64" {mapped-prefix} "0:0:0:2c::/64"

nun funktioniert die gesamte kette:

1. die aktionstabelle trägt den vom provider zugewiesen präfix beim dynDNS-dienst (z.B. dynv6.com) ein.
2. der dyn-DNS-dienst berechnet aus den MAC-adressen via EUI-64 die interface IDs und hängt dies an den präfix an (d.h. kompliziere NPTv6-mappings sind dabei nicht im spiel).
3. mit so gebildeten IPv6-adressen sind die eigenen dienste im web erreichbar und gleichzeitig sind im LAN statische ULAs (oder pseudo-ULAs aus dem doku-bereich "2001:db8::") verwendbar.

ich möchte noch anregen, das LANCOM aus diesem thread eine anleitung für den dieser diskussion zugrundeliegenden use-case herstellt.

backslash, herzlichen dank für deine hilfe!

beste grüße
frank

[roell.f]

hallo forum,

die obenstehende konfiguration ist unvollständig:

zwar kommt für das (ULA-) source-netz mit subnet-ID "c2" z.B. mit

Code: Alles auswählen

ssh -b 2001:db8:f2a1:2c:{IID-zentrale} user@2a01:dead:beef:c:{IID-filiale-1}

eine verbindung zustande, nicht aber für das (GUA-) source-netz mit subnet-ID "c" z.B. mit

Code: Alles auswählen

ssh -b 2003:dead:beef:ff0c:{IID-zentrale} user@2a01:dead:beef:c:{IID-filiale-1}

die routing-tabelle der ZENTRALE:

Code: Alles auswählen

cd /Setup/IPv6/Router/Routing-Table 
del *
#    Prefix                                       Rtg-tag  Admin-Distance  Peer-or-IPv6                                                       Active   Comment                                                         
#    ======================================================================--------------------------------------------------------------------------------------------------------------------------------------------
add "2a01:dead:beef:c::/64" 0 0 {Peer-or-IPv6} "FILIALE-1" {Active} Yes {Comment} "VPN --> FILIALE-1"

halte ich für vollständig, weil die filiale-1 statisch versorgt ist und nur das subnetz "c" besitzt.

die routing-tabelle der FILIALE-1:

Code: Alles auswählen

cd /Setup/IPv6/Router/Routing-Table 
del *
#    Prefix                                       Rtg-tag  Admin-Distance  Peer-or-IPv6                                                       Active   Comment                                                         
#    ======================================================================--------------------------------------------------------------------------------------------------------------------------------------------
add "2001:db8:f2a1:2c::/64" 0 0 {Peer-or-IPv6} "ZENTRALE" {Active} Yes {Comment} "VPN --> ZENTRALE"

halte ich für unvollständig, weil die zentrale neben dem subnetz "2c" auch noch das subnetz "c" besitzt.

da die zentrale dynamische versorgt ist, weiß ich nicht welchen präfix der fehlende routing-eintrag haben muss. wie lässt sich dies problem lösen?

2025-06-11 12:27, nachtrag:

ich vermute: weil der provider den IPv6-präfix der zentrale gelegentlich ändert, müsste auch die zentrale bei jeder änderung die filiale benachrichtigen, damit die filiale mit dem neuen präfix ihre routing-tabelle aktualisieren kann.

ist das ein einsatzzweck von Open Shortest Path First (OSPF, bzw. bei IPv6 OSPFv3)?

wenn ja, wie ist das mit LCOS zu konfigurieren?

beste grüße
frank

[backslash]

Hi

ist das ein einsatzzweck von Open Shortest Path First (OSPF, bzw. bei IPv6 OSPFv3)?

hier lautet das Stichwort eher IKEv2-Routing...

Gruß
Backslash

[roell.f]

hallo backslash,

hier lautet das Stichwort eher IKEv2-Routing...

meinst du damit den pfad "VPN > IKEv2/IPSec > Erweitete Einstellungen > IPv6-Routing"?

Code: Alles auswählen

cd /Setup/VPN/IKEv2/Routing/IPv6 
del *
#    Name                             Networks                                                                                                                                                                                                                                                        Send-IKE-CFG-Addr 
#    =================================================================================================================================================================================================================================================================================================------------------

muss das sowohl auf der seite (mit den dynamischen präfixen) "ZENTRALE" als auch der seite "FILIALE-1" konfigurierte werden?

unter IKEv2, IPv6-Routing steht, was unter netzwerk eingetragen werden kann. aber die IPv6-adresse ist ja nicht bekannt und als schnittstelle "INTERNET" einzutragen funktionierte nicht.

weil ich auch mit google nicht weiter komme, bitte ich dich (oder gerne einen anderen kundigen ) um mehr details.

beste grüße
frank

[backslash]

Hi roell.f,

meinst du damit den pfad "VPN > IKEv2/IPSec > Erweitete Einstellungen > IPv6-Routing"?

ja, genau..

muss das sowohl auf der seite (mit den dynamischen präfixen) "ZENTRALE" als auch der seite "FILIALE-1" konfigurierte werden?

also zumindest die Zentrale muß ihre (dynmasichen) Prefixe an die Filiale melden. Sinnvoll ist es abar das in beide Richtungen zu konfigurieren.

Wichtig ist, daß die IPv6-Routing Einträge in der Verbindung verlinkt werden (VPN -> IKEv2/IPSec -> Verbindungsliste -> (FILIALE/ZENTRALE) -> IKE-Config-Mode -> Routing). In der Zentrale stellts du den Wert für IKE-CFG auf "Server" und in der Filiale auf "Client"

Damit können in Filiale und Zentrale die statischen Einträge aus der Routing-Tabelle entfernt werden. In der Filiale muß dann noch das Häkchen bei Kommunikation -> Gegenstellen -> Gegenstelle auch ohne Route aufbauen gesetzt werden

unter IKEv2, IPv6-Routing steht, was unter netzwerk eingetragen werden kann. aber die IPv6-adresse ist ja nicht bekannt und als schnittstelle "INTERNET" einzutragen funktionierte nicht.

Die Schnittelle muß "INTRANET" lauten - also das LAN der Zentrale (und nicht die Internet-Verbindung)

Damit das mit dem dynamischen Routing überhaupt funktioniert, muß als Regelsatz ANY <-> ANY (vordefiniert: "RAS-WITH-NETWORK-SELECTION") verwendet werden (und zwar auf beiden Seiten)

ich hab das letzendlich selbst noch nie konfiguriert, sollte aber so funktionieren

Gruß
Backsalsh

[roell.f]

hallo backslash

Die Schnittelle muß "INTRANET" lauten - also das LAN der Zentrale (und nicht die Internet-Verbindung)

ok, zuerst das IKEv2/Routing definieren, das ist gleich für:

ZENTRALE und FILIALE-1 mit {Networks} "INTRANET"

Code: Alles auswählen

cd /Setup/VPN/IKEv2/Routing/IPv6 
del *
#    Name                             Networks                                                                                                                                                                                                                                                        Send-IKE-CFG-Addr 
#    =================================================================================================================================================================================================================================================================================================------------------
add "IKEV2.ROUTE.INTRANET.V6" "INTRANET" {Send-IKE-CFG-Addr} No

Damit das mit dem dynamischen Routing überhaupt funktioniert, muß als Regelsatz ANY <-> ANY (vordefiniert: "RAS-WITH-NETWORK-SELECTION") verwendet werden (und zwar auf beiden Seiten)

das war in der tat so voreingestellt.

Code: Alles auswählen

cd /Setup/VPN/Networks/IPv6-Rules 
del *
#    Name                             Local-Networks                                                                                                                   Remote-Networks                                                                                                                
#    =================================----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add "RAS-WITH-CONFIG-PAYLOAD" {Local-Networks} "::/0" {Remote-Networks} "::/128"
add "RAS-WITH-NETWORK-SELECTION" {Local-Networks} "::/0" {Remote-Networks} "::/0"

also zumindest die Zentrale muß ihre (dynmasichen) Prefixe an die Filiale melden. Sinnvoll ist es abar das in beide Richtungen zu konfigurieren.

Wichtig ist, daß die IPv6-Routing Einträge in der Verbindung verlinkt werden (VPN -> IKEv2/IPSec -> Verbindungsliste -> (FILIALE/ZENTRALE) -> IKE-Config-Mode -> Routing). In der Zentrale stellts du den Wert für IKE-CFG auf "Server" und in der Filiale auf "Client"

also: nach der definition des IKEv2/Routing nun die IKEv2/Peers definieren:

ZENTRALE, mit {IKE-CFG} Server und {IPv6-Rules} "RAS-WITH-NETWORK-SELECTION" und {Routing} "IKEV2.ROUTE.INTRANET.V6"

Code: Alles auswählen

cd /Setup/VPN/IKEv2/Peers 
del *
#    Peer                  Active   SH-Time     Remote-Gateway                                                    Rtg-tag     Encryption            Authentication        General               Lifetimes             IKE-CFG     IPv4-CFG-Pool     IPv6-CFG-Pool     CFG-Client-Profile  Split-DNS-Profile  Auto-IP-Profile   Rule-creation  IPv4-Rules                                                       IPv6-Rules                                                       Routing                          RADIUS-Authorization             RADIUS-Accounting                IPv6              HSVPN             Comment                                                        
#    ======================-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add "FILIALE-1" {Active} Yes {SH-Time} 0 {Remote-Gateway} "0.0.0.0" {Rtg-tag} 0 {Encryption} "DEFAULT" {Authentication} "FILIALE-1" {General} "DEFAULT" {Lifetimes} "DEFAULT" {IKE-CFG} Server {IPv4-CFG-Pool} "" {IPv6-CFG-Pool} "" {CFG-Client-Profile} "" {Split-DNS-Profile} "" {Auto-IP-Profile} "" {Rule-creation} manually {IPv4-Rules} "RAS-WITH-NETWORK-SELECTION" {IPv6-Rules} "RAS-WITH-NETWORK-SELECTION" {Routing} "IKEV2.ROUTE.INTRANET.V6" {RADIUS-Authorization} "" {RADIUS-Accounting} "" {IPv6} "DEFAULT" {HSVPN} "" {Comment} ""

FILIALE-1, mit {IKE-CFG} Client und {IPv6-Rules} "RAS-WITH-NETWORK-SELECTION" und {Routing} "IKEV2.ROUTE.INTRANET.V6"

Code: Alles auswählen

cd /Setup/VPN/IKEv2/Peers 
del *
#    Peer                  Active   SH-Time     Remote-Gateway                                                    Rtg-tag     Encryption            Authentication        General               Lifetimes             IKE-CFG     IPv4-CFG-Pool     IPv6-CFG-Pool     CFG-Client-Profile  Split-DNS-Profile  Auto-IP-Profile   Rule-creation  IPv4-Rules                                                       IPv6-Rules                                                       Routing                          RADIUS-Authorization             RADIUS-Accounting                IPv6              HSVPN             Comment                                                        
#    ======================-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
add "ZENTRALE" {Active} Yes {SH-Time} 9999 {Remote-Gateway} "lc-1793va-01.zentrale.org" {Rtg-tag} 0 {Encryption} "DEFAULT" {Authentication} "ZENTRALE" {General} "DEFAULT" {Lifetimes} "DEFAULT" {IKE-CFG} Client {IPv4-CFG-Pool} "" {IPv6-CFG-Pool} "" {CFG-Client-Profile} "" {Split-DNS-Profile} "" {Auto-IP-Profile} "" {Rule-creation} manually {IPv4-Rules} "RAS-WITH-NETWORK-SELECTION" {IPv6-Rules} "RAS-WITH-NETWORK-SELECTION" {Routing} "IKEV2.ROUTE.INTRANET.V6" {RADIUS-Authorization} "" {RADIUS-Accounting} "" {IPv6} "DEFAULT" {HSVPN} "" {Comment} ""

Damit können in Filiale und Zentrale die statischen Einträge aus der Routing-Tabelle entfernt werden.

habe ich gemacht.

In der Filiale muß dann noch das Häkchen bei Kommunikation -> Gegenstellen -> Gegenstelle auch ohne Route aufbauen gesetzt werden

FILIALE-1

Code: Alles auswählen

set /Setup/WAN/Keepalive-without-Route Yes

der VPN-verbindunsgaufbau scheitert mit der fehlermeldung:

Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindunsgaufbau) [0x1104]

etwas scheint noch zu fehlen, aber was?

beste grüße
frank

[backslash]

Hi roell.f

Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindunsgaufbau) [0x1104]

die Meldung kommt eigentlich nur bei IKEv1 - und dann auch nur, wenn bei der Gegenstelle "dynamic VPN" aktiviert ist.... Das sollest du bei IKEv2 gar nicht bekommen...

am Ende hilft vermutlich nur Debugging mittekls VPN-Status-Trace...

Gruß
Backslash

[roell.f]

hallo backslash,

die FILIALE-1 meldet keine fehler sondern nur

Protokollverhandlung mit ZENTRALE (über INTERNET)

nur die ZENTRALE meldet "... 0x1104 ..."

ich gebe der kürze wegen ausschließlich die fehler- und die success-meldungen von 2 zyklen wieder.

ZENTRALE, trace # VPN-Status

Code: Alles auswählen

+Authentication successful
+Authentication successful
  ...
+Authentication successful
+Authentication successful
Transport builder result for FILIALE-1: success
VPN: Error: IFC-I-No-PPP-table-entry-matched (0x1104) for FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43 IKEv2)
+Authentication successful
  +AUTHENTICATION_FAILED (ERROR) -> current request fails
-Received notificaion error(s): NOTIFY(AUTHENTICATION_FAILED) (comchan 22)
VPN: policy manager error indication: FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43), cause: 8458
VPN: Error: IKE-I-IKE-key-mismatch (0x210a) for FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43 IKEv2)
+Authentication successful
+Authentication successful
  ...
+Authentication successful
+Authentication successful
Transport builder result for FILIALE-1: success
VPN: Error: IFC-I-No-PPP-table-entry-matched (0x1104) for FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43 IKEv2)
  +AUTHENTICATION_FAILED (ERROR) -> current request fails
-Received notificaion error(s): NOTIFY(AUTHENTICATION_FAILED) (comchan 22)
VPN: policy manager error indication: FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43), cause: 8458
VPN: Error: IKE-I-IKE-key-mismatch (0x210a) for FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43 IKEv2)
+Authentication successful
+Authentication successful
  ...
+Authentication successful
+Authentication successful

beste grüße
frank

[backslash]

Hi roell.f

intessant ist der Fehler

Code: Alles auswählen

Received notificaion error(s): NOTIFY(AUTHENTICATION_FAILED) (comchan 22)
VPN: policy manager error indication: FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43), cause: 8458
VPN: Error: IKE-I-IKE-key-mismatch (0x210a) for FILIALE-1 (2a01:dead:beef:0:a0:57ff:fe55:6c43 IKEv2)

(8458 = 0x210a)

Da meint die Zentrale, der preshared-Key würde nicht stimmen

Auch interssant ist, daß die Zentrale meint, sie wäre Initiator (dafür steht das "I" in "IKE-I-IKE-key-mismatch").
Das würde bedeuten, daß die Zentrale versucht, aktiv den Tunnel hochzuziehen, obwohl sie die IP-Adresse der Filiale nicht kennt ("0.0.0.0").
Das würde dann aber wenigstens etwas zum "Dynamic VPN" passen...

Du kannst ja mal in der Zentrale in der PPP-Tabelle einen Eintrag für die FILIALE aufnehmen (Username/Paßwort beliebig) und schauen, was dann so passiert.


Gruß
Backslash