EN - HEv6 Tunnel improvements

After surfing the HE forum and a few other blogs I noticed some nice improvements that i would like to share with you.

DDNS URL
Currently I´m using the inital URL from HE but it is possible to use another URL that does not leave youre password in plaintext in your config

https://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&pass=MD5PASS&apikey=USERID&tid=TUNNELID

Keep in mind that USERID is not your accountname but the ID you can find on the HE webpage. MD5PASS is your account password as MD5 hash and TUNNELID stays your asigned tunnel id.
For the ip parameter you can either choose your static IPv4 IP or AUTO for dynamic IP updates.

Another interessting option is the following command

ipv6 general-prefix HEv6 2001:470:XXXX::/48

This enables you to use the reference your prefix by calling the “name” of the prefix. The configuration of the loop 2 interface changes accordingly to:

Interface loopback 2
ipv6 address HEv6 ::1/58
 ipv6 enable

Thanks to Karsten for the prefix hint on his blog. (Link)

DE - HEv6 Tunnel Verbesserungen

Nachdem ich noch etwas Zeit in den Foren von HE verbracht hab und auch bei anderen Quellen mich umgesehen habe, will ich hier noch ein paar Verbesserungen einpflegen.

DDNS URL

Derzeit verwende ich die URL wie sie Initial vorgeschlagen wird, aus dem HE Forum habe ich eine neue Form der URL, die verhindert dass das Passwort im Klartext in der Router Konfig steht.

  

https://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&pass=MD5PASS&apikey=USERID&tid=TUNNELID

Dabei ist zu beachten, das im Gegensatz zur original Form, ist der paramter IP mit der statischen IP oder mit AUTO für dynamische IPs zu belegen, sowie die USERID die ID und nicht der Accountname, MD5PASS das Accountpasswort als MD5 Hash und die TUNNELID wie gehabt die Tunnelid des IPv6 Tunnels ist.


Auch interessant ist die Option

Das ermöglicht das Referenzieren in der weiteren Routerkonfiguration auf diesen Präfix. Lässt sich einfacher merken und spricht sich im Zweifelsfall auch einfacher.

ipv6 general-prefix HEv6 2001:470:XXXX::/48

Daraus ergibt sich für das Loop 2 Interface folgende Config

nterface loopback 2

ipv6 address HEv6 ::1/58

 ipv6 enable

 Danke an Karsten bei dem ich mir das Präfix Command geliehen hab. (Link)

EN - Hurricane Electric IPv6 Tunnel with Cisco 887

As mentioned earlier I was playing with the Hurricane Electric IPv6 Tunnel setup. Now that the Tunnel is up and running I would like to share some knowledge I gained and provide a few config sniplets.

Starting with the registration at www.tunnelbroker.net you can request an IPv6 Tunnel. As soon as you´ve registered you can set up your tunnel and register for a complete network with a/48 mask. Obviously to say – I did register for the network.

You can divide configuring your router into 4 steps (more or less)

• Tunnel creation
• Configure HE Tunnel update
• Add the HE Certificate
• Configure and use your /48 network
• testing

The default configuration of HE expects you to have a static IPv4 configured at your router. Well since I’m using a home DSL connection my IP address changes every 24 hours. That´s why I change the tunnel source from IP to dialer 1. 

interface Tunnel0

 description Hurricane Electric IPv6 Tunnel Broker

 no ip address

 ipv6 enable

 ipv6 address 2001:470:xxxx:xxxx::2/64

 tunnel source Dialer 1

 tunnel destination 216.66.84.42

 tunnel mode ipv6ip

ipv6 route ::/0 Tunnel0

Additional to the configuration I added this interface into the appropriate zone of the Zone-Based firewall.

The next step for locations with changing IP addresses is to convince your router to tell HE the changing IPv4 address. Hurricane offers a default URL that you can use for the updating process.

https://ACCOUNTNAME:ACCOUNTPASSWORT@ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID

To update your IP at HE, you can use the DDNS feature of the Cisco router.

ip ddns update method HEv6

 HTTP

  add https://ACCOUNTNAME:ACCOUNTPASSWORT@ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID   !update in next blog post

 interval maximum 0 6 0 0

 interval minimum 0 1 0 0

Every hour but your router will update the IP at HE.

You have to update the configuration of your dialer interface (or the interface that is providing your internet connection) to update HE.

Interface Dialer 1

 ip ddns update hostname WS-Router

 ip ddns update HEv6

Next step is to import the certificate HE is using for the tunnel broker website. Since this page is using a self-signed certificate the update with ddns could cause problems if you don´t import it.

crypto pki trustpoint HEv6

 enrollment terminal pem

 revocation-check none

You need to authenticate the trustpoint using the following dialog:

#crypto pki authenticate HEv6

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

MIID8DCCAtigAwIBAgIJAPF6IlDmmdRhMA0GCSqGSIb3DQEBBQUAMIGcMQswCQYD

VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEQMA4GA1UEBxMHRnJlbW9udDEg

MB4GA1UEChMXSHVycmljYW5lIEVsZWN0cmljLCBMTEMxDTALBgNVBAsTBElQdjYx

GTAXBgNVBAMTEHR1bm5lbGJyb2tlci5uZXQxGjAYBgkqhkiG9w0BCQEWC2lwdjZA

aGUubmV0MB4XDTExMDQyMjE3NDIyMFoXDTIxMDQxOTE3NDIyMFowgZwxCzAJBgNV

BAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRAwDgYDVQQHEwdGcmVtb250MSAw

HgYDVQQKExdIdXJyaWNhbmUgRWxlY3RyaWMsIExMQzENMAsGA1UECxMESVB2NjEZ

MBcGA1UEAxMQdHVubmVsYnJva2VyLm5ldDEaMBgGCSqGSIb3DQEJARYLaXB2NkBo

ZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDe5nza8zQ/AiT+

ySc4mZYmLMcIrcU3q6ZEwIY5vHg2chzCJGCPQIwtBiexSZ7CWL8/GjdPWs6DoCut

DS6VlGGaRhJd0ppUOB3uZLcqnfY0/d40WpRFm49yAV3fmhQg744BKUz2+V23E3tP

n4UXq507dQ3RmNiZoS/T+DUbt1URXFZDIJmc4vjnYfGQhUzhbWZbC7J5fMFnTFSL

NWNou4drWwcApm4FjPfVr+tdanjGEs8bMGSbXo6BjtStiEy1yJ3QGyZLwuURcMMv

