Cisco Ipsec Tunnel zu Root weitere externe netze

[gierig]

Smalltalk sollte fein sein, da doch eher CISCO Lastig (hoff ich)

Was ich möchte:
Das Telekom 217.0.x.x Netz auf dem Root Server verfügbar machen
Da befinden sind die SIP Server die nur aus dem Telekom Netz erreichbar sind.
Ich möcht aber den Localen Asterisk abschaffen und meinen zentralen
nehmen der auf dem Root als VM bestens Läuft.

Tunnel für Locales Netz -> Root Server läuft wunderbar.
Also kein Generelles Problem und die grundlegenden Sachen sind
Verstanden um nen CISCO Router an Openswan zu flanschen.
Erweitere ich den Tunnel nach meinen Gedanken einfach um
die Telekom IPs dann leuft dieser immer noch fein. Sehe auch
in den Access Listen Traffic aber bekomme trozdem kein Connect.
Es scheint als Wenn nach dem Tunnel nicht weiter ins Inet geleitert wird.

ROOT Server:
10.0.0.0/24
Hier laufen ein Paar VMs die über die üblichen Prerouting Iptables
Weiterleitungen Angebunden sind. (auf dem Host hängt ein Bridge interface auf
die TAP Devices der KVMs) Raus über ne PNAT Regel (MASQUERADE)

Openswan:

Code: Select all

conn Cisco
	type=tunnel
        authby=secret
        left=85.214.xx.xx
	leftsourceip=10.0.0.1
        leftsubnet=10.0.0.0/24
        right=xxxx.dyndns.org
        #rightsubnet=192.168.1.0/24
	rightsubnets={ 192.168.1.0/24 217.0.0.0/16 }
	Keyexchange=ike
	ikelifetime=3600s
	ike=aes256-sha1-modp1024
	phase2alg=aes256-sha1
	pfs=yes
        auto=start
#      auto=add

bei Itables vielleicht zu erwähnen. Die IPSEC Destinations dürfen nicht über PNAT Laufen, da sie duch den Tunnel sollen mit Ihrer Absender IP.

Code: Select all

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d 217.0.0.0/16  -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Heim Netz:
192.168.1.0/24. Router Cisco 876w (12.4(24)T1, advIP)
DSL über das ATM iNterface, mit der dem Üblichen Dialer Interface.
Raus dann über über die "ip inspect" Firewall und

Code: Select all

ip nat inside source route-map PNAT interface Dialer0 overload

die Map hat nur die AccessListe hier als Inhalt

Code: Select all

ip access-list extended LOCAL-PNAT-VPN-EXTERN
 remark ----> deny traffic that should flow through IPSEC Tunnel    
 deny   ip any 10.0.0.0 0.0.0.255
 remark ----> any other local traffic should PNat as well
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip 10.0.0.0 0.0.0.255 any

Dazu die Match liste für den IPSEC Tunnel

Code: Select all

ip access-list extended VPNTRAFFIC
 remark ----> crypto map "IPSEC"
 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255
 permit ip 217.0.0.0 0.0.255.255 10.0.0.0 0.0.0.255

Wie gesagt Kommunikation zwischen 192.168.1.0/24 und 10.0.0.0/24
leuft perfect.
Wenn ich das 217.0.x.x vo Root Ereichen will gehts auch über den Tunnel.
Aber ich da stockt es dann.

Code: Select all

Extended IP access list VPNTRAFFIC
    10 permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 (8 matches)
    20 permit ip 217.0.0.0 0.0.255.255 10.0.0.0 0.0.0.255 (6 matches)

Hier weis ich einfach nicht weiter. Jemand Ideen dazu ?

[nyxus]

Das sieht sehr nach eienm lokalen-NAT-Problem aus. Auf Deienem Dialer0 hast Du ein "ip nat outside", aber das ist auch das Interface uber den der NAT-Traffic vom Rootserver einäuft. Und was nichts mit dem Problem zu tun hat: Dein IOS sollte mal wieder upgedated werden ...

Lösungsmöglichkeiten:
1) Wenn OpenSwan inzwischen route-based VPNs kann, dann könntest Du lokal auf VTIs umstellen und hast damit einen dedizierten Tunnel den Du für NAT mit "ip nat inside" konfigurieren kannst.
2) Migration auf NVI-NAT. Dabei entfällt bei der NAT-Regel das "source", auf den Interfaces wird NAT einfach mit "ip nat enable" eingeschaltet. Die route-map müsstest Du dabei gegen eine ACL ersetzen.
3) NAT on a stick. Nein, das willst Du nicht wirklich ...

[gierig]

Hallo und ein Frohes Neues Erstmal.

Das sieht sehr nach eienm lokalen-NAT-Problem aus. Auf Deienem Dialer0 hast Du ein "ip nat outside", aber das ist auch das Interface uber den der NAT-Traffic vom Rootserver einäuft. Und was nichts mit dem Problem zu tun hat: Dein IOS sollte mal wieder upgedated werden ...

Das macht sinn und ja ein update macht auch sinn. Werde ich mich mal die Tage drum kümmern. Mein Handler der mich
da unterstützt hat (ist ja für Privat) ist nicht mher... aber das ist ein anderes Thema :-)

1) Wenn OpenSwan inzwischen route-based VPNs kann, dann könntest Du lokal auf VTIs umstellen und hast damit einen dedizierten Tunnel den Du für NAT mit "ip nat inside" konfigurieren kannst.
2) Migration auf NVI-NAT. Dabei entfällt bei der NAT-Regel das "source", auf den Interfaces wird NAT einfach mit "ip nat enable" eingeschaltet. Die route-map müsstest Du dabei gegen eine ACL ersetzen.
3) NAT on a stick. Nein, das willst Du nicht wirklich ...

