Netzaufbau Privat

JeGr

@teddy / Marc: Den C5 aber nur in der Rev1 nehmen, nicht 2, die läuft nicht laut OpenWRT Wiki! Dann doch lieber safety first und nen C7 schießen mit Rev2.

Und einen kleinen VLAN Switch - bspw. ebenfalls von TP-Link - gibts auch für schmales Geld, wie den SG105E z.B. sofern 5 Ports genügen: http://j.mp/tp-link-sg105e
Kleiner Nachteil der Kiste ist zwar, dass man die nur via Windows konfigurieren kann (warum frag ich mich schon…) aber trotz schmalem Geld kann der Easy Smart tatsächlich port based und frei definierbare VLANs etc.

Die Einträge die dich stören sind DHCP von der vorgeschalteten Fritzbox (UDP/67 bzw. UDB/68) sowie irgendwelches Windows NETBIOS/AD Geblubber (tcp/135-139 sowie 445). Würde ich zwei Aliase erstellen, P_UDP_trash und P_TCP_trash und auf der WAN Seite einfach als erste Regeln jeden TCP Traffic an Ziel any Port P_TCP_trash sowie UDP Traffic an P_UDP_trash einfach kommentarlos blocken - dann taucht es auch nicht mehr in den Logs auf. Windows Directory Krams willst du auf der WAN Seite eh nicht haben und deine pfSense hinter der Fritte sollte eh statisch konfiguriert sein, also ist es safe DHCP zu verwerfen.

Grüße

MarcM

Hey Moin,

danke für den Hinweis, das habe ich direkt umgesetzt - siehe Screen. Leider bekomme ich die Einträge im Log nach wie vor… Was habe ich falsch gemacht?

Log:

block   Oct 29 07:20 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:20 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:32 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:32 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:44 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:44 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:56 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 07:56 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:08 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:08 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:20 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:20 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:32 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:32 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:44 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:44 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:56 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 08:56 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 09:08 WAN  169.254.1.1  169.254.255.255:138 
block   Oct 29 09:08 WAN  169.254.1.1  169.254.255.255:138

FW-P_TCP-and-UPD_trash.jpg_thumb

JeGr

Das ist von der Regel her schon richtig, aber hast du auch die Ports in das Alias eingetragen, die du rausfiltern willst? ;)

MarcM

Ja, das habe ich gemacht. Offensichtlich nicht korreklt, oder? Habe das noch mal angehängt…

FW-P_TCP-and-UPD_trash2.jpg_thumb

JeGr

Doch, das sieht an und für sich ganz gut aus. Evtl. müsste man die States resetten, aber eigentlich sollten die Regeln so auch greifen. Du kannst das aber in der WebGUI in den Firewall Logs besser prüfen, denn da steht im Gegensatz zu deinem Console Output auch dabei, was für ein Protokoll greift. Ich vermute und denke mich zu erinnern, dass 135:139 UDP, nicht TCP war. Deshalb wirds wohl auch noch nicht geblockt :)

Edit: Jep siehe https://support.microsoft.com/en-us/kb/204279

Trage in der Port Blockliste am Besten in beiden 135:139 sowie 445 einzeln ein (Doppelpunkt heißt hier "von-bis"). Windows benutzt die teils als TCP, teils mit UDP und da läuft im Normalfall auch sonst nichts im Internet, was dich interessieren müsste, deshalb kannst du da auch etwas gröber mit 135:139 filtern :)

jahonix

"Log packets that are handled by this rule" ist sicherlich NICHT aktiviert.
Was ist mit diesen Einstellungen: (see the Diagnostics: System logs: Settings page) ?
Wobei da das Diagnostics falsch ist, denn es müsste "Status: System logs: Settings page" heißen.

Schaue Dir das nach einem Reboot nochmal an, bevor Du erneut postest… :D

JeGr

@Chris: Das Log ist bei den Regeln aus, sonst wäre im Screen das blaue "i" zu sehen. Die 138er Blocks tauchen einfach auf, weil er die via TCP blockt, Windows NETBEUI ist aber 138/udp, deshalb müssen die Ports auch in den UDP Blocker mit rein. :)

Und die Settings Page mit den Hits gegen die Default Block Rule lasse ich meistens an, dann sehe ich nen groben Überblick was da so gegen die FW zimmert und ich vllt. noch wegblocken will um sowas wie 22/tcp bruteforcing zu sehen ;)

MarcM

Moin,

genau das hat es gebracht, danke JeGr. Nach dem ich die mit in den UPD Blocker reingepackt habe, ist es weg. Perfekt. Und nochmals danke.

jahonix

@JeGr:

sonst wäre im Screen das blaue "i" zu sehen

Hast ja Recht, war schlampig von mir drübergeschaut.

MarcM

