Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 2114 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPv6 korrekt an DeutschlandConnectIP aktivieren

Stefan Schinzel

Hallo,

eigentlich eine einfache Sache, nur bei mir scheinbar nicht. Ausgangspunkt:

GF-> (SPF GIG0/1) AdtranNetVanta4660 (GIG0/2 RJ45)-> (eth1) SG230 (eth0) -> internes Netz

                                                                                           (ethx -> weitere Netze)

Die IPv4 Geschichte läuft so wie es soll seit Jahren. Die SG bedient 3 IPv4/29 Netze, nun soll IPv6 aktiviert werden.

eth1 ist folgendermassen konfiguriert (als Beispiel eine zus. Adresse):

Wird nun IPv6 aktiviert bekomme ich:

Soweit so gut. Leider scheitert ein Kontaktversuch über IPv6 nach aussen:

Was läuft hier schief? Was fehlt da noch?

Gruß,

Stefan



This thread was automatically locked due to age.
Parents
  • 0

    was für eine IP ist am externen Interface gebunden?

    ist das IPv6 default gateway pingbar?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Hallo,

     

    danke erstmal für (D)eine Antwort, ein wenig bin scheinbar weitergekommen.

    Das externe Interface eth1 hat folgende Adressen zugewiesen:

    loginuser@asg01:/home/login > ip -6 ad sh eth1
    11: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 ABCD:EFGH:c011::8/48 scope global
    valid_lft forever preferred_lft forever
    inet6 fe80::21a:8cff:fe59:2469/64 scope link
    valid_lft forever preferred_lft forever

    Der "WAN" Port des Telekom-Routers hat ABCD:EFGH:c011::1 und routet laut Telekom das gesamte Netz nach ABCD:EFGH:c011::8

    Ich kann von der UTM ssh-console aus:

    - unsere externe UTM-WAN Adresse ABCD:EFGH:c011::8 anpingen.

    - Telekom-Router externe WAN Adresse ABCD:EFGH:c011::1 anpingen.

    - ipv6.google.com Adresse 2a00:1450:4001:819::200 anpingen.

    - traceroute ipv6.google.com Adresse 2a00:1450:4001:819::200 durchführen.

     

    Ich kann von extern:

    - Telekom-Router externe WAN Adresse ABCD:EFGH:c011::1 anpingen.

    - unsere externe UTM-WAN Adresse ABCD:EFGH:c011::8 anpingen.

     

    Nun ein zus. Interface (physikalisch vorhanden eth13) anglegen hier unter IPv6 als Beispiel

    die Adresse ABCD:EFGH:c011:fff::1 eintragen (ist ja innerhalb der /48). Somit sollte unter

    Preafix-Advertisement möglich sein um ein /64 Netz bereitzustellen bei dem

    sich die Clients IPv6 aus eben diesem Netz ABCD:EFGH:c011:fff::/64 eine Adresse holen. Das klappt auch soweit,

    doch ein Routing findet scheinbar nicht statt. Ich bin nichtmal in der Lage von einem Client aus diesem

    Netz einen Ping auf die entsprechende UTM-Schnittstelen und deren Adresse ABCD:EFGH:c011:fff::1 zu machen!

    9: eth13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 ABCD:EFGH:c011:fff::1/64 scope global
           valid_lft forever preferred_lft forever
        inet6 fe80::21a:8cff:fe65:da47/64 scope link
           valid_lft forever preferred_lft forever

    was mir auch auffällt ist ein (möglicherweise) seltsamer Routingtable:

    ABCD:EFGH:c011::1 dev eth1  metric 1024
    ABCD:EFGH:c011:1::/64 dev eth0  proto kernel  metric 256
    ABCD:EFGH:c011:a::/64 dev eth2  proto kernel  metric 256
    ABCD:EFGH:c011:fff::/64 dev eth13  proto kernel  metric 256
    ABCD:EFGH:c011::/48 dev eth1  proto kernel  metric 256
    fe80::/64 dev redw2  proto kernel  metric 256
    fe80::/64 dev redw0  proto kernel  metric 256
    fe80::/64 dev redw1  proto kernel  metric 256
    fe80::/64 dev redw0.103  proto kernel  metric 256
    fe80::/64 dev redw2.103  proto kernel  metric 256
    fe80::/64 dev redw1.103  proto kernel  metric 256
    fe80::/64 dev redw0.101  proto kernel  metric 256
    fe80::/64 dev redw2.101  proto kernel  metric 256
    fe80::/64 dev redw1.101  proto kernel  metric 256
    fe80::/64 dev redw0.102  proto kernel  metric 256
    fe80::/64 dev redw2.102  proto kernel  metric 256
    fe80::/64 dev redw1.102  proto kernel  metric 256
    fe80::/64 dev ifb0  proto kernel  metric 256
    fe80::/64 dev ifb1  proto kernel  metric 256
    fe80::/64 dev ifb2  proto kernel  metric 256
    fe80::/64 dev ifb3  proto kernel  metric 256
    fe80::/64 dev ifb4  proto kernel  metric 256
    fe80::/64 dev ifb5  proto kernel  metric 256
    fe80::/64 dev ifb6  proto kernel  metric 256
    fe80::/64 dev ifb7  proto kernel  metric 256
    fe80::/64 dev reds1  proto kernel  metric 256
    fe80::/64 dev br0  proto kernel  metric 256
    fe80::/64 dev eth5  proto kernel  metric 256
    fe80::/64 dev wlan3  proto kernel  metric 256
    fe80::/64 dev wlan2  proto kernel  metric 256
    fe80::/64 dev eth9  proto kernel  metric 256
    fe80::/64 dev eth6  proto kernel  metric 256
    fe80::/64 dev eth11  proto kernel  metric 256
    fe80::/64 dev eth7  proto kernel  metric 256
    fe80::/64 dev eth10  proto kernel  metric 256
    fe80::/64 dev eth4  proto kernel  metric 256
    fe80::/64 dev eth0  proto kernel  metric 256
    fe80::/64 dev eth2  proto kernel  metric 256
    fe80::/64 dev eth1  proto kernel  metric 256
    fe80::/64 dev eth13  proto kernel  metric 256

    Das :1: und :a: sind Testnetze, da brauch ich (noch) kein Advertisement.

     

    Könnten daher auch diese unendliche auftretenden

    14:48:21 Spoofed packet UDP  
    ABCD:EFGH:c011:1::1:15 : 41384
    		→
    2001:7fe::53 : 53
    		 
    len=77 srcmac=aa:aa:aa:01:7a:ed dstmac=bb:bb:bb:59:24:68

    begründet liegen?

     

    Bin ratlos :-o und dankbar für jedwede Hilfe zur Problemlösung.

    Gruß,

    Stefan

  • 0 in reply to Stefan Schinzel

    Ich habe da nur eine vage Idee ... und die kommt aus einem IPv4 Kopf...

    Das interne Netz ABCD:EFGH:c011:fff::1/48 liegt innerhalb des Netzbereiches/Subnetzes des externen Adressbereiches ABCD:EFGH:c011:::1/64 

    ... kann / darf so etwas bei IPv6 sein?

    Ich habe bei meinen IPv6 Versuchen intern mit einem eigenen / privaten IPv6 Bereich gearbeitet und maskiert/genattet wie bei IPv4. Das ging, ist aber bei IPv6 nicht mehr so gewollt ... glaube ich.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    So jetzt habe ich es. Btw. NAT bei IPv6 ist "bäh".

     

    Die externe Schnittstelle der UTM (hier eth1) wird mit ABCD:EFGH:c011::8 und der Netzmaske /64 angelegt.

    Das default Gateway wird mit der Adresse ABCD:EFGH:c011::1 angegeben.

    Die beiden oberen IPs wurden von der Telekom vorgegeben.

    Das stellt scheinbar mein "Transfernetz" dar und ist das erste /64 aus dem uns zugewiesenen /48 Bereich .

    Nun wird die interne Schnittstelle (hier eth0) mit ABCD:EFGH:c011:1::1 und Netzmaske /64 angelegt

    - man beachte ein anderes, nämlich einfach das zweite,  /64 Netz!!

    IPv6 Konnektivität vom internen Netz nach außen ist gegeben.

     

    Nun kann ich auch weitere Netze anlegen (hier eth13) mit ABCD:EFGH:c011:fff::1 /64 und per praefix delegation

    Clients an dieser Schnittstelle mit dem Praefix versorgen. Auch das Routing stimmt - sowohl raus als auch rein.

     

    Irritierend bei der ganzen Geschichte ist dass nirgend angegeben werden muss wie groß (/48) das uns zugewiesene Netz überhaupt ist....

     

    <These>

    Vmtl. Routet die Sophos einfach alles was reinkommt und nicht lokal (eth0, eth13) bedient werden kann einfach zum Defaultgateway welches eben über das erste /64 Netz erreicht werden kann, und von außen wird einfach alles aus dem /48 Netz an der Sophos abgekippt und die Netze die per Definition (eth0, eth13) existent sind bekommen Ihre Pakete der Rest wird verworfen.

    </These>

     

    Zumindest läuft das jetzt.

     

    Gruß Stefan

