Lan-to-Lan loopback auf Firewall

[r4z13l 12]

Hallo Zusammen,

 

wir haben mit einem Kunden eine L2L-VPN Verbindung aufgebaut.

Dies funktioniert auch problemlos. Nur einen kleinen Schönheitsfehler hat das ganze noch...

 

Wir überwachen gegenseitig das Gateway, also ob der VPN-Tunnel noch steht (wir: OpenNMS, Kunde: Nagios).

Auf unserer Seite ist eine PIX515E:

Cisco Pix Security Appliance Software Version 8.0(2)

Device Manager Software 6.0(2)

 

Von unserer Seite aus (192.168.0.173 = OpenNMS-Server) kann ich das Gateway des Kunden (192.168.200.249) pingen. Wenn er von seinem Nagios-Server (192.168.200.254) unser Gateway (192.168.0.251) pingen möchte bekommt er keine Antwort.

 

Das Problem ist, dass unsere Pix nicht auf dem selben Interface antwortet. Ich benötige also soetwas wie ein Loopback-Interface.

Jedoch, so wie ich das verstehe ist ein Loopbackinterface nur auf einem Router, nicht auf einer Firewall verfügbar.

 

Auch eine Konfigurationsvorlage die ich im Internet gefunden habe bei der das Problem mit NAT gelöst wird, hat bei mir leider nicht funktioniert (https://supportforums.cisco.com/thread/2038631).

 

Ich hoffe Ihr könnt mir weiter helfen. Sollten noch angaben fehlen, stelle ich diese gerne bereit.

 

Vielen Dank für eure Antworten :)

 

lg r4

[XP-Fan 217]

Hallo und herzlich Willkommen an Board,

 

damit sich entfernte Geräte erreichen können durch einen Tunnel müssen diese den Weg dahin kennen.

 

Am einfachsten ist es wenn die Gateways der Systeme den Tunnel untereinander aufbauen,

dann finden die Clients in den Netzen die Gegenseiten automatisch da das Gateway für das

entfernte Netzwerk befragt wird und dieses kennt.

 

Wenn aber nicht das default Gateway genutzt wird sondern eine extra Verbindung so müssen

den Clients diese Infos mittels Routing vermittelt werden.

 

Am einfachsten ist es am default Gateway eine Route für das entfernte Netzwerk einzutragen wobei das Gateway zum entfernten Netz eingetragen wird.

 

Sollen nur einzelne Systeme das entfernte Netz erreichen so hinterlege nur auf diesen die

Route mit den entsprechenden Informationen.

 

So wie es sich für mich darstellt ist es bei euch auf der Seite das Default Gateway für euer Netzwerk,

die Gegenseite hat wol ein anderes Default Gateway im Netzwerk.

 

Hope that Helps :)

[r4z13l 12]

hmmm, ich glaube ich habe mich nicht genau genug ausgedrückt:

 

Der VPN-Tunnel steht, unsere Clients kommen ohne Probleme auf die Kundensysteme und der Kunde kommt ohne Probleme an unsere Drucker.

 

Ich kann mit meinem OpenNMS sein VPN-Router überwachen, er mit seinem Nagios-Server aber nicht unsere Firewall.

 

Soweit ich das richtig verstehe, kann unsere Firewall nicht auf dem selben Interface routen, darum die Idee mit dem Loopback-Interface auf der Firewall.

 

Also alles funktioniert nur das pingen vom Kunden auf unsere inside-IP der Firewall geht nicht.

[Otaku19 33]

ist denn die IP in der crypto domain drin ? ist die fiorewall so konfiguriert das sie auch auf pings antwortet ? Sollten sich die Tunnel stati nicht einfach via SNMP von euren eigenen Firewalls abgefragt werden können ?

[r4z13l 12]

hier mal die betreffenden config-zelen:

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.200.0 255.255.255.0 

access-list outside_6_cryptomap extended permit ip 192.168.0.0 255.255.255.0 192.168.200.0 255.255.255.0 
access-list xxxFilter extended permit ip object-group DM_INLINE_NETWORK_1 object-group DM_INLINE_NETWORK_2 

access-list xxxFilter extended permit object-group DM_INLINE_SERVICE_1 host 192.168.200.249 host 192.168.0.173 
access-list xxxFilter remark Nagios auf PIX
access-list xxxFilter extended permit object-group DM_INLINE_SERVICE_2 host 192.168.200.254 host 192.168.0.251 

 

