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 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