DV06/hc2Nv9MZPUaIPvXmNcSuVvY3MJiD1CiCWVmfiO3h7b5EmIWC+ZpO9L3Mk6/

j/MgWR6jAgMBAAGjMzAxMC8GA1UdEQQoMCaCEHR1bm5lbGJyb2tlci5uZXSCEiou

dHVubmVsYnJva2VyLm5ldDANBgkqhkiG9w0BAQUFAAOCAQEAXMG5ZOeyRCzIEPYP

tZKbr1N0CkiBHf+7bVqUqfifEte6S/edpUdzIzB9Wtt484Dt88cAeg4BH2z+Kx2C

lE9PxtTSMCInZIniuoLhaBP0BiRXEurTYdreFmen/S5cCkffVr+eJGk92lQQAdMr

kyz2kD1NCwCaEp1w9DYltDbfC2v8BSIiEKVvD72VW6E2r7AvW73s3+E3WcWbt6pV

qrKfFH4mKH0BR7nLzm5zduojCvIdH3GjelyLd7lUVR3N8Dz626tOzni/bzHpbH3T

dMlBIl3f7c41wcoFG5zSZf1mvgyOnSlOnNmlxMbnfnrIyIyfYz1L8UWqWZGbxJYH

EXcOrA==

Certificate has the following attributes:

       Fingerprint MD5: 1128B641 08E7E271 B2FFB7FF 91411952

      Fingerprint SHA1: 9EB44F27 6BCE5EF6 5D9D38CC A9252276 4318075C

% Do you accept this certificate? [yes/no]: yes

Trustpoint CA certificate accepted.

% Certificate successfully imported

I exported the applied certificate from my browser after opening the tunnelbroker page with Firefox.

The /48 network HE assigned to me was subnetted and applied to my loop 2 interface to check if everything works fine.

Interface loopback 2

ipv6 address 2001:470:XXXX::1/58

 ipv6 enable

Last but not least you should activate domain lookups on your router to resolve the tunnelbroker URL for ddns.

Final testing:

ping ipv6 ipv6.google.com source loop 2

Sending 5, 100-byte ICMP Echos to 2A00:1450:8004::6A, timeout is 2 seconds:

Packet sent with a source address of 2001:470:XXX::1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 76/76/76 ms

YEAH! Everything worked as expected great ! 
More to come here!

DE - Hurricane Electric IPv6 Tunnel mit Cisco 887

Wie schon geschrieben hab ich mich das vergangene Wochenende mit dem IPv6 Tunnel von HE rumgeschlagen. Jetzt da er Up und Running ist will ich meine Erfahrungen mal zusammenfassen und Konfigsniplets preisgeben. 

Fangen wir am Anfang an, die Website ist unter www.tunnelbroker.net  zu finden, die Registrierung ist quasi selbsterklärend und sollte keine Hürde darstellen. Sobald man seinen Tunnel angelegt hat kann man sich auch noch ein Netz /48 reservieren lassen, was ich natürlich gleich gemacht hab. 

Die Konfiguration erfolgt in mehreren Schritten,

• Tunnel aufsetzen
• HE Tunnel update
• HE Zertifikat einspielen
•  /48 Netz verwenden
• Test

Die Konfig des Tunnels geht davon aus, dass man eine statische IP hat und verwendet die IP des Browser in der initialen Konfiguration. Da wir nur einen Standard DSL am Standort haben hab ich die Statische IP durch das Dialer Interface ersetzt, das bei uns die DSL Einwahl macht.  

interface Tunnel0

   description Hurricane Electric IPv6 Tunnel Broker

   no ip address

   ipv6 enable

   ipv6 address 2001:470:xxxx:xxxx::2/64

   tunnel source Dialer 1

   tunnel destination 216.66.84.42

   tunnel mode ipv6ip

ipv6 route ::/0 Tunnel0

Zusätzlich hab ich das Interface noch in die entsprechende Zone der Zone-Base Firewall gehängt.

Als nächstes sollte man, bei dynamische angebundenen Standorten, den Router dazu überreden, bei Zwangstrennung oder IP wechseln die Tunneldaten bei HE zu aktualisieren.

Hurricane gibt dafür eine URL vor, die man vom Router aus aufrufen  kann, die URL hat folgenden Syntax:

https://ACCOUNTNAME:ACCOUNTPASSWORT@ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID

Um Hurricane zu aktualisieren sollte das DDNS feature des Routers verwendet werden:

ip ddns update method HEv6

 HTTP

  add https://ACCOUNTNAME:ACCOUNTPASSWORT@ipv4.tunnelbroker.net/ipv4_end.php?tid=TUNNELID !Update im nächsten Blogpost

 interval maximum 0 6 0 0

 interval minimum 0 1 0 0

Hier wird die dynamische IP meines Routers HE jede Stunde, spätestens nach 6 Stunden mitgeteilt.

 Dem Dialer Interface müssen noch die DDNS Infos mitgegeben werden, damit dieses HE aktualisiert.

Interface Dialer 1

 ip ddns update hostname WS-Router

 ip ddns update HEv6

Als letztes muss noch das Zertifikat von HE hinterlegt werden, da die Tunnelbroker Seite ein selbst signiertes Zertifikat verwendet und das zu Probleme mit dem DDNS Feature führen kann.

crypto pki trustpoint HEv6

 enrollment terminal pem

 revocation-check none

Danach muss der Trustpoint noch authentifiziert werden, der ganze Prozess stellt sich so dar:

crypto pki authenticate HEv6

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

MIID8DCCAtigAwIBAgIJAPF6IlDmmdRhMA0GCSqGSIb3DQEBBQUAMIGcMQswCQYD

VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEQMA4GA1UEBxMHRnJlbW9udDEg

MB4GA1UEChMXSHVycmljYW5lIEVsZWN0cmljLCBMTEMxDTALBgNVBAsTBElQdjYx

GTAXBgNVBAMTEHR1bm5lbGJyb2tlci5uZXQxGjAYBgkqhkiG9w0BCQEWC2lwdjZA

aGUubmV0MB4XDTExMDQyMjE3NDIyMFoXDTIxMDQxOTE3NDIyMFowgZwxCzAJBgNV

BAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRAwDgYDVQQHEwdGcmVtb250MSAw

HgYDVQQKExdIdXJyaWNhbmUgRWxlY3RyaWMsIExMQzENMAsGA1UECxMESVB2NjEZ

MBcGA1UEAxMQdHVubmVsYnJva2VyLm5ldDEaMBgGCSqGSIb3DQEJARYLaXB2NkBo

ZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDe5nza8zQ/AiT+

ySc4mZYmLMcIrcU3q6ZEwIY5vHg2chzCJGCPQIwtBiexSZ7CWL8/GjdPWs6DoCut

DS6VlGGaRhJd0ppUOB3uZLcqnfY0/d40WpRFm49yAV3fmhQg744BKUz2+V23E3tP

n4UXq507dQ3RmNiZoS/T+DUbt1URXFZDIJmc4vjnYfGQhUzhbWZbC7J5fMFnTFSL

NWNou4drWwcApm4FjPfVr+tdanjGEs8bMGSbXo6BjtStiEy1yJ3QGyZLwuURcMMv

DV06/hc2Nv9MZPUaIPvXmNcSuVvY3MJiD1CiCWVmfiO3h7b5EmIWC+ZpO9L3Mk6/

j/MgWR6jAgMBAAGjMzAxMC8GA1UdEQQoMCaCEHR1bm5lbGJyb2tlci5uZXSCEiou

dHVubmVsYnJva2VyLm5ldDANBgkqhkiG9w0BAQUFAAOCAQEAXMG5ZOeyRCzIEPYP

tZKbr1N0CkiBHf+7bVqUqfifEte6S/edpUdzIzB9Wtt484Dt88cAeg4BH2z+Kx2C

lE9PxtTSMCInZIniuoLhaBP0BiRXEurTYdreFmen/S5cCkffVr+eJGk92lQQAdMr

kyz2kD1NCwCaEp1w9DYltDbfC2v8BSIiEKVvD72VW6E2r7AvW73s3+E3WcWbt6pV

qrKfFH4mKH0BR7nLzm5zduojCvIdH3GjelyLd7lUVR3N8Dz626tOzni/bzHpbH3T

dMlBIl3f7c41wcoFG5zSZf1mvgyOnSlOnNmlxMbnfnrIyIyfYz1L8UWqWZGbxJYH

EXcOrA==

Certificate has the following attributes:

       Fingerprint MD5: 1128B641 08E7E271 B2FFB7FF 91411952

      Fingerprint SHA1: 9EB44F27 6BCE5EF6 5D9D38CC A9252276 4318075C

% Do you accept this certificate? [yes/no]: yes

Trustpoint CA certificate accepted.

% Certificate successfully imported

Das eingefügte Zertifikat kann man aus den Browser exportieren, wenn man die DDNS URL manuell aufruft. 

Ich habe das /48 Netz etwas gesubnettet und verwende für den Test das Loop 2 Interface um von einfach zu schauen ob wir Konnektivität haben.

Interface loopback 2

ipv6 address 2001:470:XXXX::1/58

 ipv6 enable

Ach ja zu guter Letzt sofern noch nicht vorhanden, sollte DNS aktiviert sein, schon allein damit die DDNS URL von HE aufgelöst wird.

Abschließender Test:

ping ipv6 ipv6.google.com source loop 2

Sending 5, 100-byte ICMP Echos to 2A00:1450:8004::6A, timeout is 2 seconds:

Packet sent with a source address of 2001:470:XXX::1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 76/76/76 ms

YEAH! Alles schick, mehr kommt hier!

EN - Cisco 887w default open ports! WTF!

The last two nights I was playing with the Hurricane Electric Tunnel setup for one of our routers to get IPv6 to my lab. For some strange reason the tunnel showed that it was up but I was unable to ping the IPv6 IP of Google.com. To track down the issue I used the port scan feature of HE on my public v6 and besides the expected port 22 for tcp the following ports showed up on my 887w: Port tcp 2002, tcp 4002, tcp 6002 and tcp 9002. I tried a telnet and I was really scared when my router replied with a nice telnet prompt.

I goggled for the open ports plus cisco 887w and found the article over at www.dataprotectioncenter.com. It looked like the Line 2 is used to communicate between the router and the wireless controller. This controller was working like a service module in the router. 

The article provided a simple solution that I instantly applied. What was the solution – put an access list on the Line 2 for IPv4 and IPv6. 

I dug a little to the bug database at cisco.com but I couldn´t find anything.

 When I’m back at the office I´ll have a closer look on this particular problem and keep you updated.

Thanks to “Didier Stevens“  for figuring and sharing this issue.

DE - Cisco 887w offene Ports! WTF!

Die letzten zwei Nächte haben meinem 887w Router und Hurricane Electrics IPv6 Tunnel gehört. Ich wollte für mein Lab ein echtes IPv6 Netz haben und habe mir daher einen HE Tunnel auf den Router konfiguriert. Als die Konfig durch war konnte ich leider meine Test Host ipv6.google.com nicht erreichen. Da ich einen Fehler auf meiner Seite ausschließen wollte probierte ich mit dem HE Tool einen Port Scan auf meine Maschine der ziemlich erfolgreich war. 

Leider erfolgreicher als erwünscht da er neben dem erwarteten Port TCP 22 auch die Ports TCP 2002, TCP 4002, TCP 6002 und TCP 9002 als offen anzeigte. Einen kurzen versuch via Telnet später zeigte mir, dass auf den Ports auch wirklich eine hübsche Cisco Telnet Login Aufforderung kam. WTF, wo kommt das den her, ging mir durch den Kopf.

Wie so oft wusste Google Rat und ich fand bei der Suche nach “open ports cisco 887w” eine Artikel bei www.dataprotectioncenter.com. Der lieferte eine grobe Erklärung was dort antwortet, es ist dem Artikel zufolge “Line 2” die dafür genutzt wird, dass man vom Router mit dem Service Module des Wireless Controller kommunizieren kann. Die Lösung die der Artikel anbot ist recht einfach – einfach eine entsprechende access-list auf die “Line 2” binden und schon ist ruhe.

Sobald ich wieder im Büro bin und etwas mehr Zeit hab schau ich mir das Thema noch einmal genauer an. Im Moment mag ich nicht an dem Ast sägen, auf dem ich sitze :D

Wenn ich etwas mehr weiß, melde ich mich.

Ein dickes danke an “Didier Stevens“  von dem der Artikel stammt.

Achja die Cisco BUG DB findet dazu nichts (war ja klar)

DE – Rack Layout

OK ich hab es also wieder nicht wirklich geschafft meinen Zeitplan treu zu bleiben. Aber da ich mit meiner Familie meine Eltern besuchen war hab ich das verlängerte Wochenende für mehr Zeit mit der Familie und weniger Zeit zum Lernen und Bloggen genutzt.

