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

roell.f · Beitrag von **roell.f** » 13 Jun 2025, 14:32

hallo, backslash,

backslash hat geschrieben: 13 Jun 2025, 13:42 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.

ZENTRALE: kommunikation > protokolle > PPP-liste; zusätzlich IPv6-Routing angehakt

Code: Alles auswählen

cd /Setup/WAN/PPP 
del *
#    Peer              Authent.request             Authent-response            Key       Time  Try   Conf  Fail  Term  Username                                                          Rights         
#    ==================---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
...
add "FILIALE-1" {Authent.request} MS-CHAPv2,MS-CHAP,CHAP,PAP {Authent-response} MS-CHAPv2,MS-CHAP,CHAP,PAP {Key} "FILIALE-1.Pwd" {Time} 0 {Try} 5 {Conf} 10 {Fail} 5 {Term} 2 {Username} "FILIALE-1.Usr" {Rights} IP,IPv6

ZENTRALE, trace # VPN-Status, alle meldungen von 2 zyklen

Code: Alles auswählen

+Authentication successful
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x0204915FB1F552759F41E9A2304D09F3) removed from SADB
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x0204915FB1F552759F41E9A2304D09F3) entered to SADB
Request attributes:
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP4_DNS()
  INTERNAL_IP4_NBNS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
  INTERNAL_IP4_SUBNET()
  INTERNAL_IP6_SUBNET()
  INTERNAL_DNS_DOMAIN()
  -Acquiring addresses failed  -> abort

[VPN-Status] 2025/06/13 14:12:39,245
Peer FILIALE-1: Constructing an IKE_AUTH-RESPONSE for send
+Local-ID filiale-1@zentrale.org:USER_FQDN
+I use AUTH(PSK)

IKE_SA_INIT [responder] for peer FILIALE-1 initiator id filiale-1@zentrale.org, responder id filiale-1@zentrale.org
initiator cookie: 0x0204915FB1F55275, responder cookie: 0x9F41E9A2304D09F3
SA ISAKMP for peer FILIALE-1
 Encryption                    : AES-CBC-256
 Integrity                     : AUTH-HMAC-SHA-256
 IKE-DH-Group                  : 14
 PRF                           : PRF-HMAC-SHA-256
life time soft 06/14/2025 17:12:39 (in 97200 sec) / 0 kb
life time hard 06/14/2025 20:12:39 (in 108000 sec) / 0 kb
DPD: 31 sec
Negotiated: IKE_FRAGMENTATION IKEV2_FRAGMENTATION

NOTIFY(INTERNAL_ADDRESS_FAILURE)
CHILD_SA ('', '' ) removed from SADB
CHILD_SA ('', '' ) freed
Sending an IKE_AUTH-RESPONSE of 144 bytes (responder encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x0204915FB1F552759F41E9A2304D09F3, Message-ID 1

[VPN-Status] 2025/06/13 14:12:39,268
Peer FILIALE-1 [responder]: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x0204915FB1F552759F41E9A2304D09F3, Message-ID 2

[VPN-Status] 2025/06/13 14:12:39,268
Peer FILIALE-1: Constructing an INFORMATIONAL-RESPONSE for send
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x0204915FB1F552759F41E9A2304D09F3) removed from SADB
Sending an INFORMATIONAL-RESPONSE of 80 bytes (responder encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x0204915FB1F552759F41E9A2304D09F3, Message-ID 2

[VPN-Status] 2025/06/13 14:12:39,269
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x0204915FB1F552759F41E9A2304D09F3) freed

[VPN-Status] 2025/06/13 14:12:39,269
FILIALE-1: DISCONNECT-RESPONSE sent for handle 22

[VPN-Status] 2025/06/13 14:12:39,269
vpn-maps[22], remote: FILIALE-1, idle, static-name