Machen mir mal Rückwerts.

3.) Nicht sicher Was du Meinst damit, klingt aber so als wenn das nicht in frage kommt.
2.) Danke, jetzt habe ich was zu lesen wie das genauer Funktionier, das ist wirklich interesant.
1.) Bingo. Also fast. VTI soweit ich nun gelesen / Verstanden habe würde gehen wenn ich Openswan ein wenig Patche
(geht wohl Haubtsächlich um das Startscript). Aber mit dem hinweis hast du schonmal ne Kerbe geschlagen.

Nen Dedenzirten Tunnel über nen GRE Tunnel. Sollte so laufen lässt sich verschlüssen und wenn der erstmal steht
quasi Wartungsfrei denn ich kann einfach über normale Statische Routen das Transfernett ansprechen und
mir damit die Zielnetze anderes Routen lassen

Danke soweit.

Ich setzt mich jetzt hin mach mich auf Linux Seite über GRETunnel schlau :-)

Danke Nochmals

[nyxus]

GRE musst Du dafür nicht extra machen, da Du vermutlich nichts anderes als IPv4 transportieren willst. Daher kannst Du einen einfachen IPv4-IPSec-Tunnel nehmen. Das ist das, was bei Cisco die VTIs standardmäßig sind.

GRE käme in Frage, wenn Du über einen Tunnel sowohl v4 und v6 gleichzeitig übertragen willst. Das geht im IOS bisher nicht ohne GRE.

Eine Router-Konfig würde dabei folgendermaßen aussehen (ISAKMP so wie schon vorhanden):

Code: Select all

crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac
crypto ipsec profile IPSEC-PROFILE
  set transform-set ESP-AES-SHA
!
interface Tunnel 0
  ip address 10.11.11.1 255.255.255.252
  tunnel source Dialer0
  tunnel destination 1.2.3.4
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile IPSEC-PROFILE

[gierig]

GRE musst Du dafür nicht extra machen, da Du vermutlich nichts anderes als IPv4 transportieren willst. Daher kannst Du einen einfachen IPv4-IPSec-Tunnel nehmen. Das ist das, was bei Cisco die VTIs standardmäßig sind.

Ja IPv4 würde (momentan) reichen. ein VT Interface wäre durchaus das Optimalste. Liest sich auf Cisco Seite sehr gut
und verständlich in meinen Augen.

Allerdings scheint Linux (3.2x Kernel) bzw. Openswan kein VTI Tunnel zu unterstützen. (erst mit 3.6.x)
Damit bleibt dann quasi nur der weg über ein GRE Interface/Tunnel.

Wobei ich bin noch am suchen/lesen die Informationen auf Linux Seite sind da ein wenig arg verstreut.
Es gibt da ein paar Announcments (die sich alle auf Kernel ab 3.6 beziehen).

Ansonsten werde ich es mal damit versuchen wenn ich die tage wieder in der Heimat bin.

[gierig]

Mein Dank an an Karsten der mich überhabt dazu gebracht hat an ein Tunnel Interface und normales Routing zu verwenden.
Das klappt nun wunderbar.

auf Cisco

Code: Select all

interface Tunnel0
 ip address 10.99.99.1 255.255.255.252
 ip nat inside
 ip virtual-reassembly
 tunnel source Dialer0
 tunnel destination 85.214.x.x

und natürlich die iP Route fürs ziel netz.

IPSEC crypto map dann wie oben, blos die match Map mus so ausehen.

Code: Select all

ip access-list extended VPNTRAFFIC
 remark ----> crypto map "IPSEC"
 permit gre any host 85.214.xx.xx

Also Im Prinzip nur den GRE Tunnel Traffic Verschlüsseln.
(ja ich weiß ganz sauber ist das nicht any zu erlauben, aber damit umgehe ich die Änderung bei IP Wechsel bei mir & und auf mein INbound
access list auf dem dialer lass ich GRE dann nur vom root zu)



auf Linux Seite:
Der Tunnel Selber.
Hier lauert dann auch einzige Stolperstein. Das hier ins zwar für für nen Debian Style Interface Config.
Aber auch hier wird im Endeffekt "iptunnel" aufgerufen das in meiner Version kein HOST Name für den Remote akzeptiert.
Wegen Dynamischer IP wäre hier nen Host name Wünschenswert. Damit mein Montierung das Interface einfach nur durchstarten Mus
wenn der Tunnel nicht mehr steht (macht es eh schon für IPSEC)

Lösung: erstmal quick and Dirty, das Monitoring triggert ein script das über sed/grep/cut die Remote IP in der Interfaces aktualisiert.
bevor ich den Tunnel neu starte. und mal in ruhe nach alternativen suchen :-)

(ein schnelles GREP / SED Script)

Code: Select all

iface tun0 inet tunnel
    address 10.99.99.2
    netmask 255.255.255.252
    dstaddr 10.99.99.1
    mode Ger
    local 85.214.xx.xx     
    endpoint 87.xx.xx.xx  
    up route add -net 192.168.1.0/24 gw 10.99.99.1
    up route add -net 217.0.0.0/16 gw 10.99.99.1
    down route del -net 192.168.1.0/24 gw 10.99.99.1
    down route del -net 217.0.0.0/16 gw 10.99.99.1 

ach ja... die Routen werden auch noch angelegt..


Ipsec:
HIer dann über left/rightprotoport GRE als zu schützenden traffic deklarieren.

Code: Select all

conn Cisco2
	type=tunnel
        authby=secret
        left=85.214.xx.xx
	leftprotoport=gre
        right=dynsndadresse
	rightprotoport=gre 
	Keyexchange=ice
	ikelifetime=3600s
	ike=aes256-sha1-modp1024
	phase2alg=aes256-sha1
	pfs=yes
        auto=start

DANKE.