Hallo,
Mein Setup ist folgendes:
Ich habe vom ISP eine IPv4 Adresse bekommen, die sich in einem /30 Transfernetz befindet. Der andere Teilnehmer ist ein Router von meinem ISP. Ich habe die Verbidnung über eine IPoE Gegenstelle in meiner 7111 realisiert.
Zusätzlich dazu habe ich einen v4 Adressblock /29 bekommen. Alle möglichen Adressen innerhalb des Blocks werden beim ISP auf meine obige v4 Adresse geroutet.
Mein Ziel ist nun, dass ich für VPN Verbindungen eine IP Adresse aus dem /29 Block in die VPN Clients einkonfiguriere und dort entsprechend VPN Verbindungen aufgebaut werden können.
Das ganze Szenario funktioniert, wenn meine Clients sich direkt bei der IP aus dem Transfernetz melden.
Was muss ich an der Firewall noch konfigurieren, dass sie sich für Pakete an dieses Netz überhaupt zuständig fühlt, bzw. wie realisiere ich, dass überhaupt Pakete diese IP Adressen verwertet werden. ein race zeigt zumindest nicht an, dass irgendwelche Pakete ankommen
Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Moderator: Lancom-Systems Moderatoren
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Ich muss das nochmal nach oben schieben. Mein Gedanke war, dass ich den /29 Adressblock in eine DMZ packe und der Lancom eine Adresse daraus gebe. Wie genau bring ich sie jetzt dazu, Pakete für diesen Bereich auch zu verarbeiten?
Ich glaube ich steh hier gewaltig auf dem Schlauch.
Muss ich evtl. irgendwo eine zusätzliche Gegenstelle aufbauen?
Ich glaube ich steh hier gewaltig auf dem Schlauch.
Muss ich evtl. irgendwo eine zusätzliche Gegenstelle aufbauen?
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi hoeschler,
was spricht dagegen, daß die VPN-Clients sich mit der IP des LANCOMs (aus dem /30er-Netz) verbinden?
Das /29er ist normalerweise für eine DMZ gedacht, d.h. du richtest auf dem LANCOM eine entsprechende DMZ ein und stellst die Maskierungs-Option auf "nur Intranet maskieren". Dann kannst du in der dieser DMZ Server mit öffentlichen IPs betreiben (und das LANCOM hat selbst auch eine IP aus dem Netz).
Oder du erstellst Portforwardings für die /29er-Adressen (bei "Intranet und DMZ maskieren"), indem du in der Portforwarding-Tabelle unter "WAN-Adresse" die Adesse aus dem /29er Netz einträgst, für die das jeweilige Forwarding gelten soll.
Wenn du tatsächlich willst, daß das LANCOM selbst auch auf eine (oder mehrere) der /29er-Adressen reagiert ohne eine DMZ einzurichten, dann mußt du mit "Loopback-Adressen" arbeiten (unter IPv4 -> Allgemein). Dort kannst du die gewünschten Adressen eintragen.
Gruß
Backslash
was spricht dagegen, daß die VPN-Clients sich mit der IP des LANCOMs (aus dem /30er-Netz) verbinden?
Das /29er ist normalerweise für eine DMZ gedacht, d.h. du richtest auf dem LANCOM eine entsprechende DMZ ein und stellst die Maskierungs-Option auf "nur Intranet maskieren". Dann kannst du in der dieser DMZ Server mit öffentlichen IPs betreiben (und das LANCOM hat selbst auch eine IP aus dem Netz).
Oder du erstellst Portforwardings für die /29er-Adressen (bei "Intranet und DMZ maskieren"), indem du in der Portforwarding-Tabelle unter "WAN-Adresse" die Adesse aus dem /29er Netz einträgst, für die das jeweilige Forwarding gelten soll.
Wenn du tatsächlich willst, daß das LANCOM selbst auch auf eine (oder mehrere) der /29er-Adressen reagiert ohne eine DMZ einzurichten, dann mußt du mit "Loopback-Adressen" arbeiten (unter IPv4 -> Allgemein). Dort kannst du die gewünschten Adressen eintragen.
Gruß
Backslash
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hallo,
Ich hab die VPN Clients jetzt auf die IP im /30 konfiguriert. Das ist mir so nicht in den Sinn gekommen. Vielen Dank dafür.
Nochmal kurz zur DMZ: Ich hab eine DMZ eingerichtet und eine der öffentlichen Adressen für die Lancom definiert. In dieser DMZ sitzt jetzt ein Gerät, welches eine andere IP aus dem Netz hat.
Irgendwie klappt das mit dem Routing noch nicht. Ich hab auf dem Gerät als Gatewayadresse die zugewiesene IP der Lancom eingetragen (die ich ihr im /29 gegeben hab). Das sollte es doch eigentlich gewesen sein, oder? Ich bekomm gerade nichts, also nicht einmal irgendwelche Logmeldungen o.ä.
Ich hab die VPN Clients jetzt auf die IP im /30 konfiguriert. Das ist mir so nicht in den Sinn gekommen. Vielen Dank dafür.
Nochmal kurz zur DMZ: Ich hab eine DMZ eingerichtet und eine der öffentlichen Adressen für die Lancom definiert. In dieser DMZ sitzt jetzt ein Gerät, welches eine andere IP aus dem Netz hat.
Irgendwie klappt das mit dem Routing noch nicht. Ich hab auf dem Gerät als Gatewayadresse die zugewiesene IP der Lancom eingetragen (die ich ihr im /29 gegeben hab). Das sollte es doch eigentlich gewesen sein, oder? Ich bekomm gerade nichts, also nicht einmal irgendwelche Logmeldungen o.ä.
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi hoeschler,
trace # ip-ro eth @ -tcp
Genauso solltest du im Gegenzug auch mal prüfen, ob der Provider das /29er-Netz tatsächlich zum LANCOM routet, indem du aus dem Internet heraus einfach mal versuchst eine Adresse in dem Netz anzupingen und das Ganze ebenfalls per Router- und Ethernet-Trace mitschneidest...
Generell solltest du bei den Traces darauf achten, daß kein weiterer Traffic vorhanden ist, da du sonst den Wald vor lauter Bäumen nicht mehr siehst
Gruß
Backslash
Beachte dabei, daß ein /29er Netz nur sechs frei verfügbare Adressen hat. Die beiden verbleibenden dienen als Netzadresse und als Broadcast-Adresse und dürfen nicht vergeben werden.Irgendwie klappt das mit dem Routing noch nicht. Ich hab auf dem Gerät als Gatewayadresse die zugewiesene IP der Lancom eingetragen (die ich ihr im /29 gegeben hab)
ja - zumindest, wenn du die DMZ als solche markiert und die Maskierungsoption der Defaultroute auf "nur Intranet maskieren" gestellt hast.Irgendwie klappt das mit dem Routing noch nicht. Ich hab auf dem Gerät als Gatewayadresse die zugewiesene IP der Lancom eingetragen (die ich ihr im /29 gegeben hab). Das sollte es doch eigentlich gewesen sein, oder?
mach mal auf dem LANCOM einen IP-Router- und Ethernet-Trace beim Versuch von dem Gerät aus irgend eine IP-Adresse im Internet anzupingen, z.B. die 8.8.8.8... Achte dabei darauf, daß du deine Telnet-Session mit der du den Trace erstellst nicht mitschneidest:Ich bekomm gerade nichts, also nicht einmal irgendwelche Logmeldungen o.ä.
trace # ip-ro eth @ -tcp
Genauso solltest du im Gegenzug auch mal prüfen, ob der Provider das /29er-Netz tatsächlich zum LANCOM routet, indem du aus dem Internet heraus einfach mal versuchst eine Adresse in dem Netz anzupingen und das Ganze ebenfalls per Router- und Ethernet-Trace mitschneidest...
Generell solltest du bei den Traces darauf achten, daß kein weiterer Traffic vorhanden ist, da du sonst den Wald vor lauter Bäumen nicht mehr siehst
Gruß
Backslash
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi,
Die Traces selbst muss ich noch machen.
Die IP der Firewall selbst in dem /29 ist pingbar und ein Traceroute hüpft auch über die andere IP im /30
Daher meine ich schon, dass alles vom Provider aus richtig geroutet wird.
Interessant ist eher: Ich habe jetzt den Host direkt auf den eth3 geklemmt, bekomm ihn aber nicht angepingt. Umgekehrt bekomm ich die lancom als gateway auch nicht angepingt. Ich hab dann auch eine FW Regel erstellt und testweise vom Host aus jeden Traffic erlaubt, ohne Erfolg. Danach hab ich auch nochmal eine andere Regel eingestellt und jeden Traffic auf Port 80 auf dem Host erlaubt. Auch das klappt nicht.
Die Traces selbst muss ich noch machen.
Die IP der Firewall selbst in dem /29 ist pingbar und ein Traceroute hüpft auch über die andere IP im /30
Daher meine ich schon, dass alles vom Provider aus richtig geroutet wird.
Interessant ist eher: Ich habe jetzt den Host direkt auf den eth3 geklemmt, bekomm ihn aber nicht angepingt. Umgekehrt bekomm ich die lancom als gateway auch nicht angepingt. Ich hab dann auch eine FW Regel erstellt und testweise vom Host aus jeden Traffic erlaubt, ohne Erfolg. Danach hab ich auch nochmal eine andere Regel eingestellt und jeden Traffic auf Port 80 auf dem Host erlaubt. Auch das klappt nicht.
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi hoeschler,
Du mußt zunächst unter dem Ethernet-Port unter Schnittstellen -> LAN -> Ethernet-Ports die Interface-Verwendung z.B. als LAN-2 zuordnen.
Danach mußt du unter IPv4 -> Allgemein -> IP-Netwerke der DMZ dieses LAN-2 unter Schnittstellen-Zuordnung zuweisen.
Der Netzwerktyp der DMZ muß natürlich auf DMZ stehen.
Gruß
Backslash
das deutet aber eher darauf hin, daß die Zuordnung zwischen Ethernet-Port, LAN-Interface und IP-Netz nicht korrekt ist...Interessant ist eher: Ich habe jetzt den Host direkt auf den eth3 geklemmt, bekomm ihn aber nicht angepingt. Umgekehrt bekomm ich die lancom als gateway auch nicht angepingt.
Du mußt zunächst unter dem Ethernet-Port unter Schnittstellen -> LAN -> Ethernet-Ports die Interface-Verwendung z.B. als LAN-2 zuordnen.
Danach mußt du unter IPv4 -> Allgemein -> IP-Netwerke der DMZ dieses LAN-2 unter Schnittstellen-Zuordnung zuweisen.
Der Netzwerktyp der DMZ muß natürlich auf DMZ stehen.
Du solltest in jedem Fall das LANCOM vom Server aus anpingen können - solange das nicht geht, brauchst du dir um Firewallregeln keine Gedanken machen, denn die sind "nur" Forwarding-Regeln und beeinflussen daher die direkte Erreichbarkeit (Pingbarkeit) des LANCOMs nicht.Ich hab dann auch eine FW Regel erstellt und testweise vom Host aus jeden Traffic erlaubt, ohne Erfolg. Danach hab ich auch nochmal eine andere Regel eingestellt und jeden Traffic auf Port 80 auf dem Host erlaubt. Auch das klappt nicht.
Gruß
Backslash
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi,
Ja das wundert mich ja gerade.
Ich hab die Schnittstelle ETH-3 auf LAN-4 gesetzt. Ich hab den private mode abgeschaltet. Ich hab ja auch vlan tagging auf den anderen Ports an, deshalb hab ich das für lan 4 auf niemals gesetzt.
Die DMZ hab ich als DMZ eingerichtet, ebenfalls mit LAN-4.
Geht einfach nicht.
Ich hab jetzt auch mal einen Switch an den Port gehängt, dazu einen Laptop, diesem die nächste IP im Block zugewiesen. Da das gleiche Spiel, die Lancom ist nicht erreichbar. Selbst wenn ich ihr selbst eine andere IP zuweise.
Ja das wundert mich ja gerade.
Ich hab die Schnittstelle ETH-3 auf LAN-4 gesetzt. Ich hab den private mode abgeschaltet. Ich hab ja auch vlan tagging auf den anderen Ports an, deshalb hab ich das für lan 4 auf niemals gesetzt.
Die DMZ hab ich als DMZ eingerichtet, ebenfalls mit LAN-4.
Geht einfach nicht.
Ich hab jetzt auch mal einen Switch an den Port gehängt, dazu einen Laptop, diesem die nächste IP im Block zugewiesen. Da das gleiche Spiel, die Lancom ist nicht erreichbar. Selbst wenn ich ihr selbst eine andere IP zuweise.
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Hi hoeschler,
Mit VLAN gibt es natürlich noch eine ganze Menge anderer Dinge die schief gehen können. Da solltest du neben Router- und Ethernet-Trace auch den VLAN-Trace machen - nur hat der das Problem, daß er sich nicht sinnvoll filtern läßt und du somit auch Ausgabe der tracenden Session dehen dürftest.
Gruß
Backslash
Du hast also auch das VLAN-Modul an? Dann mußt du den jeweiligen Ethernet-Port einem VLAN zuweisen *und* auch dem DMZ-Netz dieses VLAN zuweisen, sonst passiert da gar nichts. VLAN 0 gibt es nur, wenn das VLAN-Modul deaktiviert ist.Ich hab ja auch vlan tagging auf den anderen Ports an, deshalb hab ich das für lan 4 auf niemals gesetzt.
Mit VLAN gibt es natürlich noch eine ganze Menge anderer Dinge die schief gehen können. Da solltest du neben Router- und Ethernet-Trace auch den VLAN-Trace machen - nur hat der das Problem, daß er sich nicht sinnvoll filtern läßt und du somit auch Ausgabe der tracenden Session dehen dürftest.
Gruß
Backslash
Re: Verarbeitung eines vom ISP gerouteteten IPv4 Blocks
Wah! Vielen Dank, das war ein Treffer.
Ich hab ein VLAN definiert und auf das Device gelegt, dann gehts.
Ich hab ein VLAN definiert und auf das Device gelegt, dann gehts.