Wie schon im letzten Post erwähnt, hab ich es geschafft mein Lab fertig zu stellen. 

Anbei eine kleine Auflistung der Sachen die ich jetzt verbaut hab und warum sie sich dort befinden :)

HE 1 & 2 - Patch Panels für die Büro Verkabelung – das Rack wird auch im Produktiven Netz benutzt

HE 3 - Cisco 2509 + Oktopus Kabel + AUI Konverter Der Router arbeitet als Terminal Server für alle Lab Geräte

HE 4 - Cisco 2924 – 24 Port Fast Ethernet Switch, als Backbone Switch übernimmt er die L2 Topologie Anbindung der ASAs

HE5 -6 Neat Patch – Kabelführungsgedönst (sehr schick)

HE7 HP ProCurve Switch (non Lab)

HE8 Cisco ASA (BLUE) –ASA OS 8.0.2

HE9 Cisco ASA (GREEN) –ASA OS 8.0.2

HE10 Cisco ASA (RED) –ASA OS 8.0.4 (wird noch angepasst)

Unter den ASAs befindet sich eine etwas ältere Vostro Workstation von Dell, die so umgebaut wurde, das sie nun als VMware Server für die anderen Systeme dient, sprich für ACS, IOU, GNS3 und natürlich auch für die Client Betriebssysteme

Auf der Rückseite des Racks befindet sich eine achtfach Steckdose, mit IP Anschluss, so dass alle Geräte per Webmanagement hoch und runter gefahren werden können.

Sobald ich Zeit hab update ich meine L1/ L2 Topologie und poste sie hier

So long

EN - Rack layout

Once again I´ve been a bit lazy, we´ve been to my parents and I decided to spent more time with my family than blogging (and learning).

But as mentioned earlier I was finally able to cable my rack.

As you can see (hopefully) I´ve got a mixed rack. This means a small part of the stuff is used for productive networking in our office.

I will quickly line out what I´ve used and why, starting from top.

U 1 & 2 - patch panels for the office (non LAB)

U 3 - Cisco 2509 + octopus cable + AUI converter – this router is used to provide console connections to all lab devices

U4 - Cisco 2924 – 24 Port Fast Ethernet switch, not really part of the lab the switch just provides the L2 Structure for the ASAs

U5 -6 Neat Patch – just to keep the rack clean

U7 HP ProCurve Switch (non Lab)

U8 Cisco ASA (BLUE) – Running ASA OS 8.0.2

U9 Cisco ASA (GREEN) – Running ASA OS 8.0.2

U10 Cisco ASA (RED) – Running ASA OS 8.0.4 (need to fix that)

Below – not rack mounted – Dell Vostro 410 Desktop PC modified to work as VM host system with ACS, IOU , GNS3 and some Guest OS to work as clients.

All Lab equipment is attached to an 8 port power outlet that can be managed using a web interface to remotely reboot the stuff in case it fails.

I´ll update the L1 / L2 topology in the next view days and once again post it here.

So long

DE - dynamisches Routeleanking oder "Inter VRF routing"

Dynamisches Route Leaking oder Routing Protokolle fürs Routing zwischen der globales Routingtabelle (GRT) und VRFs

Hallo zusammen,

das letzte mal gab es ein Beispiel, wie man statisch das Routing zwischen 2 VRFs einrichtet und dachte, daß es doch garnicht so schwer sein kann, dies auch dynamisch zu realisieren ... das war reichlich naiv ;)
Nach massig herumprobieren und mit dem Rat von ein paar anderen habe ich ein kleines Lab zusammengebaut, wo Routen zwischen der GRT und einem VRF dynamisch ausgetauscht werden.
Soweit ich es sagen kann, gibt es keine Möglichkeit Routen auf normalem Wege zu redistributen, wenn ein Routingprozess der globale ist. Wenn man es dennoch versucht, bekommt man eine kryptische Fehlermeldung wie diese:
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]

Dies müssen wir einfach "austricksen" und dafür brauchen wir einige Tunnelinterfaces und ein paar Loopbacks

So sieht mein Netzplan aus:


Der globale Client und der VRF_Client werden wieder durch missbrauchte Router dargestellt, die lediglich eine IP haben und eine Default Router auf das ausgehende Interface+Next Hop IP.

grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]

vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]

Nun brauchen wir ein paar Grundkonfigurationen für den VRF Router:

ein vrf erstellen:
ip vrf zif
rd 1:1
route-target both 1:1

Interface config zum grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplex

Interface config zum vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplex

Das alles ist kein Hexenwerk ... bis jetzt ;)

Das erste was wir uns überlegen müssen: wie tricksen wir die Grenzen des Designs aus?

Die erste Zutat sind "Tunnel-Interfaces", die andere sind "Loopbacks".

Unterm Strich brauchen wir:
ein Tunnel-Interface pro VRF,
ein Tunnel-Interface für die GRT
ein Loopback pro VRF und
ein Loopback für die GRT.

Wenn wir mehrere VRFs mit der GRT verknüpfen wollen, brauchen wir entsprechend der obigen Liste das gleiche nochmal pro zusätlichem VRF.

Beide Loopbacks werden in der GRT gelassen:
VRF Router
interface Loopback111
ip address 111.111.111.111 255.255.255.255

interface Loopback222
ip address 222.222.222.222 255.255.255.255

Jetzt brauchen wir die dazugehörigen Tunnel-Interfaces.
Das für die GRT:
interface Tunnel102
ip address 100.100.100.1 255.255.255.0
tunnel source 111.111.111.111
tunnel destination 222.222.222.222
Und das für das VRF:
interface Tunnel201
ip vrf forwarding RED
ip address 100.100.100.2 255.255.255.0
tunnel source 222.222.222.222
tunnel destination 111.111.111.111

