Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 1 subscriber
  • Views 4527 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Basics, Network Protection

hegl
Beschäftige mich gerade mit dem Zugriff aus anderen Netzen ins LAN hinter einer UTM. Hier sind eine UTM320 und eine Cisco ASA über ein Transfer-LAN verbunden. Jetzt möchte ich einen Zugriff eines Clients im Netz hinter der ASA 10.250.22.4 (Client im LAN-ASA) auf einen Server (10.240.22.10) im LAN der UTM mittels TCP/445 gewähren. Also LAN-A --> Transfer-LAN --> LAN-UTM. Auf der ASA sehe ich im logging auch, dass das Paket mit der Original-IP-Adresse im Transfer-LAN aufschlägt. Auf der UTM habe ich dann ein FW-Regel erstellt, die den Zugriff von 10.250.22.4 (Client im LAN-ASA) auf den internen Server 10.240.22.10 (LAN-UTM) zulässt. 
Der Zugriff schlägt aber fehl. Ich denke, ich muss ja noch irgendwo ein NAT vom Transfer-LAN ins LAN-UTM bauen, oder wo liegt mein Problem? Statische Routen habe ich auf beiden FW´s konfiguriert.

Bei Cisco bekommt man eigentlich für alles Beispielkonfigurationen, bei Sophos bin ich bis jetzt nicht fündig geworden :-(


This thread was automatically locked due to age.
  • 0
    Werden in der Firewall Pakete gedroppt? - was steht bei einer Anfrage im LiveLog bzw. steht dort überhaupt etwas?

    Wie sieht die FW-Regel aus?
    Wie sehen die statischen Routen auf beiden Seiten aus?

    Nice greetings
  • 0 in reply to GuyFawkes
    Werden in der Firewall Pakete gedroppt? - was steht bei einer Anfrage im LiveLog bzw. steht dort überhaupt etwas? 

    Jepp: "Packet Filter Rule #5 10.250.22.4 --> 10.240.22.10"  in grün :-)

    Wie sieht die FW-Regel aus?

    Source: 10.250.22.4
    Services: any
    Destinations: 10.240.22.10
    Action: Allow

    Wie sehen die statischen Routen auf beiden Seiten aus?

    UTM: 
    Route Type:Gateway route 
    Network: 10.250.22.0/24
    Gateway: 172.20.20.1 (Interface-IP der ASA im Transfer-LAN)

    ASA:
    route transfer-lan 10.240.22.0 255.255.255.0 172.20.20.2 1

    Hier bin ich eigentlich auch sicher, dass alles stimmt, da hier bereits andere Kunden auch über das Transfer-LAN kommunizieren. Und außerdem sehe ich ja im Transfer-LAN, dass keine Pakete von der UTM zurückkommen.
  • 0
    hat der zielrechner 10.240.22.10 im utm lan ( zu dem die pakete gesendet werden) eine default-route zur UTM? ich wette seine default route geht woanders hin ... also default gw aendern oder netzwerk route einfzegen.
  • 0 in reply to Ölm
    Default-Gateway ist ok, sonst würde ja auch der Internetzugriff nicht funktionieren.
    Habe es aber gerade noch einmal explizit überprüft, Gateway ist das UTM.
  • 0
    Netzwerkkonfiguratin auf dem Server - welche Netzmaske ist hinterlegt? Wenn da ne /8 statt ne /24 drin steht dann wird die Antwort falsch geroutet.
    100%ige Sicherheit bekomst du mit tcpdump auf der UTM
     
    tcpdump -npi ethX host 10.240.22.10    
    parallel (2. SSH Session)
    tcpdump -npi ethY host 10.240.22.10    
    ethx= LAN Interface  ethy = WAN interface
    so siehst du ob pakete von der ASA ankommen (das tun sie auf jeden Flal, sonst wuerde die FW ja nicht grün loggen), ob Sie auf der anderen Seite der UTM wieder rausgehen in Richtung Server, ob der Server antwortet, und ob das Antwortpaket die UTM in Richtung ASA verlaesst
  • 0 in reply to Ölm
    IP-Konfiguration am Server ist ok.

    Am Interface des Transfer-LAN an der UTM sehe ich die Pakete reingehen, aber nicht mehr herauskommen.
    Also liegt ja der Hund im LAN-UTM begraben. Hier werde ich aber nicht richtig schlau. 
    Wäre nett, wenn Du dazu (siehe Anhang) was sagen könntest.

    NACHTRAG !!! Habe gerade mal einen dump auf´s WAN gemacht und sehe, dass die Pakete da herausgehen. Also ist irgendwas am Routing falsch. Aber was???
  • 0 in reply to hegl
    mach mal den tcpdump auf dem WAN interface mit -e
     
    also tcpdump -nepi ethX
     
    dann siehst du die MAC addressen wo die pakete hingeroutet werden
    und kannst prüfen, ob die Rückpackete (zur 10.250.22.4) auch wirklich zur MAC der ASA geroutet werden oder nicht
     
    arp -an ist ebenfalls hilfreich
  • 0
    noch was, in deinem tcpdump sind folgende Zeilen enthalten:
     
    09:38:02.365751 arp who-has 10.240.22.10 tell 10.240.22.254
    09:38:02.365833 arp reply 10.240.22.10 is-at 90:b1:1c:10:60:e6

    wenn das ein tcpdump auf dem WAN interface ist, warum siehst du hier arp requests und responses von IP-Adressen, die nur auf dem LAN interface auftauchen sollten (10.240.22 ist doch das LAN).
     
    Vermutlich stimmt da was nicht - Routing, proxy ARP, Verkabelung ... ?
  • 0 in reply to Ölm
    noch was, in deinem tcpdump sind folgende Zeilen enthalten:
     
    09:38:02.365751 arp who-has 10.240.22.10 tell 10.240.22.254
    09:38:02.365833 arp reply 10.240.22.10 is-at 90:b1:1c:10:60:e6

    wenn das ein tcpdump auf dem WAN interface ist, warum siehst du hier arp requests und responses von IP-Adressen, die nur auf dem LAN interface auftauchen sollten (10.240.22 ist doch das LAN).

    Das ist auch aus dem LAN - schau Dir mal den Dateinamen des Anhangs an ;-)
     
    Vermutlich stimmt da was nicht - Routing, proxy ARP, Verkabelung ... ?

    Jepp, Routing vermute ich ja auch - deswegen ja auch oben meine Angabe zur Überprüfung, Verkabelung ist ok. Aber nochmal:

    1) Default-Gateway ist der Provider-Router am WAN (Eth1). So ist das Interface konfiguriert
    2) Weiterhin sind 2 Interface (Internal (Eth1) & Transfer-LAN (Eth7) ) mit festen IP-Adressen definiert.
    3) Ich habe eine statische Route hinzugefügt: Netz 10.250.22.4 befindet sich hinter 172.20.20.1 (Interface-IP der ASA am Transfer-LAN). Dies ist definiert als Gateway route.

    Ist das soweit ok?
  • 0
    du hast aber in der Zeile drüber geschrieben: "NACHTRAG !!! Habe gerade mal einen dump auf´s WAN gemacht und sehe, dass die Pakete da herausgehen. "
    daher hatte ich vermutet dass sich auf deas attachte tcpdump  log bezieht.
     
    egal, dann mach das doch nochmal auf dem WAN interface, gleich mit -e, dann siehst du es doch am einfachsten wo die pakete von der UTM hingeroutet werden.
Cookie Information Banner