/*Gelöst*/ DNS Ausflösung (Regeln funktionieren nicht)



  • Hallo,

    irgendwie werde ich aus den gefundenen Informationen nicht schlau genug.
    Folgender Aufbau:

    WAN / Internet
                :
                : DialUp-/PPPoE-/Cable-/whatever-Provider
                :
          .–---+-----.
          |  Gateway  |  (or Router, CableModem, whatever)
          '-----+-----'
                |
            WAN | IP or Protocol
                |
          .-----+-----.        LAN2          192.168.1.10/24        .-------------.
          |  pfSense  |---------------------------------------------| LAN-Switch |------Clients
          '-----+-----'                LAN3                                    '-------------'
                |    '-------------------------------------
            LAN1 | 192.168.14.10/24                    |    192.168.2.10/24        .-------------.
                |                                                    '-----------------------------| LAN-Switch|------Clients
          .-----+-------.                                                                              '--------------'
          | LAN-Switch |
          '-----+-------'
                |
        ...-----+------... (Clients/Servers)

    Jetzt "relativ" einfache Aufgabe. In dem Netz 192.168.14.0 steht u.a DNS. Ich will also dass die Klients aus den Netzen 192.168.1.0 und 192.168.2.0 den Server im 192.168.14.0 befragen können und dass der Server aus dem Netz 192.168.14.0 öffentliche Server draußen fragen kann.

    Für den ersten Teil habe ich eine Regel erstellt die besagt:
    Quelle (LAN2-net) (bzw. LAN3-Net) Ziel ist 192.168.14.2 UDP und Port 53
    und diese je an LAN2 und LAN3 gebunden

    Für den 2-ten Teil habe ich eine Regel erstellt die besagt:
    Quelle ist 192.168.14.2 Ziel ist "any" Protokoll "UDP" und Zielport "53". Ich habe die Regel an LAN1 gebunden.

    Der Resolver auf pfSense ist nicht aktiv.
    Es kann weder ein Klient noch der Server selbst Namen auflösen. Da pfSense über 4 Netzwerkkarten verfügt die je im eigenem VLAN stecken ist hier nur default Route definiert die auf mein DSL Gateway zeigt.
    Sonst gibt es keine andere Regeln.

    Muss ich bei pfSense auch Relegn für Rückantwort definieren, sind die falsch aufgehangen oder was kann ich hier sonst noch übersehen haben?


  • LAYER 8 Moderator

    Hi Tobi,

    wenn ich das recht sehe, ist es also:

    LAN1: 192.168.14.0/24
    LAN2: 192.168.1.0/24
    LAN3: 192.168.2.0/24

    Jetzt "relativ" einfache Aufgabe. In dem Netz 192.168.14.0 steht u.a DNS. Ich will also dass die Klients aus den Netzen 192.168.1.0 und 192.168.2.0 den Server im 192.168.14.0 befragen können und dass der Server aus dem Netz 192.168.14.0 öffentliche Server draußen fragen kann.

    Übersetzung:

    • Regel auf LAN1: Erlaube DNS Server IP nach any (extern) auf DNS Ports (TCP/UDP 53). Damit darf der DNS raus
    • Regel auf LAN2/3: Erlaube Interface network nach DNS Server IP, UDP/53. Damit dürfen alle CLients aus den Netzen DNS auf dem DNS Server aber nicht extern.

    Der Resolver auf pfSense ist nicht aktiv.
    Es sollte aber lokal zumindest DNS Server auf der pfSense konfiguriert sein. Und es macht durchaus Sinn, den Forwarder oder Resolver aktiv zu lassen, damit die Zugriffe etwas gecached werden.

    Es kann weder ein Klient noch der Server selbst Namen auflösen
    Dann prüfen, was der Server selbst als Upstream nutzt. Hat er selbst spezifizierte DNS Server die er fragt wenn er nicht lokal zuständig ist oder macht er Resolver und fragt "die Welt"? Dann muss ggf. TCP/53 noch offen sein (Server 2 Server DNS!)

    Bitte auch in den Logs schauen, was zu dem Zeitpunkt auf LAN1 (wegen Server) oder auf LAN2/3 geblockt wird

    Da pfSense über 4 Netzwerkkarten verfügt die je im eigenem VLAN stecken ist hier nur default Route definiert die auf mein DSL Gateway zeigt.

    Das ist irritierend. 4 Netzwerkkarten (echte?) oder VLANs?

    Muss ich bei pfSense auch Relegn für Rückantwort definieren, sind die falsch aufgehangen oder was kann ich hier sonst noch übersehen haben?

    Nein die outgoing Regeln (pass out on <xy>…) werden automatisch erzeugt.

    hier sonst noch übersehen haben?

    Evtl. dass DNS auch via TCP gesprochen wird, nicht nur UDP.

    Grüße</xy>



  • @JeGr:

    wenn ich das recht sehe, ist es also:

    LAN1: 192.168.14.0/24
    LAN2: 192.168.1.0/24
    LAN3: 192.168.2.0/24

    WAN - 192.168.3.0/24
    Nur damit das Vollständig wird.

    @JeGr:

    • Regel auf LAN1: Erlaube DNS Server IP nach any (extern) auf DNS Ports (TCP/UDP 53). Damit darf der DNS raus

    Richtig

    @JeGr:

    • Regel auf LAN2/3: Erlaube Interface network nach DNS Server IP, UDP/53. Damit dürfen alle CLients aus den Netzen DNS auf dem DNS Server aber nicht extern.

    Richtig

    @JeGr:

    Es sollte aber lokal zumindest DNS Server auf der pfSense konfiguriert sein. Und es macht durchaus Sinn, den Forwarder oder Resolver aktiv zu lassen, damit die Zugriffe etwas gecached werden.

    Das sind Feinheiten die ich gerne auf "später" verschiebe wo halt alles so läuft wie ich es haben will. Möchte vermeiden, dass irgendwo doch "Kleinigkeit" übersehen habe.

    @JeGr:

    Bitte auch in den Logs schauen, was zu dem Zeitpunkt auf LAN1 (wegen Server) oder auf LAN2/3 geblockt wird

    Ich habe die Regeln jetzt etwas angepasst und alle quasi gelöscht, bis auf Ping und Abfrage von Externen DNS Servern
    Und es sieht doof aus. Ping geht, Log sagt "alle Gut" und Namen können nicht aufgelöst werden.

    @JeGr:

    Das ist irritierend. 4 Netzwerkkarten (echte?) oder VLANs?

    Echte Karten und für jede diesen Karten ist anderes VLAN auf dem Switch-Port definiert

    Vielleicht noch als Bemerkung/ Hinweis. Im Moment läuft hier Linux mit IPTables als Router/FW. Ich bin damit nicht ganz zufrieden und so läuft pfSense auf der gleicher Hardware (halt mal Linux mal FreeBSD). Gleiche MAC, gleiche IP's usw. somit sind irgendwelche Fehler außerhalb des Routers/FW ausgeschlossen.

    ![Bildschirmfoto 2016-08-09 um 17.16.19.png](/public/imported_attachments/1/Bildschirmfoto 2016-08-09 um 17.16.19.png)
    ![Bildschirmfoto 2016-08-09 um 17.16.19.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2016-08-09 um 17.16.19.png_thumb)


  • LAYER 8 Moderator

    Echte Karten und für jede diesen Karten ist anderes VLAN auf dem Switch-Port definiert

    Ah, untagged Ports, verstanden.

    Und es sieht doof aus. Ping geht, Log sagt "alle Gut" und Namen können nicht aufgelöst werden.

    Step by Step.

    1. Kann die pfSense selbst Namen auflösen über ihre DNS Server die konfiguriert sind?
    2. Kann der DNS/DHCP Server selbst jetzt Namen auflösen? Auf der Konsole o.ä.?

    Wenn nicht (2), dann bei der Regel das Logging aktivieren und bei der Abfrage die Firewall Logs (Filter) überprüfen, ob von der IP was raus will, was du ggf. übersehen hast.
    Oder: Ist der DNS vllt. DualHomed? Der Server eine zweite IP oder Netzwerkkarte und schickt die Anfragen über die falsche?



  • Namen aus dem "internen" Bereich kann mein DNS/DHCp Server natürlich auflösen.
    Die externe nicht.
    Wenn ich da auf der Konsole ein "nslookup …..." mache bekomme ich Timeout
    Bei pfSense im Log sieht es aber gut aus (Screenshot, hatte ich gestern vergessen.)

    Ich habe gestern Abend noch versucht auf pfSense den Resolver zu aktivieren und als DNS 2 Server von meinem ISP einzutragen. pfSense konnte die externe Namen auflösen.
    So ein Konstrukt hilft mir aber nicht, da ich dafür so ziemlich alles bei mir umändern musste und das will ich nicht.

    Von der interner DNS IP Adresse wird laut Log nichts geblockt.

    ![Bildschirmfoto 2016-08-09 um 17.59.41.png](/public/imported_attachments/1/Bildschirmfoto 2016-08-09 um 17.59.41.png)
    ![Bildschirmfoto 2016-08-09 um 17.59.41.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2016-08-09 um 17.59.41.png_thumb)


  • LAYER 8 Moderator

    Dann scheint es als ob der Windows DNS das Problem macht/hat. Aus dem Regel-Log würde ich sagen das läuft wie es soll. Ich würde dann mal beim Windows Server ins Ereignislog schauen, was der DNS o.ä. meckert, vielleicht wird man dann schlauer, was eigentlich das Problem ist. Ich hatte mit Windows Kisten aber auch schon Probleme dass die wegen irgendwas ziemlich zickig sind. Es sieht mir aber vom Prinzip her nicht nach einem Fehler der pfSense Einstellung aus, sondern als ob die Windows Kiste da noch irgendein Problem hat was vielleicht nichts mit DNS zu tun hat (oder auf einer anderen Ebene).

    Aber das artet jetzt leider eher in Glaskugellesen aus :)



  • Mein DNS/DHCP läuft aber nicht unter Windows ;) sondern Linux.

    Wenn das Problem da liegen sollte, dürfte es auch nicht laufen, wenn ich statt pfSense, Linux boote und mit IPTables es versuche.
    Aber Danke für die Antwort, auch wenn mein Problem damit nicht gelöst ist.


  • LAYER 8 Moderator

    Mein DNS/DHCP läuft aber nicht unter Windows ;) sondern Linux.

    Ah, das Kommentar mit Konsole und nslookup hatte ich falsch interpretiert ;)
    Dann wäre aber ein Check mit "host" oder "dig" noch interessant, ob die Abfragen gezielt funktionieren. Und wenn das Linux ist, was für ein DNS Server da werkelt, ist er als Resolver eingestellt oder hat er Forwarder? Ist er selbst als sein eigener DNS eingestellt etc?



  • Da läuft bind9
    Eingestellt ist er als Resolver.

    Wie es mit host und/oder dig aussieht kann ich heute abend wieder testen.

    EDIT:

    Gibt es auf pfSense eine Möglichkeit sich den Trafic etwas "genauer" irgendwie anzuschauen? Also wenn das Log meint "alles in in Ordnung" verschickt worden, und Du sagst dass die Rückantworten automatisch impliziert werden, dann wäre meine Vermutung/ Idee - vielleicht stimmt was mit dem Routing nicht und die Rückantwort einfach mein DNS Server nicht erreicht.


  • LAYER 8 Moderator

    vielleicht stimmt was mit dem Routing nicht und die Rückantwort einfach mein DNS Server nicht erreicht.

    Klar, du kannst einen TCPDump machen. Diagnostic / Packet Capture und entsprechend auf den DNS Server als Host konfigurieren, damit du nicht zu viel Traffic mitschneidest. Dann starten, ein paar DNS queries machen und dann den Dump speichern und bspw. in Wireshark anschauen.



  • Nac meinen gestrigen Tests komme ich zu dem Ergebnis, dass pfSense an der Stelle buggy ist.
    Ich kann aus meinen Netzen alles machen, das einzige was nicht funktioniert ist direkte Befragung eines externen DNS Server. Damit die Auflösung möglich ist, muss pfSense als Resolver oder Forwarder definiert sein.


  • LAYER 8 Moderator

    Wie hast du deinen DNS Server konfiguriert damit es geht? Er befragt als Upstream die pfSense und dann läuft es (mit aktivem Resolver)?

    Nac meinen gestrigen Tests komme ich zu dem Ergebnis, dass pfSense an der Stelle buggy ist.
    Da "muss" ich dich enttäuschen, dass das definitiv nicht der Fall ist. Zumindest kann ich das (leider) in meinem kurzen Test nicht nachvollziehen.
    Wir haben hier ein Pärchen public DNS Server die definitiv aus dem Internet sowie intern erreichbar sind und selbst Resolver spielen, also keine fixen Upstream DNS Server als Forwarder ansprechen, sondern selbst mit dem SOA Server Kontakt aufnehmen und dann cachen. Und die funktionieren bei uns definitiv an der pfSense und deren Forwarder vorbei. Ich kann nur vermuten dass irgendwo noch ein kleines Puzzleteil fehlt um dem Problem auf die Spur zu kommen…

    Konntest du mal einen TCPDump machen um zu sehen, was an Traffic anfällt und ggf. nicht läuft?



  • Wie hast du deinen DNS Server konfiguriert damit es geht? Er befragt als Upstream die pfSense und dann läuft es (mit aktivem Resolver)?

    Nicht ganz, ich habe in der Konfig von meinem DNS "forwarders" eingetragen und da die IP Adresse von der pfSense box. pfSense ist nur als DNS-Forwarder konfiguriert und da die 2 DNS vom ISP

    Da "muss" ich dich enttäuschen…..

    Ja, das habe ich inzwischen auch feststellen müssen. ALLERDINGS (ja natürlich kann hier niemand in mein Netz schauen - das ganze läuft wie gesagt ohne Probleme (und ohne dass ich ein extra Forwarder auf meinem Router/FW konfigurieren muss o.ä) sowohl mit meiner Linux Box und IPTables wie auch mit Citrix NetScaler.

    /Bevor die "plumpe" bemerkung kommt - "dann bleibe doch dabei" - bei IPTables ist es schon recht nervig und aufwendig immer auch an den Rückweg zu definieren und erlauben. NetScaler kann dummerweise DHCP-Relay nicht :( /

    So und jetzt komme ich sofort von einem zu nächsten Problem und bin fast geneigt zu sagen dass pfSense sich mit meinem DNS/DHCP nicht verträgt :(. Bei DHCP-Relay habe ich nämlich auch das Problem, dass die Anfragen vom Klient bei meinem DHCP Server ankommen und diese werden auch beantwortet nur beim Klient kommt nichts an.
    Ein Trace auf den 2 betroffenen Interfaces zeigen, dass Anfragen verschickt werden aber man sieht keine Antworten. (ob ich mit tcpdump etwas mehr sehe, wollte ich noch heute oder morgen probieren.
    Hier könnte man ja auch sagen "liegt doch an deinem DHCP Server". Und da kommt die Gegenfrage - warum wenn ich die Software auf dem Router/FW tausche alles funktioniert?

    Ich habe nie an Woodoo in EDV geglaubt aber so langsam bin ich mit meinen Ideen und Wissen echt am Ende :(
    Vielleicht ist es echt irgendeine "Kleinigkeit" die man dafür auf pfSense aktivieren oder deaktivieren muss, das weiß ich nicht. Dazu kenne ich das viel zu wenig.


  • LAYER 8 Moderator

    Bevor die "plumpe" bemerkung kommt - "dann bleibe doch dabei" -

    Das wäre wirklich plump und nicht zielführend. Aber die Problematik ist wirklich extrem seltsam. Vielleicht bringt ein TCPDump etwas mehr Licht ins Dunkel wo da vielleicht was falsch abbiegt.



  • So, ich habe den Test mit tcpdump etwas schneller gemacht Hier das Ergebnis

    XN0 ist die Schnittstelle an der DHCP Server hängt, die XN1 ist die wo der Klient hängt.

    myhack01:~ robert$ tcpdump -r XN0.tdump 
    reading from file XN0.tdump, link-type EN10MB (Ethernet)
    12:34:10.223060 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:10.253801 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:11.944303 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:11.976186 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:14.531593 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:14.564944 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:19.066438 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:19.066732 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:20.698683 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:20.699012 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:23.158499 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:23.158782 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:27.562553 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:27.562797 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:35.772013 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:35.772310 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:36.636509 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302
    12:34:36.721868 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:38.582339 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302
    12:34:38.610976 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:40.754626 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302
    12:34:40.788885 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:44.735974 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:44.736288 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:48.966390 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 300
    12:34:48.966685 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    12:34:53.530764 IP xencom002.rjap.de.bootps > xenserver01.rjap.de.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:34:53.531083 IP xenserver01.rjap.de.bootps > xencom002-1.openwlan.local.bootps: BOOTP/DHCP, Reply, length 301
    myhack01:~ robert$ tcpdump -r XN1.tdump 
    reading from file XN1.tdump, link-type EN10MB (Ethernet)
    12:31:26.037441 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:27.820821 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:30.155835 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:34.462180 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:35.472950 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:38.056275 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:42.180818 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:50.803080 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:31:58.925984 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    12:32:07.710977 IP 0.0.0.0.bootpc > broadcasthost.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300
    

    Wie man (meine ich zumindest) die Pakete kommen bei Server an und der Antwortet auch nur pfSense, vergisst sie irgendwie
    Wenn Du jetzt eine gute Idee hast, was ich übersehe….


  • LAYER 8 Moderator

    Könntest du die a) mal ohne DNS machen (also mit IPs statt Namen) damit mans besser lesen kann?
    Ist myhack01 die pfSense?



  • Jupp, hatte ich später nicht daran gedacht.

    192.168.14.1 ist mein DNS/DHCP Server
    192.168.14.10 ist das eine Bein von pfSense in dem Netz

    Hier noch mal das gleiche mit IP's

    reading from file XN1.tdump, link-type EN10MB (Ethernet)
    12:31:26.037441 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:27.820821 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:30.155835 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:34.462180 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:35.472950 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:38.056275 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:42.180818 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:50.803080 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:31:58.925984 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:32:07.710977 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    [2.3.2-RELEASE][root@192.168.14.10]/root: tcpdump -w XN0.tdump -i xn0 udp portrange 67-68
    tcpdump: listening on xn0, link-type EN10MB (Ethernet), capture size 65535 bytes
    ^X^C28 packets captured
    877 packets received by filter
    0 packets dropped by kernel
    [2.3.2-RELEASE][root@192.168.14.10]/root: tcpdump -r XN0.tdump
    reading from file XN0.tdump, link-type EN10MB (Ethernet)
    12:34:10.223060 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:10.253801 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:11.944303 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:11.976186 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:14.531593 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:14.564944 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:19.066438 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:19.066732 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:20.698683 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:20.699012 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:23.158499 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:23.158782 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:27.562553 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:27.562797 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:35.772013 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:35.772310 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:36.636509 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302 
    12:34:36.721868 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:38.582339 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302 
    12:34:38.610976 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:40.754626 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 302 
    12:34:40.788885 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:44.735974 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:44.736288 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:48.966390 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from 90:b9:31:2a:44:a9 (oui Unknown), length 300 
    12:34:48.966685 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    12:34:53.530764 IP 192.168.14.10.bootps > 192.168.14.1.bootps: BOOTP/DHCP, Request from f0:db:f8:ab:8b:28 (oui Unknown), length 300 
    12:34:53.531083 IP 192.168.14.1.bootps > 192.168.1.10.bootps: BOOTP/DHCP, Reply, length 301 
    

  • LAYER 8 Moderator

    Und wer hat dann die .1.10 aus dem unteren Dump? Hast du den oberen Dump vielleicht zu stark eingegrenzt um die Antworten zu sehen? Nur eine Idee.



  • pfsense hat ja 4 Netzwerkkarten

    1.10 (Netzbereich für Gäste)
    2.10 (Netzbereich für "Freifunk" Projekt)
    3.10 –> 192.168.3.118 (Fritzbox)
    14.10 (hier sind meine eigene Klients und Server)

    Hier noch 2 *.pcap Dateien

    xn0.pcap
    xn1.pcap


Log in to reply