In der DM_INLINE - Gruppen stehen die betroffenen IP-Adressen

bearbeitet 5. September 2011 von r4z13l

[Otaku19 33]

sagt mir so...genau garnix. welche davon ist für in der crypto-map gebunden und ist da die IP der FW die überwacht werden soll drin ?

[r4z13l 12]

object-group network DM_INLINE_NETWORK_1
network-object host 192.168.200.33
network-object host 192.168.200.34

object-group network DM_INLINE_NETWORK_2
network-object host 192.168.0.100
network-object host 192.168.0.106
network-object host 192.168.0.108
network-object host 192.168.0.126
network-object host 192.168.0.150
network-object host 192.168.0.156
network-object host 192.168.0.159
network-object host 192.168.0.199
network-object host 192.168.0.226
network-object host 192.168.0.235
network-object host 192.168.0.41
network-object host 192.168.0.49
network-object host 192.168.0.51
network-object host 192.168.0.55
network-object host 192.168.0.128
network-object host 192.168.0.211
network-object host 192.168.0.234

object-group network DM_INLINE_NETWORK_3
network-object host 192.168.200.18
network-object host 192.168.200.19
network-object host 192.168.200.250
network-object host 192.168.200.251
network-object host 192.168.200.252
network-object host 192.168.200.35
network-object host 192.168.200.37
network-object host 192.168.200.7
network-object host 192.168.200.36

object-group network DM_INLINE_NETWORK_4
network-object host 192.168.0.120
network-object host 192.168.0.148
network-object host 192.168.0.175
network-object host 192.168.0.176
network-object host 192.168.0.177
network-object host 192.168.0.48
network-object host 192.168.0.149

object-group service DM_INLINE_SERVICE_1
service-object ip 
service-object tcp eq echo 

object-group service DM_INLINE_SERVICE_2
service-object ip 
service-object tcp eq echo 


access-list inside_nat0_outbound remark xxx
access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.200.0 255.255.255.0 

access-list outside_6_cryptomap extended permit ip 192.168.0.0 255.255.255.0 192.168.200.0 255.255.255.0 
access-list xxxFilter remark ... und ... auf Arbeitsstationen
access-list xxxFilter extended permit ip object-group DM_INLINE_NETWORK_1 object-group DM_INLINE_NETWORK_2 
access-list xxxFilter remark ... auf Drucker
access-list xxxFilter remark Zugriff von ... auf Drucker
access-list xxxFilter extended permit ip object-group DM_INLINE_NETWORK_3 object-group DM_INLINE_NETWORK_4 
access-list xxxFilter remark OpenNMS auf xxx VPN-Router
access-list xxxFilter extended permit object-group DM_INLINE_SERVICE_1 host 192.168.200.249 host 192.168.0.173 
access-list xxxFilter remark Nagios auf PIX
access-list xxxFilter extended permit object-group DM_INLINE_SERVICE_2 host 192.168.200.254 host 192.168.0.251 

crypto map outside_map 6 match address outside_6_cryptomap
crypto map outside_map 6 set peer xxx.xxx.xxx.xxx 
crypto map outside_map 6 set transform-set ESP-3DES-SHA
crypto map outside_map 6 set nat-t-disable

 

192.168.200.254 soll auf 192.168.0.251 zugreifen können (per ping)

[Otaku19 33]

192.168.0.251 ist dann aber die inside IP der FW...und des geht net

[r4z13l 12]

richtig, darum will ich ja soetwas wie ein Loopback-Interface. Einfach ein virtuelles Interface auf der Firewall dem ich eine IP zuweisen kann.

 

Das war ja meine ursprüngliche Frage, wie ich soetwas realisieren kann.

[Otaku19 33]

nein,das geht nicht :) crypto domain ändern

[r4z13l 12]

ich habe nun eine funktionierende Lösung:

Cisco ASA remote management via VPN | Booches.nl

 

Vielen Dank für eure Mühen! :)

[hegl 10]

ich habe nun eine funktionierende Lösung:

Cisco ASA remote management via VPN | Booches.nl

 

Vielen Dank für eure Mühen! :)

 

Vielen Dank für Deine Mühen - da suche ich schon äußerst lange dran. :):):)

[Otaku19 33]

hm, wusste nur das man damit den ASDm/CLI Access erlauben kann, nicht das da auch auf icmp reagiert wird :)

[r4z13l 12]

freut mich, dass anderen die Lösung ebenfalls hilft :)