Was macht dieses Konstrukt? Wir zeigen mit dem dem Tunnel 201 auf die Loopback in der GRT, mit der Quelle in der GRT und packen das ganze dann ins VRF. Hört sich nicht nur komisch an, es ist komisch (und "fühlt sich komisch an), ABER es funktioniert ;)

Jetzt haben wir schicke Netzwerke, zwischen denen wir ein Routingprozess wie zB OSPF laufen lassen können.

Der globale Routingprozess:
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 100.100.100.1 0.0.0.0 area 0
network 10.10.10.0 0.0.0.255 area 0

Der VRF Routingprozess:
router ospf 2 vrf zif
router-id 20.20.20.20
log-adjacency-changes
network 20.20.20.0 0.0.0.255 area 0
network 102.102.102.2 0.0.0.0 area 0

Die Routing Tabelle schaut danach wiefolgt aus::
global

VRF_Router#sh ip route
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel102
200.200.200.0/32 is subnetted, 1 subnets
C 200.200.200.200 is directly connected, Loopback200
100.0.0.0/32 is subnetted, 1 subnets
C 100.100.100.100 is directly connected, Loopback100
20.0.0.0/24 is subnetted, 1 subnets
O 20.20.20.0 [110/11112] via 102.102.102.2, 00:24:29, Tunnel102
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
vrf

Router#sh ip route vrf zif

Routing Table: zif
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel201
20.0.0.0/24 is subnetted, 1 subnets
C 20.20.20.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 102.102.102.1, 00:26:19, Tunnel201



Und das wars auch schon!
Nun ist es möglich vom grt_host direkt den vrf_host zu pingen und umgekehrt.

Bei Fragen nutzt einfach die Kommentarfunktion

Bis dann,
Zif

DE - IOS HTTP Server "hacking" Vorsorge

So nachdem ich heute 4 Firmen angerufen hab und denen mitgeteilt hab das die Konfiguration Murks ist, poste ich die ganze Geschichte auch noch in deutsch.

Vor kurzem bin ich über eine Suchmaschine gestolpert mit der man auch was finden kann. Dabei ging es aber nicht um den Inhalt der Webseite sondern mehr das drum herum. So war es möglich nach dem Webserver und deren Version zu suchen.

Gesagt getan auf meine suche nach Cisco IOS Webservern erhielt ich über 67.000 Treffer. Ouch,. mal ehrlich 67k wieso müssen die Webinterfaces haben und vor allem warum müssen die via Publik IP Verfügbar sein.

Als ich so durch die liste surfte stellt ich fest das einige nicht mit der 401 sondern mit einer 200 als HTTP Statuscode antworteten. Einen von den Routern angeklickt und schon hat sich gezeigt. Prima die Systeme arbeiten ganz ohne Authentifizierung.

Ich hab die Suchkriterien angepasst und von 67.000 Routern brauchen mehr als 1200 Kein Passwort sind also ungeschützt.

Da es über die Weboberfläche möglich ist ein show cdp neigbor abzusetzen zeigte sich das hinter den Routern noch andere Cisco Komponenten hängen. Ich hoffe das die nicht so lausig konfiguriert sind wie der Router.

Um sicher zu sein, gilt daher entweder eine Access Liste auf den Webserver binden:

access-list 1 permit X.X.X.X ! x.x.x.x= your management network
ip http access-class 1

oder noch besser:

no ip http server


cheers
NWG

EN - IOS HTTP Server hacking prevention

OK I need to post this since this is really scary to me.

A few days ago I stumbled upon a quite cool search engine (no I will not post the URL) what was really interesting is that it did not search for the content of the website it was more interested in the server replies like Server Version HTTP status code.

Since Cisco routers and switches offer a web server for configuration I searched for Cisco IOS servers. The result was scary (it gets worse a bit later) more than 67.000 routers and switches operating the HTTP server are public available. Their may be reasons why routers should be available via HTTP from the Internet but 67000 router people you are kidding me.
I checked some of them and most look like real routers/ switches.

But while browsing the list I found a few routers responding with Cisco IOS Server AND HTTP 200 code. (most of the routers respond with 401 authorization required). I tried one of these and great I could log in and have a look at the configuration passwords etc.

I decided to redefine my search and the result was: from those 67.000 routers 1200 are not requiring authorization of any kind, great.

A quick show cdp neigh showed that most of them I've checked are connected to other Cisco devices. I hope that these devices aren't configured that poorly.

To get out of this list just bind an access list to you HTTP Server,


access-list 1 permit X.X.X.X ! x.x.x.x= your management network
ip http access-class 1


or even better do a

no ip http server


hope some of those guys owning these routers fix them (fast)


Cheers
NWG

EN - Layer 2 redundancy with routers

Yesterday I was playing around with dynamips and found a really cool solution to a problem that well not exists. But after thinking a while I found a situation at a customer location that could make use of my idea.

I'll describe the situation.
The customer has one core switch located in his main building and across his (large) campus a few distribution switches. All switches are layer 2 only so no routing stuff. Since the network small (a view servers and some hand full of workstations) the customer uses one class C subnet (eg 172.20.3.0 /24)
The problem is, the internet access is located near 2 edge switches but far from the main building. So the Edge Router is placed with one WAN interfaces and 2 LAN interfaces one connecting to each edge switch
This looks like this diagram:


So this leads to one obvious question, how do you provide on those LAN interfaces ONE gateway IP (remember no dynamic routing plain default gateway)
The solution is easy: build a bridge group and add a Bridged Virtual Interface (BVI)

How this is done? Just a second I'll show you.
Start with the usual fluff: name, domain, ntp whatever you need and want.

enable
configure terminal

hostname EdgeRouter
ip domain-name playingwithnetworks.com
no ip domain-lookup

line console 0
logging synchronous
password #sicher01
login

line vty 0 4
logging synchronous
password #sicher01
login
transport input telnet


OK you should add of course logging, ntp, ssh security and so on but this would be to much.

Now the next step becomes interesting.
Apply the bridging settings


bridge irb
! enables bridging with routing

bridge 1 protocol ieee
! tells the router what protocol to bridge on bridge group 1

bridge 1 route ip
! tells the router what protocol to route (not what routing protocol )

! configure your LAN interfaces
interface fastEthernet 0/0
description ### LAN Link to EdgeSwitch01 ###
bridge-group 1
! add interface to bridging group 1

! configure your LAN interfaces
interface fastEthernet 0/1
description ### LAN Link to EdgeSwitch02 ###
bridge-group 1
! add interface to bridging group 1

interface BVI 1
description ### routing interface of bridge group 1 ###
ip address 172.20.3.1 255.255.255.0
no shutdown


Next thing you need is to configure the interface to the ISP, this is usual stuff done about a hundred of times and set your default route.

interface Serial0/0
description ### ISP Uplink ###
ip address 172.20.4.2 255.255.255.252
no shutdown

ip route 0.0.0.0 0.0.0.0 Serial0/0 172.20.4.1

Well that's it !!

To verify that all is working, issue a show spanning-tree on your EdgeRouter

Bridge group 1 is executing the ieee compatible Spanning Tree protocol
(…)
Port 3 (FastEthernet0/0) of Bridge group 1 is forwarding
(...)
Port 4 (FastEthernet0/1) of Bridge group 1 is blocking
(…)

By now you know that what we've done is, we've turned the LAN side of our Router into a switch and let spanning tree do the path selection. We could have bought a switching module for our router or created a third single point of failure (1st is only one CoreSwitch, 2nd is only one Edge Router) and set up a physical switch between the edge switches and our router.

DE – SDM mit Dynamips Routern (IINS Vorbereitung)

Das wird ein kurzes Zwischenpost da das Thema an sich recht einfach ist.
Jeder der sich auf den IINS Test von Cisco vorbereitet weiß das der SDM zu den Dingen gehört die zwingend notwendig sind, um bei dem Test was zu erreichen. Wer aber (wie ich) nicht unbedingt so viel Geld in die Hand nehmen will für echte Routerhardware, der nutzt vermutlich Dyanmips, Dynagen bzw GNS3. Doch dann stellt sich die Frage, wie bekommt man den SDM auf einem virtuellen Router zu laufen , dem gehen wir hier nach.

Vorbereitung: In meinem Aufbau, musste ich eine VM meines dynaBuntu anlegen und diese mit dem Router LAB_R001 verbinden (das werden die meisten von euch nicht machen)

Schritt 1: Vorbereitung des Virtuellen Routers mit den üblichen Einstellungen wie Hostnamen Interface IPs etc.

Schritt 2: Einschalten des HTTP Servers des Routers mittels des Befehls

ip http server

Jetzt sollte die Konfiguration des Routers in etwa so aussehen (defaults und unwichtige Informationen wurden raus gelassen)


service password-encryption
!
hostname R_LAB_SDM_01
!
enable secret 5 $1$51xU$t3K/gEBYlwwTYeTEdCqTy/
!
ip domain name playingwithnetworks.com
interface FastEthernet0/0
description ### Link to LAB_R001 and HyperV ###
ip address 172.20.1.3 255.255.255.0
speed 100
full-duplex
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip http server
!
line con 0
password 7 XYZXYZ
logging synchronous
login
line vty 0 4
password 7 YZXZY
logging synchronous
login
transport input telnet


Schritt 3: Eine Kopie des SDM besorgen – das macht sich am besten von der Cisco Seite, wofür aber ein CCO Account gebraucht wird

Zwischenschritt 4: Es ist sicherzustellen das der Router die VM oder den PC erreichen kann und umgekehrt, das funktioniert am besten mit einem Ping zwischen den Geräten..

Schritt 4: Installation des SDM

Welcome Window – klick next
License Agreement – anklicken “I accept the terms of agreement” & klick next
Install Options: - auswählen der Option : “This Computer” & klick next
Choose Destination Location – klick next (oder einen anderen Pfad wählen)
Ready to Install the Program – klick install

Sobald die Installation beendet ist findet sich auf dem Desktop der Workstation ein Icon mit dem Namen: “Cisco SDM” das bitte durch doppelklick starten. Nach Eingabe der guiltigen IP (bei mir 172.20.1.3) sollte folgendes Bild erscheinen (oder so ähnlich)



Das war es erst mal, danke für die Aufmerksamkeit :D

cheers NWG
PS Ein etwas ausführlichers Video zum Thema SDM auf GNS3 von Blindhog.net

EN - SDM on Dynamips Routers (IINS preparation)

This post will be quite short because the topic is pretty easy.
To prepare for the IINS exam you need to have a router with SDM support. If you (like me) don't want to spend the money on real hardware you'll use dynamips/dynagen/gns3.

So how can you run a dynamips router with SDM support. Well this is pretty straight forward
pre-step 1:
In my setup I've had to set up a new dynaBuntu VM and connect this VM to LAB_R001 (you'll probably not have to do this)
Step 1: prepare your router with the usually fluff: set up interfaces, users hostname etc ..
Step 2: add http and if desired https server capability to the router setup