Reply
  • 0 in reply to dirkkotte

    So jetzt habe ich es. Btw. NAT bei IPv6 ist "bäh".

     

    Die externe Schnittstelle der UTM (hier eth1) wird mit ABCD:EFGH:c011::8 und der Netzmaske /64 angelegt.

    Das default Gateway wird mit der Adresse ABCD:EFGH:c011::1 angegeben.

    Die beiden oberen IPs wurden von der Telekom vorgegeben.

    Das stellt scheinbar mein "Transfernetz" dar und ist das erste /64 aus dem uns zugewiesenen /48 Bereich .

    Nun wird die interne Schnittstelle (hier eth0) mit ABCD:EFGH:c011:1::1 und Netzmaske /64 angelegt

    - man beachte ein anderes, nämlich einfach das zweite,  /64 Netz!!

    IPv6 Konnektivität vom internen Netz nach außen ist gegeben.

     

    Nun kann ich auch weitere Netze anlegen (hier eth13) mit ABCD:EFGH:c011:fff::1 /64 und per praefix delegation

    Clients an dieser Schnittstelle mit dem Praefix versorgen. Auch das Routing stimmt - sowohl raus als auch rein.

     

    Irritierend bei der ganzen Geschichte ist dass nirgend angegeben werden muss wie groß (/48) das uns zugewiesene Netz überhaupt ist....

     

    <These>

    Vmtl. Routet die Sophos einfach alles was reinkommt und nicht lokal (eth0, eth13) bedient werden kann einfach zum Defaultgateway welches eben über das erste /64 Netz erreicht werden kann, und von außen wird einfach alles aus dem /48 Netz an der Sophos abgekippt und die Netze die per Definition (eth0, eth13) existent sind bekommen Ihre Pakete der Rest wird verworfen.

    </These>

     

    Zumindest läuft das jetzt.

     

    Gruß Stefan

Children
No Data
Unfiltered HTML