2
Routing in ein anderes internes Subnetz mit Cisco PIX 501
Hallo,
wir haben zwei Gebäude über eine WLAN-Bride (DD-WRT) miteinander verbunden (nicht perfekt, ich weiß - aber funktioniert). Die Bridge funktioniert also wunderbar. Im "Hauptnetz" (N1) haben wir 192.168.0.0/24 und im anderen Gebäude (N2) 192.168.0.2/24.
Im Hauptnetz N1 steht die Cisco PIX und routet bisher via SDSL ins Internet.
In N2 steht ein Router mit Debian (keine Ahnung davon, da lass ich die Finger von), der so konfiguriert ist, das er alles was drüben ins Internet will über eine eigene SDSL-Leitung ins Netz schickt und alles was nach 192.168.0.0/24 will über die WLAN-Bridge routet.
Clients in N1 haben feste IPs:
IP: 192.168.0.1 - 192.168.0.99
Gateway: 192.168.0.254 (das ist die PIX)
Clients in N2 bekommen via DHCP folgendes:
IP: 192.168.2.100 - 192.168.2.199
Gateway: 192.168.2.1 (das ist der Debian-Server)
(Der Debian-Server ist auf der anderen Seite auch unter 192.168.0.251 zu erreichen)
Wenn ich nun an meinem Client (Windows Vista) via CMD eine route hinzufüge:
route add 192.168.2.0 mask 255.255.255.0 192.168.0.251
komme ich ohne Probleme von N1 nach N2.
Ich möchte nun aber nicht bei allen Clients die route hinzufügen oder das Standartgateway ändern. Daher dachte ich mir, ich könnte das Gateway in N1 (die PIX) so ändern, das sie die Routing-Funktion übernimmt.
Also naiv wie ich bin, im PIX PDM eingeloggt und in der Configuration unter "System Properties" -> "Routing" -> "Static routes" folgendes eingetragen:
Interface: inside
IP-Adress: 192.168.2.0
Netmask: 255.255.255.0
Gateway IP: 192.168.0.251
Metric: 1
Teste ich das an einem Client in N1 (z.B. mit ping nach 192.168.2.1) kommt aber nichts an. Mit der route über CMD eingetragen (siehe oben) funktioniert es.
Wo liegt mein Fehler?
Vielen Dank und Gruß,
Markus
wir haben zwei Gebäude über eine WLAN-Bride (DD-WRT) miteinander verbunden (nicht perfekt, ich weiß - aber funktioniert). Die Bridge funktioniert also wunderbar. Im "Hauptnetz" (N1) haben wir 192.168.0.0/24 und im anderen Gebäude (N2) 192.168.0.2/24.
Im Hauptnetz N1 steht die Cisco PIX und routet bisher via SDSL ins Internet.
In N2 steht ein Router mit Debian (keine Ahnung davon, da lass ich die Finger von), der so konfiguriert ist, das er alles was drüben ins Internet will über eine eigene SDSL-Leitung ins Netz schickt und alles was nach 192.168.0.0/24 will über die WLAN-Bridge routet.
Clients in N1 haben feste IPs:
IP: 192.168.0.1 - 192.168.0.99
Gateway: 192.168.0.254 (das ist die PIX)
Clients in N2 bekommen via DHCP folgendes:
IP: 192.168.2.100 - 192.168.2.199
Gateway: 192.168.2.1 (das ist der Debian-Server)
(Der Debian-Server ist auf der anderen Seite auch unter 192.168.0.251 zu erreichen)
Wenn ich nun an meinem Client (Windows Vista) via CMD eine route hinzufüge:
route add 192.168.2.0 mask 255.255.255.0 192.168.0.251
komme ich ohne Probleme von N1 nach N2.
Ich möchte nun aber nicht bei allen Clients die route hinzufügen oder das Standartgateway ändern. Daher dachte ich mir, ich könnte das Gateway in N1 (die PIX) so ändern, das sie die Routing-Funktion übernimmt.
Also naiv wie ich bin, im PIX PDM eingeloggt und in der Configuration unter "System Properties" -> "Routing" -> "Static routes" folgendes eingetragen:
Interface: inside
IP-Adress: 192.168.2.0
Netmask: 255.255.255.0
Gateway IP: 192.168.0.251
Metric: 1
Teste ich das an einem Client in N1 (z.B. mit ping nach 192.168.2.1) kommt aber nichts an. Mit der route über CMD eingetragen (siehe oben) funktioniert es.
Wo liegt mein Fehler?
Vielen Dank und Gruß,
Markus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 108675
Url: https://administrator.de/contentid/108675
Printed on: April 24, 2024 at 11:04 o'clock
2 Comments
Latest comment
Guten Morgen,
ich stehe vor dem gleichen Problem - gleicher Effekt wie schon oben beschrieben. Route unter Static Routes eingetragen und Traceroute wird auf der PIX erfolgreich ausgeführt. Trotzdem funktioniert es vom Client nur, wenn ich die Route händig eintrage. Ich wäre über Hilfe sehr dankbar.
Mit freundlichen Grüßen
Jens
ich stehe vor dem gleichen Problem - gleicher Effekt wie schon oben beschrieben. Route unter Static Routes eingetragen und Traceroute wird auf der PIX erfolgreich ausgeführt. Trotzdem funktioniert es vom Client nur, wenn ich die Route händig eintrage. Ich wäre über Hilfe sehr dankbar.
Mit freundlichen Grüßen
Jens
Auch wenn dir das jetzt nicht hilft:
Ich habs (mit der PIX) nicht hinbekommen. Es liegt daran das die PIX alle Pakete blockt die am internen Interface eingehen und auf über dieses Interface wieder rauswollen. Gefunden hab ich das, als ich mir die Log-Files auf der PIX angeschaut habe. Dort taucht dann irgendwas mit "no xlate" auf... das Internet verrät dazu:
Das es nun bei uns funktioniert liegt einfach daran das die PIX absofort nicht mehr unser Gateway ist.
Wir haben auf einem bereits vorhandenen Server die zweite Netzwerkkarte reaktiviert und dieser ist nun unser Router. Somit musste das natürlich überall geändert werden, aber da muss man dann durch...
Vielleicht findet ja noch jemand eine Lösung für die PIX, würde mich jedenfalls auch interessieren.
Ich habs (mit der PIX) nicht hinbekommen. Es liegt daran das die PIX alle Pakete blockt die am internen Interface eingehen und auf über dieses Interface wieder rauswollen. Gefunden hab ich das, als ich mir die Log-Files auf der PIX angeschaut habe. Dort taucht dann irgendwas mit "no xlate" auf... das Internet verrät dazu:
%PIX-7-106011: Deny inbound (No xlate) chars
Explanation
This is a connection-related message. This message occurs when a packet is sent to the
same interface that it arrived on. This usually indicates that a security breach is occurring. When the
PIX Firewall receives a packet, it tries to establish a translation slot based on the security policy you
set with the global and conduit commands, and your routing policy set with the route command.
Failing both policies, PIX Firewall allows the packet to flow from the higher priority network to a
lower priority network, if it is consistent with the security policy. If a packet comes from a lower
priority network and the security policy does not allow it, PIX Firewall routes the packet back to the
same interface.
To provide access from an interface with a higher security to a lower security, use the nat and global
commands. For example, use the nat command to let inside users access outside servers, to let inside
users access perimeter servers, and to let perimeter users access outside servers.
To provide access from an interface with a lower security to higher security, use the static and
conduit commands. For example, use the static and conduit commands to let outside users access
inside servers, outside users access perimeter servers, or perimeter servers access inside servers.
Action
Fix your configuration to reflect your security policy for handling these attack events.
Explanation
This is a connection-related message. This message occurs when a packet is sent to the
same interface that it arrived on. This usually indicates that a security breach is occurring. When the
PIX Firewall receives a packet, it tries to establish a translation slot based on the security policy you
set with the global and conduit commands, and your routing policy set with the route command.
Failing both policies, PIX Firewall allows the packet to flow from the higher priority network to a
lower priority network, if it is consistent with the security policy. If a packet comes from a lower
priority network and the security policy does not allow it, PIX Firewall routes the packet back to the
same interface.
To provide access from an interface with a higher security to a lower security, use the nat and global
commands. For example, use the nat command to let inside users access outside servers, to let inside
users access perimeter servers, and to let perimeter users access outside servers.
To provide access from an interface with a lower security to higher security, use the static and
conduit commands. For example, use the static and conduit commands to let outside users access
inside servers, outside users access perimeter servers, or perimeter servers access inside servers.
Action
Fix your configuration to reflect your security policy for handling these attack events.
Das es nun bei uns funktioniert liegt einfach daran das die PIX absofort nicht mehr unser Gateway ist.
Wir haben auf einem bereits vorhandenen Server die zweite Netzwerkkarte reaktiviert und dieser ist nun unser Router. Somit musste das natürlich überall geändert werden, aber da muss man dann durch...
Vielleicht findet ja noch jemand eine Lösung für die PIX, würde mich jedenfalls auch interessieren.
