DHCP-Server im Bridged Mode

1. offizieller Beitrag

    Hallo,

    wir haben ein Problem bei einer mittels OpenVPN realisierten Ethernet-Brücke. Ich würde mich freuen, wenn mir jemand mit dem Zaunpfahl winken könnte. :oops:

    Code
    Client-Netzwerk                                                                                         Server-Netzwerk
        ------------+                                                                                           +------------
                    I            +-----------+          +-------------+           +-----------------+           I
        ------------#------------# FRITZ!Box #-.-.-.-.-.#   Router    #-----------#       efw       #-----------#------------
                    I            +-----------+          +-------------+           +-----------------+           I
        ------------+                                                            RED              GREEN         +------------
    192.168.15.65-99/24    192.168.15.64     ((INTERNET))    192.168.12.1   192.168.12.9     192.168.15.1     192.168.15.2-64/24


    Der Server läuft auf einer "Endian Firewall Community release 2.2.rc3" und der Client auf einem Router (FRITZ!Box - "OpenVPN 2.1_rc2 mipsel-linux"). Die Verbindung an sich ist in Ordnung, was ja auch schon das Problem ist: DHCP-Clients aus dem Client-Netzwerk erhalten z.T. ihre IP-Konfiguration oder auch nur DHCP-Optionen wie die DNS-Server aus dem Server-Netzwerk. Sobald der Tunnel dann nicht mehr steht (wg. DSL-Problemen auf Server-Seite leider recht häufig), gehen sämtliche DNS-Anfragen ins Leere.

    Auf 'ner älteren efw hatte ich das mal per iptables gelöst, aber ich besitze die Doku dazu leider nicht mehr. Ich habe die Regel bereits in verschiedensten Ketten (z.B. OPENVPNDHCP, INPUT, INPUTFW, etc.) ausprobiert, aber der DHCP-Server antwortet immernoch wie zuvor.

    Code
    iptables -I $CHAIN -p udp --sport 67:68 --dport 67:68 -m physdev --physdev-in tap1 -j DROP


    Eigentlich sollte das ja nicht passieren, weil der Request "gedropped" werden soll. Wo erfahre ich, in welcher Reihenfolge die zahlreichen Ketten abgearbeitet werden, oder in welcher Kette müsste die Regel greifen?

    Ich habe auch mal versucht, den DHCP-Server der efw durch die benutzerdefinierten Konfigurationszeilen dazu zu überreden, den DHCP-Clients im Client-Netz ihre passende Konfiguration zu senden, was zu bizarren Ergebnissen führte: Das DHCPOFFER-Paket kam zwar mit den untenstehenden (richtigen) Optionen, der DHCPACK kam dann aber mit den falschen.


    Versuch macht halt kluch... :D Ich möchte die Konfiguration des efw-DHCP-Servers jetzt aber ungerne komplett händisch erstellen. Mir wäre es eh am liebsten, wenn das ganze wieder wie zuvor über die Firewall geregelt werden könnte.

    Vielen Dank schonmal im Voraus und 'n guten Rutsch...

    Hallo nochmal,

    die Funktionsweise der iptables-Ketten habe ich jetzt glaube ich durchschaut. :? Trotzdem werden DHCP-Request-Pakete offensichtlich immernoch weitergeleitet, obwohl sie im efw-Log eindeutig als -je nach Einstellung- INPUTFW:DROP oder VPNFW:DROP zu finden sind. Auch die Zähler (iptables -L -v) deuten daraufhin, dass die Regeln greifen. Aber der efw-DHCP-Server antwortet nach wie vor. Auch die folgende (ausgehende) Regel war nicht von Erfolg gekrönt (auch nicht mit DROP als Sprungziel):

    Code
    iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p tcp --sport 68 --dport 67 -j REJECT
iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p udp --sport 68 --dport 67 -j REJECT

    Nutzt der Server vielleicht doch direkt das tap-Interface obwohl er nur für die Brücke br0 gestartet ist?

    Ich hoffe auf frische Ideen, meine sind zur Zeit ausgeschöpft...

    Also denn, nochmal 'n guten Rutsch!

    Hallo,

    leider besteht das Problem immernoch. Die Pakete gehen lt. Wireshark auf jeden Fall auf/über die Ports UDP 67 (Server) & UDP 68 (Client). Ob vielleicht noch andere Ports genutzt werden, kann ich nicht ausschließen, weil der Netzwerk-Traffic bei mehreren Windows-Clients im Netzwerk dermaßen unübersichtlich ist, dass ich nur die Kommunikation über die Standard-Ports genauer betrachtet habe (Lt. IANA.ORG: 67 & 68 jeweils TCP und UDP). Es finden sich auf diesen Ports alle DHCP-Pakete (Release, Discover, Request, Offer, Inform, Ack...), weshalb ich davon ausgehe, dass nur diese benutzt werden.

    Ich befürchte mittlerweile, dass es hier nicht ohne weiteres möglich ist, die Pakete adequat auszufiltern, würde mich aber freuen, wenn mir doch noch ein Weg aufgezeigt werden könnte...

    Gruß
    Andreas