ip http server


The configuration of your dynamips router could look like this (defaults have been skipped) one by now:


service password-encryption
!
hostname R_LAB_SDM_01
!
enable secret 5 $1$51xU$t3K/gEBYlwwTYeTEdCqTy/
!
ip domain name playingwithnetworks.com
interface FastEthernet0/0
description ### Link to LAB_R001 and HyperV ###
ip address 172.20.1.3 255.255.255.0
speed 100
full-duplex
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip http server
!
line con 0
password 7 XYZXYZ
logging synchronous
login
line vty 0 4
password 7 YZXZY
logging synchronous
login
transport input telnet


Step 3: get you copy of the SDM from Cisco (CCO required)

pre-step 4: make sure your dynamips Router can ping your SDM host and vice versa
Step 4:: install the SDM on a PC (or VM)

Welcome Window – click next
License Agreement – select “I accept the terms of agreement” & click next
Install Options: - choose the option: “This Computer” & click next
Choose Destination Location – click next (or select an other location)
Ready to Install the Program – click Install

After the installation has finished you've got a new icon on your desktop called: “Cisco SDM”, double click the icon and enter the IP of your dynamips router. If you've followed this guide you should be able to login to your router via SDM and get something like this screenshot.


Cheers and Thanks for your attention.
NWG

PS a little more detailed movie about the SDM on GNS3 topic, just click to get to the blindhog Video

EN - dynamic routleaking or Inter VRF routing

dynamic route leaking or routing protcols between global routing table (GRT) and VRFs

Hey Everybody,

last time I showed some exampel config for static roue leaking and thought that dynamic routing between GRT and VRF can't be that hard ... how green.
After some hard trys and help from other people I will now show you, how to exchange routes between GRT and VRF-RT dynamicly.
There is no chance to do a normal redistrubution between routing processes if one is the global one.
If you try so, you'll get some cryptic message like
VRF -> GRT [code]%OSPF process 1 is attached to Default-IP-Routing-Table[/code]
GRT -> VRF [code]OSPF process 22 already exists and is attached to Default-IP-Routing-Table[/code]

How ever, now we need to get this tricked. Therefor we use tunnel interfaces and some loopbacks.

This is my tiny topology:


The global Client and the VRF_Client are again just some as host missused routers with one IP address and a default route pointing on the outgoing IF.
grt_host
[code]interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
ip route 0.0.0.0 0.0.0.0 10.10.10.1 FastEthernet0/0[/code]

vrf_host
[code]interface FastEthernet0/1
ip address 20.20.20.20 255.255.255.0
ip route 0.0.0.0 0.0.0.0 20.20.20.1 FastEthernet0/1[/code]

Now are some basic config for the vrf_router needed:

Create a vrf:
ip vrf zif
rd 1:1
route-target both 1:1

