Firewall | Log
-
Hallo zusammen,
vielleicht kann mich jemand hier aufschlauen um daraus zu lernen …
Siehe Foto (Anhang).Was bedeutet das ?
DANKE !
 -
Hallo,
bei den 0 Byte des Fotos darf man sich nicht viel Inhalt erwarten.
:-\ -
Warum auch immer, jetzt sollte es gehen .. :-)
-
Mit der Kenntnis deines Aufbaus wäre das Ganze vielleicht leichter zu erklären.
Du hast auch nicht verraten, was an dem Log genau unklar ist.Im ersten Block ruft einer deiner hosts eine Link-local Adresse auf. Was ich aber hier nicht verstehe ist, dass es am WAN Interface abgefangen wird, denn diese Pakete sollten gar nicht geroutet werden.
Suspekt sind auch die Pakete am EXT Interface. Die Quell- und Ziel-IP sind ja wohl im selben Netzerksegment? So sollte die Pakete gar nicht über die pfSense gelangen.
Möglicherweise hast du ein asymmetrisches Routing, weil das alles auch ACK-Pakete sind. Auf dem Zielhost ein anderes Gateway definiert?Ganz unten sind Broadcasts, die ebenfalls nicht geroutet werden.
-
Danke für dein Feedback - ich versuche es mal zu umschreiben …
-
192.168.0.1 = das GW, die IP des Kabelrouters von upc.at (ISP) - es ist ein 192.168.0.0/30 Point to Point Netz um den Kabelrouter mit der pfSense zu verbinden … dieser Kabelrouter kann kein „BRIDGE" … wird irgendwann ausgetauscht
-
192.168.0.2 = ist die DHCP-Adresse am WANport der pfSense
-
10.0.250.1 = ist die IP-Adresse am EXT-Port der pfSense … quasi LAN-2 … Zugriff auf Internet aber nicht auf LAN-1 (10.0.100.1)
-
10.0.250.2 = ist die IP-Adresse eines Netgear "Access-Point“ an dem LAN- und WLAN Clients hängen
Warum versucht der Netgear als Source die 169er IP als Destination zu „kontaktieren“ ? Ist da ein Client der keine 10.0.250.x IP beziehen kann ? Warum am WAN ?
Die EXT ist das LAN-2 wie oben erwähnt …
Ist das Normal dass die pfSense .1 auf den Netgear .2 zugreift ?Ad. WAN … warum greift hier eine 196er IP auf die .255 = Broadcast dieser speziellen IP ? Am WAN ?
Nochmals danke vorab !
-
-
Sorry, aus diesem Log werde ich dennoch nicht schlau.
Da werden als Source die Interface-Adressen der pfSense aufgelistet. Das ist ungewöhnlich, auch wenn man outbound NAT macht.Warum versucht der Netgear als Source die 169er IP als Destination zu „kontaktieren“ ?
Das sehe ich jetzt nicht in dem Log.
Ist das Normal dass die pfSense .1 auf den Netgear .2 zugreift ?
Wohl nicht aufm Port 80.
Ad. WAN … warum greift hier eine 196er IP auf die .255 = Broadcast dieser speziellen IP ? Am WAN ?
Eine Link-local Adresse hat ein Host, wenn er keine definierte IP bekommen hat (vom DHCP). Diese machen im Log nur Broadcasts, aber warum am WAN, ist mir nicht klar.
Diese IPs (169.254.0.0/16) gehören zu den Bogons. Hast du das Logging von Bogons in den Log-Einstellungen aktiviert?
-
Dann bin ich nicht der Einzige der es nicht versteht ….
Die Bogons sind am WAN der pfSense aktiviert. -
Die Bogons sind am WAN der pfSense aktiviert.
Das Blocken von Bogons.
Doch meinte ich das Logging. Status > System logs > Settings > Log packets blocked by 'Block Bogon Networks' rules -
Das ist auch aktiviert …
-
169.254.0.0 ist Zeroconf, das kann mit DHCP und oder IPv6 zusammenhängen. Finde ich jetzt nicht extrem ungewöhnlich. Was ungewöhnlich ist, sind die Art der Blocks, dass nämlich immer Ack Pakete geblockt werden. Das impliziert, dass der SYN erlaubt wurde, dann muss aber eigentlich der Stateful Filter auch die Acks erlauben.
Ich sehe den ersten Block der WAN Logs eher als Kommunikationsversuch zwischen dem Kabelmodem zur pfSense. Wenn ich allerdings
192.168.0.2 = ist die DHCP-Adresse am WANport der pfSense
lese, gruselt es mich. Bei solchen Routerkaskaden nutzt man kein DHCP. Nie. Das macht keinen Sinn weil es mehr Ärger macht als sonstwas. Wenn man Router kaskadiert, dann nach einem bestimmten Schema (.1 und .2 oder .1 und .254 oder ähnliches) aber spielt nicht mit DHCP rum, da es sonst gern vorkommt, dass sich IPs verstellen oder ein DHCP Handshake nicht klappt o.ä.
Dass aber jeweils nur Acks geblockt werden finde ich ebenfalls dubios.
-
DANKE für dein Feedback :) !!
169.254.0.0 ist Zeroconf, das kann mit DHCP und oder IPv6 zusammenhängen. Finde ich jetzt nicht extrem ungewöhnlich.
Auf der WAN der pfSense ?
Da ist doch nur der Kabelrouter an dem nur ich mit der pfSense hänge, auf der anderen Seite ist ja "nur" die öffentliche IP von upc.at
Woher kann dann dieser Zugriff kommen ?Was ungewöhnlich ist, sind die Art der Blocks, dass nämlich immer Ack Pakete geblockt werden. Das impliziert, dass der SYN erlaubt wurde, dann muss aber eigentlich der Stateful Filter auch die Acks erlauben.
Da ich Newbie bin, bin ich noch nicht so tief in die Terminologie der pfSense vorgedrungen, somit sind mir die Begriffe "SYN" oder "ACK" noch nicht so geläufig - bitte Milde walten lassen :)
Was bedeutet das ?Wenn ich allerdings
192.168.0.2 = ist die DHCP-Adresse am WANport der pfSense
lese, gruselt es mich. Bei solchen Routerkaskaden nutzt man kein DHCP. Nie. Das macht keinen Sinn weil es mehr Ärger macht als sonstwas. Wenn man Router kaskadiert, dann nach einem bestimmten Schema (.1 und .2 oder .1 und .254 oder ähnliches) aber spielt nicht mit DHCP rum, da es sonst gern vorkommt, dass sich IPs verstellen oder ein DHCP Handshake nicht klappt o.ä.
Das ist Absicht - aus zwei Gründen:
1. Sobald ich einen anderen Kabelrouter von upc.at erhalte, der "BRIDGE" kann, dann brauche ich - denke ich - eh ein DHCP um die öffentliche IP beziehen zu können (eine statische IP habe ich nicht, da derzeit kein Bedarf an z.B. Hosting von irgendwas oder Zugriff von WAN auf das LAN besteht) … ohne DHCP würde ich dann kein Internet haben, oder ?
2. Ich habe es mit einer statischen IP am WAN der pfSense versucht, warum auch immer, es gab immer Probleme ... anscheinend hat der Kabelrouter eine Make ...
3. Am Kabelrouter ist auf der LAN-Seite ein 192.168.0.0/30 Netz konfiguriert (SubNet 255.255.255.252) somit nur zwei nutzbare IPs .1 für den Kabelrouter und .2 für die pfSense (wenn ich es richtig verstanden habe ist dann .0 das Netz und .3 Broadcast) …Von welchem Ärger sprichst du, worauf muss ich achten ?
.254 beim /30 Netz ist nicht möglichWie schon geschrieben der FW-Log verunsichert mich als Newbie :-[ da ich es noch nicht wie die Profis hier interpretiern kann ..
-
Auf der WAN der pfSense ?
Da ist doch nur der Kabelrouter an dem nur ich mit der pfSense hänge, auf der anderen Seite ist ja "nur" die öffentliche IP von upc.at
Woher kann dann dieser Zugriff kommen ?Weil das Guffelmodem von Kabelanbietern sehr häufig auf DHCP konfiguriert ist, weil normaler Dummy-User im Normalfall nichts mit Konfiguration zu tun haben möchte? Insofern ist bei den Büchsen meist Default, dass sie DHCP oder Autoconf machen. Deshalb halte ich das nicht für irrsinnig seltsam, mitunter haben einige Provider auch ihr Bridging auf den Modems nicht im Griff und du siehst Multicast oder andere Zugriffe vom Rest des Netzes (gabs in den Anfangszeiten von Unitymedia bspw.)
Was bedeutet das ?
das hat nichts mit pfSense zu tun, das ist TCP Basiswissen. TCP Verbindungen kommt durch ein 3-Wege Handshake zustanden: Syn, Syn Ack und Ack. Symbolisiert durch entsprechende TCP Flags wie S, SA und A. Da die Sense hier A Pakete blockt ist seltsam, da das der 3. Schritt des Handshakes ist. Wenn sie aber den ersten Schritt (SYN) durchlässt, wird normalerweise ein State erzeugt, der der Firewall sagt: alle weiteren Verbindungen dieser Sitzung durchlassen, ergo sollte auch der ACK durchgelassen werden. Einziges Mal, dass man sowas mitunter sieht, ist erwähntes asymetrisches Routing, wenn irgendjemand bspw. ein anderes Default Gateway hat. Dann läuft eine Verbindung mitunter einen falschen Rückweg o.ä. und damit bekommt die Firewall Pakete, die sie initial noch gar nicht kennt. Deshalb ist das verwunderlich.
Gründe…
zu 1) Nein. Je nachdem was upc.at dir sagt, wirst du eher eine fixe IP konfigurieren. Natürlich kanns auch DHCP sein, aber das ist kein Grund, das jetzt auch schon mit DHCP zu machen, da in solch einem Setup wie gesagt DHCP fehleranfällig ist.
zu 2) Der Kabelrouter hat nicht zwangsweise eine Macke, wenn was falsch konfiguriert ist ;)
zu 3) Das ist die einzig valide Konfiguration, dass man DHCP akzeptieren kann.
Ärger:
- IP ändert sich
- durch Probleme beim Modem/Router/WAN Port/Verzögerung hat die Sense plötzliche für kurze Zeit keine IP weil das Lease abgelaufen ist
- diverse Mechanismen werden bei neuer Adresse auf der pfSense aktiviert, die unnötig sind, da sich effektiv nichts ändert (DynDNS aktualisieren, VPN Tunnel neu aufbauen, etc.)
usw.
Dass .254 bei einer /30 Konfiguration nicht möglich ist, ist mir auch klar ;) Aber niemand zwingt dich DHCP zu nutzen, du kannst auch einfach manuell die gleiche Konfiguration übernehmen, die jetzt per DHCP gepusht wird. Das sollte auf alle Fälle funktionieren, wenn nicht jemand arg schwarze Magie in der Routerkiste eingebaut hat.
-
Danke für dein Feedback !!
Könntest du mir auch noch die Bedeutung der Option am Interface WAN „Alias IPv4 addresses“ ?
„Reject Leases From“ … bedeutet das, dass wenn ich den WAN auf eine statische IP umstellen würde, hier die IP des DHCPs des Kabelrouters eintragen müsste/sollte 192.168.0.2 oder ist das etwas ganz anderes ?
DANKE vorab !!
-
„Reject Leases From“
…gibt es nur bei Typ DHCP. Bei Static gibt es diese Einstellung logischerweise nicht. Warum auch, was sollte denn verworfen werden? Es läuft kein DHCP Prozess.
Alias IPv4 addresses
Die ganzen Einstellungen gibt es nicht bei statischer Konfiguration. Diese beziehen sich lediglich auf den DHCP Client.
Quote: Sometimes you need an IP alias in addition to a DHCP lease, that's its purpose, it should virtually always be left blank.