So Leute, am Wochenende bin ich endlich mal dazu gekommen, den ganzen Kram aufzubauen und vernünftig zu verkabeln. Jetzt habe ich aber folgendes Problem. Ich komme auf das DMZ Netz nicht drauf. Bzw. will ich ja nur auf die Gui der Fritzbox am DMZ-IF…

Das ganze habe ich jetzt wie folgt aufgebaut:
1&1 Internet > Fritte (noch Standardkonfig 192.168.178.0/24) mit LAN1 zur pfSense WAN-IF (192.168.178.29 DHCP). LAN-IF der pfSense zu einem Switch Port 1 glaube ich. Am Switch hängen PCs, die bekommen aber kine IP. Sollen sie aber, die pfSense ist als DHCP Server für LAN und DMZ eingerichtet... Nehme ich das Ethernetkabel von Switch ab und stecke es direkt in meinen Laptop, bekomme ich eine IP aus dem LAN Segment der pfSense. Warum geht das nicht mit dem Switch? Was mache ich hier falsch?

Problem 2:
Am DMZ-IF hängt eine weitere Fritzbox. Diese soll das WLAN übernehmen. Hier habe ich das Netz 192.168.2.0/24 und die Fritte hat die 2.2 bekommen, da die pfSense ja 2.1 hat. Ich habe eine Regel für LAN erstellt "IPv4 * * * 192.168.2.2 * * none". Somit sollte aus LAN zu 2.2 die Verbindung möglich sein. Ein Ping funktioniert, der Zugriff auf die Fritten-Gui leider nicht. Was mache ich auch hier falsch?

Edit:
Bei Problem 2 meldet sich der Squid wenn ich auf http://192.168.2.2 gehen will mit folgender Meldung:

Der folgende Fehler wurde beim Versuch die URL http://192.168.2.2/ zu holen festgestellt:

Verbindung zu 192.168.2.2 Fehlgeschlagen.

Das System antwortete: (61) Connection refused

Der Zielhost oder das Zielnetzwerk ist momentan nicht verfügbar. Bitte wiederholen sie die Anfrage.

Ihr Cache Administrator ist XxX@YyY.de.

LG Marc.

magicteddy

Moin,

folgender Vorschlag: Installiere einfach mal Wireshark auf dem Notebook, starte ein Capture auf der LAN Schnittstelle und dann einmal direkt und einmal mit Switch mit dem LAN verbinden. Da sollten Unterschiede zu Sehen sein.
Taucht was im Log des DHCP Servers auf wenn Du dich mit Switch verbinden willst?
Ohne Switch muss ja was passieren sonst hättest Du keine IP bekommen.

-teddy

JeGr

"… pfSense WAN-IF (192.168.178.29 DHCP)..."

Never ever benutzt man in einer Routingkaskade DHCP. Nie nicht. Das fällt unter die Rubrik "Das kannste schon so machen, aber dann ist es halt kacke". Ist nicht böse gemeint, aber ein #1 Fehler wenn mal wieder irgendein Mist nicht läuft. Du hast hier fixe Geräte also vergib ihnen auch fixe Adressen. Deine Fritte extern ist .1 also mach die pfSense zur .2 oder zur .254. Egal wie, aber gib ihr ne statische IP. Sonst wird das murks. Wenn du Traffic von außen sonst reinleiten willst, klappt das mit den Portforwardings nicht richtig.

Zu Problem 2: Warum den Zugang zu den Fritten via Proxy handeln, lass die einfach direkt durchs Routing durch.

MarcM

Ich werde die 1. Fritte 192.168.0.0/24 machen. Das LAN 192.168.1.0/24 und die DMZ 192.168.2.0/24.

Wie kann ich den Proxy umgehen? Habe den derzeit als transparenten Proxy eingestellt. Da wird wohl alles drüber gehen dann oder?

MarcM

Moinsen,

wie muss ich das mit dem Proxy einstellen genau? Er sollte vorerst schon als transparent laufen, da er von den PCs und Handys nicht umgangen werden sollte. Und das geht nun mal denke ich nicht anders, oder denke ich hier grade um falsche Ecken?

Langsam läuft der Thread hier voll mit 27 verschiedenen Themen, aber nun gut, ist ja auch im Titel allgemein gehalten. Es geht ja um meinen Netzaufbau 8)

Ich habe noch ein Verständnissproblem mit Routing und Gateway…
Muss ich mehr einstellen, als das Gateway für WAN? Also das ist ja klar, das ist die Fritte die am Inselnet hängt. Also bislang noch die 192.168.178.1. Das ist auch als default GW markiert. Mehr brauche ich nicht einzurichten, oder? Alle anderen (LAN und DMZ) gehen über das 178.1 GW raus, richtig?

Besten Dank, Marc.