Link to grt_host:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
speed 100
full-duplex

Link to vrf_host:
interface FastEthernet0/1
ip vrf forwarding zif
ip address 20.20.20.1 255.255.255.0
speed 100
full-duplex

This all was no rocket science yet, until now ;)

First thing to figure out: how to outsmart the limitations of design?

One credential are "Tunnel-Interfaces", an other one "loopbacks".

In sum we need one tunnel-IF per VRF and GRT plus one loopback for each.

Both loopbacks are left in GRT:
VRF Router
interface Loopback111
ip address 111.111.111.111 255.255.255.255

interface Loopback222
ip address 222.222.222.222 255.255.255.255

Now we need the correspondent tunnel IFs.
The global one:
interface Tunnel102
ip address 100.100.100.1 255.255.255.0
tunnel source 111.111.111.111
tunnel destination 222.222.222.222
And the VRF one:
interface Tunnel201
ip vrf forwarding RED
ip address 100.100.100.2 255.255.255.0
tunnel source 222.222.222.222
tunnel destination 111.111.111.111

What this is doing: pointing with the tunnel 201 to a GRT loopback with a source in GRT putting itself in a VRF. It sounds, strange, it looks strange, it feels strange, BUT it works ;)

Now you have sweet networks which you can add to routing processes like OSPF.

The global routing process:
router ospf 1
router-id 10.10.10.10
log-adjacency-changes
network 100.100.100.1 0.0.0.0 area 0
network 10.10.10.0 0.0.0.255 area 0

The VRF routing process:
router ospf 2 vrf zif
router-id 20.20.20.20
log-adjacency-changes
network 20.20.20.0 0.0.0.255 area 0
network 102.102.102.2 0.0.0.0 area 0

The routintg tables looks like this:
global

VRF_Router#sh ip route
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel102
200.200.200.0/32 is subnetted, 1 subnets
C 200.200.200.200 is directly connected, Loopback200
100.0.0.0/32 is subnetted, 1 subnets
C 100.100.100.100 is directly connected, Loopback100
20.0.0.0/24 is subnetted, 1 subnets
O 20.20.20.0 [110/11112] via 102.102.102.2, 00:24:29, Tunnel102
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
vrf

Router#sh ip route vrf zif

Routing Table: zif
[...snip...]

Gateway of last resort is not set

102.0.0.0/24 is subnetted, 1 subnets
C 102.102.102.0 is directly connected, Tunnel201
20.0.0.0/24 is subnetted, 1 subnets
C 20.20.20.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O 10.10.10.0 [110/11112] via 102.102.102.1, 00:26:19, Tunnel201


And thats it! Now you are able to ping from you grt_host straight through the vrf_host.

For questions just use the comments.

so long,
Zif

EN - Upcomming: dynamic route leaking or routing protcols between global routing table (GRT) and VRFs

Hey everyone,

due to NWG asked me for this I started investigation about a way to do some dynamic redistribution between a VRF and the GRT. Everyone trying to solve this by a simple "redistribute" command in the routing process knows, thats that is not the way ;)

At the moment I am preparing the entry for this blog. At this point big thanks to "conspathas" from the dynamip forum for his time explaining this way.

See ya soon,
Zif

Update 09-07-10: due to heavy load @work there is a delay in publication, please stand by :)

EN/DE - Configuration Registers on Routers

Hey out there,

due to I stubled over some wrong set config registered in last time and had not all settings in mind, I found a nice cisco document revealing the secrets about the crytic hex values:

Use of the Configuration Register on All Cisco Routers

Have fun with it,
Zif

---

Hallo zusammen,

letztens bin ich bei einem Kunden über falsch gesetzte config registers gestolpert und da ich mir nicht sämtliche Werte merken kann, habe ich ein schickes Cisco-Dokument gefunden, welches die Bedeutung hinter den kryptischen Hex-Zahlen verrät:

Use of the Configuration Register on All Cisco Routers

Habt Spaß damit,
Zif

EN - "Route Leaking" or Inter VRF routing

Heyho,

today I want to give a small guide, how to configure inter-VRF (VRF = VPN Routung and Forwarding) routing.
The Cisco documentation I found for this is more likely rocket science than a working guide.

The task was to implement static routes on one device routing between different VRFs.
I used following network map:

Both routers "VRF_1" and "VRF_2" are only hosts with only an IP and a default route pointing at the outgoin interface:
VRF1

interface FastEthernet0/1
description Link to VRF_Router
ip address 10.0.100.2 255.255.255.0
speed 100
full-duplex
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

VRF2

interface FastEthernet0/1
 description Link to VRF_Router
 ip address 10.0.200.2 255.255.255.0
 speed 100
 full-duplex
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1

Now to the routing part:
At first you need an basic VRF lite config:

ip vrf vrf1
rd 1:1
route-target export 1:1
route-target import 1:1
!
ip vrf vrf2
rd 2:2
route-target export 2:2
route-target import 2:2

The two commands route-target export 2:2 and route-target import 2:2 can be summed up with the command "route-target both. In your config this will be automaticaly replaced with to commands shown.

In addition to this there is some IF configuration:

interface FastEthernet0/0
ip vrf forwarding vrf1
ip address 10.0.100.1 255.255.255.0
speed 100
full-duplex
!
interface FastEthernet0/1
ip vrf forwarding vrf2
ip address 10.0.200.1 255.255.255.0
speed 100
full-duplex

The command ip vrf forwarding [vrf_name] associates the IF into a VRF so the traffic is marked up.

Now you need to set up the routing. There for you only need a route for each VRF pointing on the IF and Next-Hop-IP of the targeted VRF.

ip route vrf vrf1 10.0.200.0 255.255.255.0 FastEthernet0/1 10.0.200.2

ip route vrf vrf2 10.0.100.0 255.255.255.0 FastEthernet0/0 10.0.100.2

And thats all. If you issue the command show ip route.

VRF_Router#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

VRF_Router#

You'll see an empty global routing table. If you add show ip route vrf [vrf_name]. As example only the output of one vrf:

VRF_Router#show ip route vrf vrf1

Routing Table: vrf1

[... snip ...]

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
C 10.0.100.0 is directly connected, FastEthernet0/0
S 10.0.200.0 [1/0] via 10.0.200.2, FastEthernet0/1
VRF_Router#

Note that it says explictly which routing table it's showing you and you have one extra routing table for each VRF.




If there are any open questions left, just use the commenting funtion


Regrads,
Zif

DE - Task 2.2.1 hinzufügen der VPN Edge Geräte