[VPN-Status] 2025/06/13 14:12:40,405
Peer DEFAULT: Received an IKE_SA_INIT-REQUEST of 569 bytes
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x4DC0FD3816640E0F0000000000000000, Message-ID 0
Peer identified: DEFAULT
IKE_SA ('', '' IPSEC_IKE SPIs 0x4DC0FD3816640E0FC5CB040FD7F7EE80) entered to SADB
Received 5 notifications: 
  +REDIRECT_SUPPORTED (STATUS)
  +NAT_DETECTION_SOURCE_IP(0xAB589349A03F6BD62FE7350DC79BD33CCBF11E1B) (STATUS)
  +NAT_DETECTION_DESTINATION_IP(0x09E501DD13045155B69461D762D8269BD3396990) (STATUS)
  +IKEV2_FRAGMENTATION_SUPPORTED (STATUS)
  +DEVICE-ID(0x5C98A3B4E78DB800D3DE82B891E63196EFF796710EC3ECA725136291AFA2710A) (PRIVATE)
Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled
+IKE-SA:
  IKE-Proposal-1  (6 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256 PRF-HMAC-SHA1
    INTEG: HMAC-SHA-256 HMAC-SHA1
    DH   : 14
+Received KE-DH-Group 14 (2048 bits)

[VPN-Status] 2025/06/13 14:12:40,647
Peer DEFAULT: Constructing an IKE_SA_INIT-RESPONSE for send
+IKE-SA:
  IKE-Proposal-1  (4 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256
    INTEG: HMAC-SHA-256
    DH   : 14
+KE-DH-Group 14 (2048 bits)
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x4DC0FD3816640E0F, responder cookie: 0xC5CB040FD7F7EE80
SA ISAKMP for peer DEFAULT
 Encryption                    : AES-CBC-256
 Integrity                     : AUTH-HMAC-SHA-256
 IKE-DH-Group                  : 14
 PRF                           : PRF-HMAC-SHA-256
life time soft 06/14/2025 17:12:40 (in 97200 sec) / 0 kb
life time hard 06/14/2025 20:12:40 (in 108000 sec) / 0 kb
DPD: NONE
Negotiated: IKE_FRAGMENTATION IKEV2_FRAGMENTATION

Sending an IKE_SA_INIT-RESPONSE of 570 bytes (responder)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x4DC0FD3816640E0FC5CB040FD7F7EE80, Message-ID 0

[VPN-Status] 2025/06/13 14:12:40,683
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 304 bytes (encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x4DC0FD3816640E0FC5CB040FD7F7EE80, Message-ID 1
CHILD_SA ('', '' ) entered to SADB
Received 2 notifications: 
  +MANAGEMENT_IP4_ADDRESS (PRIVATE)
  +INITIAL_CONTACT (STATUS)
+Received-ID filiale-1@zentrale.org:USER_FQDN matches the Expected-ID filiale-1@zentrale.org:USER_FQDN
+Peer identified: FILIALE-1
+Peer uses AUTH(PSK)
+Authentication successful
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x4DC0FD3816640E0FC5CB040FD7F7EE80) removed from SADB
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x4DC0FD3816640E0FC5CB040FD7F7EE80) entered to SADB
Request attributes:
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP4_DNS()
  INTERNAL_IP4_NBNS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DNS()
  INTERNAL_IP4_SUBNET()
  INTERNAL_IP6_SUBNET()
  INTERNAL_DNS_DOMAIN()
  -Acquiring addresses failed  -> abort

[VPN-Status] 2025/06/13 14:12:40,685
Peer FILIALE-1: Constructing an IKE_AUTH-RESPONSE for send
+Local-ID filiale-1@zentrale.org:USER_FQDN
+I use AUTH(PSK)

IKE_SA_INIT [responder] for peer FILIALE-1 initiator id filiale-1@zentrale.org, responder id filiale-1@zentrale.org
initiator cookie: 0x4DC0FD3816640E0F, responder cookie: 0xC5CB040FD7F7EE80
SA ISAKMP for peer FILIALE-1
 Encryption                    : AES-CBC-256
 Integrity                     : AUTH-HMAC-SHA-256
 IKE-DH-Group                  : 14
 PRF                           : PRF-HMAC-SHA-256
life time soft 06/14/2025 17:12:40 (in 97200 sec) / 0 kb
life time hard 06/14/2025 20:12:40 (in 108000 sec) / 0 kb
DPD: 31 sec
Negotiated: IKE_FRAGMENTATION IKEV2_FRAGMENTATION

NOTIFY(INTERNAL_ADDRESS_FAILURE)
CHILD_SA ('', '' ) removed from SADB
CHILD_SA ('', '' ) freed
Sending an IKE_AUTH-RESPONSE of 144 bytes (responder encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x4DC0FD3816640E0FC5CB040FD7F7EE80, Message-ID 1

[VPN-Status] 2025/06/13 14:12:40,707
Peer FILIALE-1 [responder]: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x4DC0FD3816640E0FC5CB040FD7F7EE80, Message-ID 2

[VPN-Status] 2025/06/13 14:12:40,707
Peer FILIALE-1: Constructing an INFORMATIONAL-RESPONSE for send
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x4DC0FD3816640E0FC5CB040FD7F7EE80) removed from SADB
Sending an INFORMATIONAL-RESPONSE of 80 bytes (responder encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x4DC0FD3816640E0FC5CB040FD7F7EE80, Message-ID 2

[VPN-Status] 2025/06/13 14:12:40,708
IKE_SA ('FILIALE-1', 'ISAKMP-PEER-FILIALE-1' IPSEC_IKE SPIs 0x4DC0FD3816640E0FC5CB040FD7F7EE80) freed

[VPN-Status] 2025/06/13 14:12:40,708
FILIALE-1: DISCONNECT-RESPONSE sent for handle 22

[VPN-Status] 2025/06/13 14:12:40,708
vpn-maps[22], remote: FILIALE-1, idle, static-name

[VPN-Status] 2025/06/13 14:12:41,843
Peer DEFAULT: Received an IKE_SA_INIT-REQUEST of 569 bytes
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x0EE69EF128FBDDF30000000000000000, Message-ID 0
Peer identified: DEFAULT
IKE_SA ('', '' IPSEC_IKE SPIs 0x0EE69EF128FBDDF3F2A7700F920F28D5) entered to SADB
Received 5 notifications: 
  +REDIRECT_SUPPORTED (STATUS)
  +NAT_DETECTION_SOURCE_IP(0xC619BBD8BD90B6F9237D0D350B2485C2281BE845) (STATUS)
  +NAT_DETECTION_DESTINATION_IP(0x4999636F621AC6CE0E742412BDF7870737A71F8E) (STATUS)
  +IKEV2_FRAGMENTATION_SUPPORTED (STATUS)
  +DEVICE-ID(0x5C98A3B4E78DB800D3DE82B891E63196EFF796710EC3ECA725136291AFA2710A) (PRIVATE)
Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled
+IKE-SA:
  IKE-Proposal-1  (6 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256 PRF-HMAC-SHA1
    INTEG: HMAC-SHA-256 HMAC-SHA1
    DH   : 14
+Received KE-DH-Group 14 (2048 bits)

[VPN-Status] 2025/06/13 14:12:42,092
Peer DEFAULT: Constructing an IKE_SA_INIT-RESPONSE for send
+IKE-SA:
  IKE-Proposal-1  (4 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256
    INTEG: HMAC-SHA-256
    DH   : 14
+KE-DH-Group 14 (2048 bits)
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x0EE69EF128FBDDF3, responder cookie: 0xF2A7700F920F28D5
SA ISAKMP for peer DEFAULT
 Encryption                    : AES-CBC-256
 Integrity                     : AUTH-HMAC-SHA-256
 IKE-DH-Group                  : 14
 PRF                           : PRF-HMAC-SHA-256
life time soft 06/14/2025 17:12:42 (in 97200 sec) / 0 kb
life time hard 06/14/2025 20:12:42 (in 108000 sec) / 0 kb
DPD: NONE
Negotiated: IKE_FRAGMENTATION IKEV2_FRAGMENTATION

Sending an IKE_SA_INIT-RESPONSE of 570 bytes (responder)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500-->[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500, tag 0 (UDP)
SPIs: 0x0EE69EF128FBDDF3F2A7700F920F28D5, Message-ID 0

[VPN-Status] 2025/06/13 14:12:42,120
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 304 bytes (encrypted)
Gateways: [2003:dead:beef:ff0c:2a0:57ff:fe54:f215]:500<--[2a01:dead:beef:0:a0:57ff:fe55:6c43]:500
SPIs: 0x0EE69EF128FBDDF3F2A7700F920F28D5, Message-ID 1
CHILD_SA ('', '' ) entered to SADB
Received 2 notifications: 
  +MANAGEMENT_IP4_ADDRESS (PRIVATE)
  +INITIAL_CONTACT (STATUS)
+Received-ID filiale-1@zentrale.org:USER_FQDN matches the Expected-ID filiale-1@zentrale.org:USER_FQDN
+Peer identified: FILIALE-1
+Peer uses AUTH(PSK)

backslash · Beitrag von **backslash** » 13 Jun 2025, 14:48

Hi roell.f

jetzt ist zwar die PPP-Fehlermeldung weg - aber die hätte eh nie auftauchen sollen...

Nun sind wir an dem Punkt, an dem ich nicht mehr weiter weiss - offenbar will die Filiale nun von der Zentrale auch eine IP-Adresse zugewiesen bekommen (wegen CFG-Mode-Client), was die Zentrale abar nicht macht - mangels konfigurierter Adreß- und Prefix-Pools. Da ist aber einer LAN-LAN-Kopplung auch nicht nötig.

Wie gesagt: ich hab das noch nie konfiguriert. Da müßtest du jetzt mal das Hanbuch lesen oder die LANCOM Knowledgebase befragen.
Vielleicht weiss auber auch ein anderer User im Forum weiter...

Gruß
Backslash

Dr.Einstein · Beitrag von **Dr.Einstein** » 13 Jun 2025, 14:54

Wenn du unter Kommunikation / Protokolle / IP-Parameter einen Eintrag mit Name der VPN-Gegenstelle erstellst, und als IP-Adresse die INTRANET IP Einträgst als 255.255.255.255 Subnetmaske, und den Rest auf 0.0.0.0 lässt, sollte an sich die Anfrage nach einer Client-IP-Adresse unterdrückt werden. Ob das auch die v6-Address-Anfrage neutralisiert, kann ich dir leider nicht beantworten.

roell.f · Beitrag von **roell.f** » 13 Jun 2025, 15:42

hallo Dr.Einstein,

Dr.Einstein hat geschrieben: 13 Jun 2025, 14:54 Wenn du unter Kommunikation / Protokolle / IP-Parameter einen Eintrag mit Name der VPN-Gegenstelle erstellst, und als IP-Adresse die INTRANET IP Einträgst als 255.255.255.255 Subnetmaske, und den Rest auf 0.0.0.0 lässt, ...

ich habe das gemacht und erhalte im LANmonitor für die ZENTRALE

IKE Schlüssel stimmen nicht überein (Aktiver Verbindungsaufbau, IKE) [0x210A]

so weit, so schlecht.

Dr.Einstein hat geschrieben: 13 Jun 2025, 14:54 ..., sollte an sich die Anfrage nach einer Client-IP-Adresse unterdrückt werden. Ob das auch die v6-Address-Anfrage neutralisiert, kann ich dir leider nicht beantworten.

verzeihung, das scheint mir eine verzweiflungstat zu sein, weil wir mit der konfiguration im bereich IPv4 ein problem im bereich IPv6 zu lösen versuchen. meine denke von dual-stack ist, dass es sich um zwei völlig separate protokollstapel handelt und die beiden (abgesehen von den wenigen verfahren zur deren kopplung) überhaupt nichts mit einander zu tun haben. oder?

eine site-to-site-kopplung über IPv6 von einer dynamisch versorgten seite mit einer statisch versorgten halte ich jetzt nicht für so abwegig, dass in der LANCOM-welt nur eine handvoll experten existieren, die wissen wie das geht. es handelt sich ja nicht um so komplizierte verfahren wie das lila-mäuse-melken-am-hang

ok, wo genau ist diese (standard-) aufgabe samt lösung beschrieben, oder besser noch, wenn können wir wie ansprechen?

BG frank

sebsch134 · Beitrag von **sebsch134** » 13 Jun 2025, 18:43

Config Service bei LANCOM als Service buchen? Dafür ist der halt da.

roell.f · Beitrag von **roell.f** » 13 Jun 2025, 20:15

hallo sebsch134,
hallo forum,

sebsch134 hat geschrieben: 13 Jun 2025, 18:43 Config Service bei LANCOM als Service buchen? Dafür ist der halt da.

hm, eine kommerzielle lösung für laut preistabelle vom feb. 2024 "nur" 297,50 euro brutto pro 60 minuten!

ob wir hier im forum unsere zeit, die wir mit dem problem zubringen mussten, wohl damit verrechnen dürfen?

jetzt wird mir auch das lausige LCOS-handbuch erklärlich: es scheint mir bestandteil eines geschäftsmodells zu sein, bei dem der kunde mit hilfe unzulänglicher dokumentation solange frustriert wird, bis er bereit ist, stundensätze zu akzeptieren, die nicht mal ein premiumverdienender radiologe aufruft.

für mich ist die sache einfach: entweder finde ich hier im forum jemanden, der mir hilft die sache an's laufen zu bringen oder ich mache es wie die meisten: was kümmert mich IPv6, solange ich ein IPv4-lösung habe. emotional bin ich trotz meiner technikverliebtheit zu einem "fort-mit-schaden" durchaus in der lage.

@sebsch134:
ich köpfe keinen boten für die schlechte nachricht, die er überbringt. ich bin nicht im mindesten über dich sondern ausschließlich über lancom verärgert.

@backslash:
dein hilfe war super. so kenne ich dich, seit dem ich im forum unterwegs bin. dafür nochmals danke!

mal sehen, ob sich über's wochende einer findet, der sagt "ich weiß wie das geht" und der gerne mit uns sein wissen teilt. andernfalls schließe ich das thema kommenden mittwoch den 2025-06-18 für mich ab.

beste grüße
frank

Dr.Einstein · Beitrag von **Dr.Einstein** » Gestern, 09:52

Okay, habe mich vertan. Du löscht wieder meine Idee zur IP-List. Danach legst auf der dynamischen v6-Seite wo IKE-CGF Mode auf Client steht, unter VPN / Erweiterte Einstellungen / ein neues CFG-Client-Profil an, wobei v4 und v6 nicht angehakt sind. Dieses neue Profil weist du dann unter der Verbindungsliste deiner VPN-Verbindung zu.

Beachte aber ggf. eine Routingschleife. Sollte das INTRANET das gleiche Präfix nutzen, wie der Tunnelaufbau, so baust du dir eine Schleife. Der Tunnelaufbau über v6 (falls du den überhaupt über v6 aufbaust) geht dann nicht mehr, weil er das Präfix ja über den v6-Tunnel schickt statt über das WAN. Bei mir war das soweit kein Problem, da mein WAN-Provider ein /56 für das LAN und ein /64 für das Transfernetz zwischen Provider und Router mir zuweist. Via IKEv2-Routing propagiere ich dann das INTRANET, was ein /64 Bestandteil des /56 ist. Sollte jedoch eine Seite nur ein /64 besitzen und dynamisch angelernt werden, so wird diese Seite vermutlich nicht funktionieren. In der Regel machen das Mobilfunkprovider so.

Um diesen ganzen Blödsinn zu vermeiden, nutze ich zumindest ULAs für VPN-Tunnel zwischen den Partnern. Diese sind komplett unabhängig vom WAN-Provider und gehen einfach. Aber die Aussagen von backslash machen mir immer Sorgen, da er sagt, man sollte keine ULAs mehr verwenden. Vermutlich erstelle ich momentan v6-Standortvernetzungen, die vergleichbar sind mit Netzwerkeinrichtungen aus den 1990er Zeiten, wo IPv4-Netze mit 100.0.0.0/8 und 101.0.0.0/8 usw verwendet wurden.

LANCOM-Forum.de

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

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

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

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

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

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

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

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