PfSense: Squid-Zugang trotz fehlender Firewall-Regel

Moin,

hast du ne any to any rule aktive? ich kann das hier nicht bestätigen.

Ansonsten eben sowas hier:

ist bei allen System Zugriff aus dem Internen Lan zumindest zum GW möglich? Dann hast du ja den Grund.

Das heisst du hat das 30er netz in einem Parent Interface und arbeitest auf der Physik mit VLAN Subinterfaces und gehst mit einem Tagged Uplink auf die pfSense ?? Ist das so richtg ?
Also so wie hier im Beispiel beschrieben:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Ok gehen wir dann mal davon aus das dem so ist.
Wenn du dann auf dem VLAN Interface einzig nur als Source vlan30_net und als Desination any und Zielport UDP/TCP 53 (DNS) und UDP 123 (NTP) zulässt, dann kann ein Client an diesem Port gar nix machen.
Er kann lediglich Hostnamen auflösen aber alles andere scheitert dann sofort am Regelwerk des Interfaces. Nichtma ein Ping ist dann möglich.
Hier kann man nur davon ausgehen das du einen gravierenden Fehler in deinen Firewall Regeln am VLAN Subinterface gemacht hast.
Ein Screenshot wäre hier hilfreich.

Das ist dann so das das das VLAN Interface quasi deine DMZ ist in dem der Squid Proxy hängt und das native Interface dann das mit den Clients ist richtig ?
Am Client Seegment wenn du da doe Proxy Nutzung erzwingen willst darf dann nur DNS, NTP und TCP 3128 erlaubt sein. Dann könnten die Clients nur auf den Proxy zugreifen.
Erschwerend kommt vermutlich noch dazu das du den Proxy Server nur one armed (einbeinig) angeschlossen hast, oder ? Das bedeutet dann das sowohl eingehender Traffic auf dem Proxy als auch ausgehender Richtung Internet über ein und daselbe physische Interface rennt.
Ohne einen Screenshot der Regelwerke auf VLAN und native Interface kommen wir vermutlich nicht weiter, denn nur da dürfte der Fehler liegen.

Ich wollte darauf hinaus, was aqui auch angesprochen hat.

Wenn du "nur" DNS und NTP erlaubts läuft doch garnichts?
Allerdings lässt sich der Squid auch als Scheunentor konfigurieren.. Das wird bei dir wohl der Fall sein, Im "Normalfall" ist dies aber nicht so!

Das ergibt Sinn ;)

Dazu 2 Fragen:

• 1. VLAN 1 ist also nur eine Nummerierung und ncht das native VLAN 1, richtig ?? VLAN 1 wird in der Regel immer untagged übertragen und kann bei vielen Herstellen nicht getagged werden.
• 2 VLANs mit 30er Netz ?? Wie sr das gemeint 2 unterschiedliche 30er Netze ?? also sowas wie 10.1.30.0 /24 und 10.2.30.0 /24 ?? Alles andere wäre nicht möglich da nicht routebar.

Das ist doch eigentlich ganz einfach...
In den VLANs wo die Clients sind blockierst du TCP 80 und 443 inbound damit die nicht direkt ins Internet können. Du lässt nur das durch was die so dürfen sollen.
Dann aktivierst du mit einer zeitgesteuerten ACL Regel den Zugriff auf den Proxy wennimmer du das willst.
Damit können diese Clients dann zu diesen Zeiten via Proxyport 3128 ins Internet.
Das ist doch eigentlich ganz einfach umzusetzen....?!
Technisch ideal wäre es wenn die pfSense z.B. auf einem APU Board:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
rennen würde mit 3 physischen Ports und du einen dedizierten DMZ Port hättest für den Server. Dann könntest du den dadrin belassen und müsstest nur das LAN Interface mit den Client VLANs aufteilen. Das würde dein Regelwerk etwas vereinfachen und auch die Performance Richtung Internet erheblich entzerren.

OK, dann war das richtig verstanden...
OK, dann ist das auch geklärt. Du meist also einen /30er Prefix. Hättst du auch gleich sagen können dann wäre das kein Verwirrspiel geworden
Das bedeutet dann aber nur 2 Hostadresse pro DMZ. Eine geht für die pfSense drauf kannst du nur einen Server noch nehmen. Was soll da der tiefere Sinn sein ?? Oder hat bei dir jedes Client VLAN auch sein dediziertes DMZ VLAN ??
Das würde dein ursprüngliches Design noch viel fragwürdiger sein das alles über einen Port zu schieben.
Kein wirklich gutes Design
Da wäre es in der Tat erheblich besser das auf 3 Interfaces zu entzerren.
Dann könntest du auf dem DMZ Port die VLAN Subinterfaces setzen und auf dem LAN Port nur die Client VLANs.
Erheblich sinnvoller sowohl von der Logik des management als auch von der Performance.
Absolut !
Nein, das ist ein unsinniger Trugschluss, denn der gesamte Traffic aller Client und DMZ Segmente trifft sich bei dir auf einem einzigen physischen Port.
Und das gleich mehrfach, da er mehrere virtuelle Interfaces passieren muss dabei aber immer wieder über die physische NIC geschickt wird.
Nehmen wir mal an das das die üblichen 1 Gig sind dann hast du hier sehr sehr schnell ein Engpass. Da nützt dann auch ein Xeon herzlich wenig....
Darum geht es auch gar nicht. Du machst schon beim Prozip ein Denkfehler. Wichtig ist es doch wiederkehrenden Traffic immer und immer wieder durch die gleiche physische NIC zu quetschen.
Clieht Traffic soll da bleiben wo die Client sind und DMZ Traffic da wo die DMZ ist.
Deshalb solltest du das zwingend mit einer 3ten NIC entzerren. Es gibt sehr sehr preiswerte 4 Port Intelkarten auch im Low Profile. Das wären 4 Port s dann.
Außerdem muss man dafür keinen XEON glühen lassen. Ein normales APU2 Board hat die 3 NICs und verbraucht 20 Euro Strom im Jahr im Vergelich zu 200 beim Xeon.
Nur mal so zu nachdenken

Das sollte auch keine Kritik sein an dir als Person sein aber wenn du mal deinen gesunden Menschenverstand bzw. IT Verstand walten lässt dann musst du fairerweise schon zugeben das das Design gemessen an dem was du machst dort suboptimal ist.
Kein verantwortungsvoller Netzwerker würde das so machen. Allein die physische Vermischung schon von sicherheitsrelevantem Traffic mit Client Traffic ist nicht gut wenn man es auf ein klassisches FW Design runterbricht. Von den Performanceeinbußen auf dem System selber mal gar nicht zu reden. Wären dir interne Aufbauten von NIC Chipsätzen etwas geläufiger wäre auch keine Rede von Glaubenskrieg.
Aber zugegeben. Hintergründe dazu usw. kann ein Forum ja niemals liefern und deshalb führen solche doch eklatant sichtbaren Fehler dann immer zu solchen Diskussionen auf beiden Seiten. Eine evidente und auch menschlich normale Reaktion und Folge.
Aber nun gut, du machst klar das du weisst was du tust und das ist dann auch gut so. Case closed!
Der Fehler liegt ganz klar in deinen Firewall Regeln, soviel wenigstens ist absolut sicher. Die Firewall selber hat keinerlei Bugs was das Regelwerk anbetrifft in der 2.3.3er Version. Da sprechen die Release Notes eine mehr als eindeutige Sprache.