Entschuldigung, dass das letzte Post zum Thema so lang her ist, ich hoffe es stört nicht allzu sehr. Prinzipiell sind die Konfigs fertig nur das dokumentieren nervt furchtbar :)
Wir fangen mit unserem Netzwerk aus dem letzten Task an, das heißt wir haben 3 Router und eine PIX die untereinander OSPF sprechen (LINK).

Zuerst werden wir die VPN Endgeräte hinzufügen, so das wir später unser Sicherheitskonzept auf das ganze Netzwerk ausrollen können.

Die Router sind an sich sehr einfach konfiguriert und ich werde nicht tiefer darauf eingehen. Wir konfigurieren wie übliche, die Interfaces für externe und interne Kommunikation, OSPF und zum Schluss sollten wir einen blick auf die anderen Router werfen ob die Routen alle sauber übertragen werden.
Näheres zum Konfigurieren der Router lässt sich unter Task 2.1 finden.

VPN Edge Router 1 - R_VPN_1

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R_VPN_1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
no logging console
no logging monitor
!
memory-size iomem 5
ip cef
!
no ip domain lookup
ip domain name Task2.local
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
interface Loopback0
description ### Loop 0 for MGMT ###
ip address 10.99.99.4 255.255.255.255
!
interface FastEthernet0/0
description ### Uplink ISP 1 ###
ip address 192.168.11.2 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet0/1
description ### Uplink ISP 2 ###
ip address 192.168.22.2 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet1/0
description ### Uplink to R_Outer_Core_1 ###
ip address 10.1.0.2 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet2/0
description ### Uplink to R_Outer_Core_2 ###
ip address 10.1.0.10 255.255.255.252
speed auto
full-duplex
!
router ospf 100
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.0.0 0.0.0.3 area 0
network 10.1.0.8 0.0.0.3 area 0
network 10.99.99.4 0.0.0.0 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.11.1
ip route 0.0.0.0 0.0.0.0 192.168.22.1 10
!
ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
ntp server 10.99.99.1 prefer

VPN Edge Router 2 - R_VPN_2

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R_VPN_2
!
no logging console
no logging monitor
!
no aaa new-model
memory-size iomem 5
ip cef
!
no ip domain lookup
ip domain name Task2.local
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
interface Loopback0
description ### Loop 0 for MGMT ###
ip address 10.99.99.5 255.255.255.255
!
interface FastEthernet0/0
description ### Uplink ISP 1 ###
ip address 192.168.11.3 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet0/1
description ### Uplink to ISP 2 ###
ip address 192.168.22.3 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet1/0
description ### Uplink to R_Outer_Core_1 ###
ip address 10.1.0.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet2/0
description ### Uplink to R_Outer_Core_2 ###
ip address 10.1.0.14 255.255.255.252
speed 100
full-duplex
!
router ospf 100
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.0.4 0.0.0.3 area 0
network 10.1.0.12 0.0.0.3 area 0
network 10.99.99.5 0.0.0.0 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.11.1
ip route 0.0.0.0 0.0.0.0 192.168.22.1 10
!
!
no ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
ntp server 10.99.99.1 prefer

Das war es im großen und ganzen, wir haben nun 5 Router und eine PIX, auf diesem Netzwerk Sicherheit zu implementieren ist etwas aufwändiger und bekommt daher einen eigenen Blogeintrag.

cheers
NWG

EN - Task 2.2.1 adding VPN Edge devices

Well it has been a while since the last task update and I hope you don´t mind to much.
So we start with our network from last time, this means 3 routers and a pix running OSPF. (LINK)

First of all we will add the two VPN Edge devices, so that we can build security concept for the complete network.
The Routers are set up quit easily and i won´t explain in detail what to do on those machines. We will do the usual stuff like setting up network interfaces for internal and external communication, add OSPF and have a look on the other routers to see if the routes are propagated as expected. Fore more information about see the Task 2.1 Post.

VPN Edge Router 1 - R_VPN_1

service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R_VPN_1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
no logging console
no logging monitor
!
memory-size iomem 5
ip cef
!
no ip domain lookup
ip domain name Task2.local
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
interface Loopback0
description ### Loop 0 for MGMT ###
ip address 10.99.99.4 255.255.255.255
!
interface FastEthernet0/0
description ### Uplink ISP 1 ###
ip address 192.168.11.2 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet0/1
description ### Uplink ISP 2 ###
ip address 192.168.22.2 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet1/0
description ### Uplink to R_Outer_Core_1 ###
ip address 10.1.0.2 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet2/0
description ### Uplink to R_Outer_Core_2 ###
ip address 10.1.0.10 255.255.255.252
speed auto
full-duplex
!
router ospf 100
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.0.0 0.0.0.3 area 0
network 10.1.0.8 0.0.0.3 area 0
network 10.99.99.4 0.0.0.0 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.11.1
ip route 0.0.0.0 0.0.0.0 192.168.22.1 10
!
ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
ntp server 10.99.99.1 prefer

VPN Edge Router 2 - R_VPN_2

service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R_VPN_2
!
no logging console
no logging monitor
!
no aaa new-model
memory-size iomem 5
ip cef
!
no ip domain lookup
ip domain name Task2.local
!
multilink bundle-name authenticated
!
archive
log config
hidekeys
!
interface Loopback0
description ### Loop 0 for MGMT ###
ip address 10.99.99.5 255.255.255.255
!
interface FastEthernet0/0
description ### Uplink ISP 1 ###
ip address 192.168.11.3 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet0/1
description ### Uplink to ISP 2 ###
ip address 192.168.22.3 255.255.255.128
speed 100
full-duplex
!
interface FastEthernet1/0
description ### Uplink to R_Outer_Core_1 ###
ip address 10.1.0.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet2/0
description ### Uplink to R_Outer_Core_2 ###
ip address 10.1.0.14 255.255.255.252
speed 100
full-duplex
!
router ospf 100
log-adjacency-changes
redistribute connected subnets
redistribute static subnets
network 10.1.0.4 0.0.0.3 area 0
network 10.1.0.12 0.0.0.3 area 0
network 10.99.99.5 0.0.0.0 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.11.1
ip route 0.0.0.0 0.0.0.0 192.168.22.1 10
!
!
no ip http server
no ip http secure-server
!
control-plane
!
line con 0
line aux 0
line vty 0 4
!
ntp server 10.99.99.1 prefer

Well thats it for now. Since adding security to those devices is a larger task I´ll create a new blog post about this topic.

cheers NWG