Problem LAN zu DMZ



  • Hallo,

    ich habe mir hier eine DMZ konfiguriert und soweit funktioniert diese auch. Leider funktioniert eine Sache nicht:

    Ich möchte eine Verbindung aus dem LAN in die DMZ zu den dort befindlichen Rechnern herstellen können. Aber egal welche Konfiguration ich bisher ausprobiert habe, keine greift.

    Ich habe jeweils für die DMZ und das LAN eine eigene physische Schnittstelle/NIC, deren Netz-Adressen:

    LAN 10.2.0.0/20
    DMZ 10.2.28.0/24

    die jeweiligen Gateway-Adressen die die Pfsense darstellen:

    10.2.0.1
    10.2.28.1

    Lustigerweise kann ich von beiden Netzen aus, jeweils die Schnittstellen-Adresse erreichen. Aber eben nicht die Hosts/Clients/Rechner in diesem Netz.

    Für das LAN habe ich eine Rule mit folgendem Inhalt erstellt: Allow IPv4 any Protocol from Source 10.2.0.0/20 to Destination 10.2.28.0/24

    Bei DMZ habe ich allerdings ein Reject gemacht, da ich nicht will das ausgehend vom DMZ etwas ins LAN geht: Reject IPv4 any Protocol from Source 10.2.28.0/24 to Destination 10.2.0.0/20.

    Dies sollte funktionieren, zumindest nachdem was ich bisher in diversen Foren gelesen habe, da wenn das Hin-Packet pass ist auch das Rück-Packet pass. Aber leider fünktioniert es dennoch nicht.

    Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

    Würde mich über Hilfe und Tipps freuen.

    Gruß


  • Moderator

    Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

    Nein, NAT wäre hier kontra-produktiv. Beides sind interne Netze nach RFC1918, die werden ganz normal geroutet. Die üblichen Fragen gelten auch hier:

    0a) Warum ist das LAN so groß? Muss das ein /20 sein?
    0b) Warum die .8 als Gateway Adresse?

    1. Ist die 10.2.0.8 (pfsense) im LAN das default GW
    2. Ist die 10.2.28.8 (pfsense) in der DMZ das default GW
    3. kann man einen Screenshot der Regeln sehen? Reihenfolge geprüft?
    4. Ist auf den Interfaces (LAN/DMZ) der Haken drin, dass private Adressen geblockt werden?
    5. Gibt es andere Router/Gateways

    Gruß



  • @JeGr:

    Muss ich hier noch ein NAT konfigurieren? Wenn ja wie müsste dies aussehen?

    Nein, NAT wäre hier kontra-produktiv. Beides sind interne Netze nach RFC1918, die werden ganz normal geroutet. Die üblichen Fragen gelten auch hier:

    0a) Warum ist das LAN so groß? Muss das ein /20 sein?
    0b) Warum die .8 als Gateway Adresse?

    1. Ist die 10.2.0.8 (pfsense) im LAN das default GW
    2. Ist die 10.2.28.8 (pfsense) in der DMZ das default GW
    3. kann man einen Screenshot der Regeln sehen? Reihenfolge geprüft?
    4. Ist auf den Interfaces (LAN/DMZ) der Haken drin, dass private Adressen geblockt werden?
    5. Gibt es andere Router/Gateways

    Gruß

    0a) Muss es nicht, aber ich habe das so ähnlich hier. Ich wollte mich persönlich nicht noch weiter verwirren. Random. ;D
    0b) Ich habe es mal auf .1 abgeändert. Ist ja eigentlich auch Wurst.

    1. Ja.
    2. Ja.
    3. Siehe Anhang.
    4. Nein, der Haken ist nicht gesetzt.
    5. Nur das WAN-Gateway vom Provider, das mehr als Modem fungiert.

    Gruß






  • Hallo,

    die Regeln sollten ja den Zugriff von LAN nach DMZ erlauben, falls das deine 2. LAN-Regel nicht verbietet.

    Möglicherweise blockt die PC-Firewall am Zielrechner den Zugriff aus einem anderen Subnetz. Windows tut das von Haus aus.



  • Nein, die PC-Firewall sollte kein Problem sein, da es sich um ein Debian handelt und da ist iptables inaktiv.

    Die Zweite Regel blockt nur den Internetverkehr für einen Client der noch mit XP läuft.

    Könnte vielleicht das VLAN, indem ich die DMZ betreibe, das Problem sein? Ich habe ein untagged VLAN auf einem Brocade Switch eingerichtet, da ich nicht extra einen Switch für die DMZ stellen wollte. Sollte aber aus meiner Sicht kein Problem sein, da die pfSense jeweils ein Standbein in beiden VLANs hat… oder könnte es hier ein Problem geben?

    Mir ist jetzt auch folgendes aufgefallen: Wenn ich ein TCPdump auf der Debian-Kiste laufen lasse und aus dem anderen Netz pinge, kommt das Echo request an. Dann aber wird keines mehr zurückgesendet... auf der pfsense sieht der Mitschnitt dann so aus...

    
    11:54:05.499610 IP 10.4.1.50 > 10.4.29.99: ICMP echo request, id 52481, seq 1, length 24
    11:54:05.499968 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
    11:54:06.507552 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
    11:54:07.547546 ARP, Request who-has 10.4.1.50 tell 10.4.29.99, length 46
    
    

    Wie kann das sein? Das default Gateway ist auf jeden Fall gesetzt, dies habe ich gerade nochmal überprüft und es ist auch erreichbar.


  • Moderator

    Ist der Mitschnitt jetzt von dem Debian auf der 29.99 oder auf der pfsense?

    Mach doch mal zeitgleich beide und poste die, da ist was sehr seltsam und mir scheint das eher auf Netzwerkebene zu sein. Können sie Quelle und Ziel ggf. sehen weil nicht per VLAN separiert? Oder ist auf der Kiste in der DMZ die Maske vllt falsch und sie versucht direkt zu antworten statt es ans Gateway zu schicken?

    Gruß



  • Keine Ahnung von wo du da wohin pingst. Die IPs sind in keinem der o.g. Netze enthalten.

    Der TCPdump zeigt abgeshen von dem Echo Request nur die zugehörigen ARP-Requests ohne Antworten. Und ARP passiert nur in einem Subnetz.
    Dass nun 10.4.1.50 im selben Subnetz wie 10.4.29.99, zeigt dass dieses auch sehr groß dimensioniert sein muss, mind. /19. (??) Dass keine Antwort kommt, könnte auf einen Netzwerkkonfigurationsfehler hindeuten.

    Vielleicht überschneiden sich das doch ein paar Netzwerkkonfigurationen?
    Ich würde das mal aufräumen.


  • Moderator

    Stimmt hatte ich glatt übersehen. Da steht 10.4 nicht 10.2. Das kann also hinten wie vorne nicht sinnvoll in der DMZ ankommen.