ARF zu Squid klappt nicht

[pal]

Hallo,

ich sitze mal wieder fest und komm keinen Schritt weiter - vielleicht könnt ihr mir ja helfen. Das Routing will einfach nicht klappen aber mal von Anfang an.

Ich habe ein paar interne Netzwerke an einem 1711er. Die Netze sind per VLAN voneinander getrennt. Bei meinem Problem verwende ich Netz 'DMZ' und Netz 'INTRANET'. Die Netze sind alle vom Typ 'Intranet' und nicht 'DMZ'.
Netz 'INTRANET' hat VLAN-ID 4, Tag 5 und Typ 'INTRANET'.
Netz 'DMZ' hat VLAN-ID 8, Tag 6 und Typ 'INTRANET'.
Um nun von 'INTRANET' auf 'DMZ' zugreifen zu können sind die entsprechenden Regeln in der Firewall jeweils mit Tag 6 versehen. Das klappt soweit ja schon seit einiger Zeit.
Nun kommt der Squid-Proxy ins Spiel. Dieser befindet sich im Netz 'DMZ' soll aber auch von 'INTRANET' genutzt werden. Damit das ganze transparent ist, habe ich eine Route zum Squid mit Tag 2 eingetragen. In der Firewall entsprechend eine Regel für HTTP erstellt, die die Pakete mit Tag 2 versieht. Das Problem ist, dass die Regel zwar angewandt wird aber anscheinend nicht akzeptiert wird. Aus irgend einem Grund greift die allgemeine Regel 'COMMON_WEB->OUT'.
Hier ist das Firewall log:

Code: Alles auswählen

[Firewall] 2011/02/24 17:36:42,911  Devicetime: 2011/02/24 17:36:42,950
Packet matched rule JBOESL->HTTP_OUT
DstIP: 88.198.177.34, SrcIP: 192.168.44.130, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 49607, Flags: S
Seq: 1543571680, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 2 (multiply  by 4)
Option: NOP
Option: NOP
Option: SACK permitted

[Firewall] 2011/02/24 17:36:42,911  Devicetime: 2011/02/24 17:36:42,950
Packet matched rule COMMON_WEB->OUT
DstIP: 88.198.177.34, SrcIP: 192.168.44.130, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 49607, Flags: S
Seq: 1543571680, Ack: 0, Win: 8192, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 2 (multiply  by 4)
Option: NOP
Option: NOP
Option: SACK permitted

packet accepted

Ich hab schon allerlei Kombinationen versucht, allerdings mit keinem Erfolg. Einen Schritt weiter kam ich, indem ich das Netz 'DMZ' auch auf Typ 'DMZ' gestellt hab. Dann hat das Routen funktioniert, allerdings konnte ich dann mit den Rechnern aus dem Netz 'DMZ' nicht mehr per HTTP aufs Internet zugreifen. Die Maskierung beim Routing war dabei richtig eingestellt (also auf 'Maskierung An'.

Ich nehme an, mein erster Weg war einfach nie sie im LCOS vorgesehen und funktioniert deswegen nicht. Der zweite müsste ja eigentlich klappen. Hmmm...

Hat jemand nen Tipp für mich?

[Jirka]

Hallo pal,

gibt es einen bestimmten Grund, warum Du das Netz "DMZ" nicht dem Typ DMZ zugeordnet hast?
Ist die Maskierung auf "An" oder "An (nur Intranet)" gestellt?
Wie sehen die beiden Firewall-Regeln, insbesondere die "JBOESL->HTTP_OUT" genau aus?

Viele Grüße,
Jirka

[pal]

Hallo Jirka,

vielen Dank, dass Du dir Zeit nimmst.
Es gibt 'eigentlich' keinen genauen Grund, warum alle Netze auf Typ 'INTRANET' gestellt sind. Es kommt von der initialen Konfiguration. Damals wollte ich alles so sicher wie irgend möglich einstellen. Und die Möglichkeit den Zugriff zwischen den Netzen nicht nur durch Firewall-Regeln, sondern auch noch zusätzlich durch Routing-Regeln zu unterbinden erschien mir als sauberer. Im prinzip könnte ich wohl auch alle Netze auf Typ 'DMZ' stellen.

Die Maskierung ist auf "An" (gilt also auch für Typ 'DMZ') gestellt. Allerdings in einer extra Routing-Regel für das DMZ-Netz mit 'Tag 6'.

Die Firewall-Regel kann ich Moment nur beschreiben:
JBOESL->HTTP_OUT:
Routing-Tag 2, Firewall-Regel Aktiv
Regel: Accept
Netz: Quelle: JBOESL (192.168.44.130)
Protokoll: Ziel: TCP/80,443

Gruß,
pal

[pal]

Hallo Forum,

jetzt hab ich gestern im Prinzip den ganzen Tag versucht das Routing hinzubekommen. Ich bin jetzt zu dem Schluß gekommen, dass entweder das LCOS einen Fehler hat, oder ich einfach ein komplett falsches Verständnis von den Mechanismen hab. Aber mal wieder von Anfang an ...

Eigentlich wollte ich nur schnell einen transparenten Proxy (Squid) in die DMZ stellen, über den dann alle HTTP-Anfragen geroutet werden. Da ich alle Netze mit Schnittstellen Tags versehen hatte und alle (fast alle) Netze vom Typ 'Intranet' waren, funktionierte das Routing aus dem internen Netz per Routing Tag, an einen Rechner in einem anderen Netz, nicht. In das andere Netz kann ich nur routen wenn ich das Schnittstellen-Tag des anderen Netzes setze. Wenn ich allerdings das Routing-Tag der Route setze, die den Squid-Rechner in der DMZ als Router beschreibt, wird nie in die DMZ geroutet.
Nun gut ... dann klappt sozusagen 'mehrstufiges ARF' nicht. Ist in Ordnung.

Plan B: Das Netz in dem der Proxy steht als 'DMZ' deklarieren.
Hier wirds jetzt unverschämt (meiner Ansicht nach). Ich glaub ich muss auch ein bisschen ausholen.
Wie gesagt war Plan B, das DMZ-Netz als Typ 'DMZ' einzustellen. Damit ist das Netz ja von jedem anderen Netz aus 'sichtbar'. Das hat erstmal nicht geklappt. Ich bin zwar nun zum Squid geroutet worden, aber der Squid kam nicht mehr ins Internet. Das naheliegendste war erstmal die Maskierungseinstellungen der Route. Die Default-Route war auf 'nur Intranet maskieren' gestellt. Deshalb hab ich auch eine neue Route definiert, mit dem Routing-Tag des DMZ-Netzes (Tag 6) wo ich angegeben hab, dass alles maskiert werden soll. Bis ich dann rausgefunden hab, dass ich den Router beim Ändern der Routing-Einstellungen neustarten muss sind gerarde mal zwei Stunden vergangen. Vorher wurde das DMZ-Netz einfach immer nicht maskiert und ich konnte einstellen was ich wollte.
Jetzt hat eigentlich alles ganz gut ausgesehen. Ich hab ein paar Tests gemacht. Alles hat funktioniert. Naja ... fast alles. Durch Zufall bin ich über den Mailserver gestolpert, der plötzlich von anderen Mailservern nicht mehr akzeptiert wurde. 'No RDNS entry for 62.225.60.115' hieß es. 62.225.60.115 ist die Maskierungsaddresse und der Mailserver sollte eigentlich über 62.225.60.117 raus wo auch der ReverseDNS-Eintrag vorhanden ist. Eigentlich sollte dieser ja weiterhin über die DefaultRoute raus, wo nur Netze vom Typ 'Intranet' maskiert werden. Ich schreib mal kurz die Netze hin:

Code: Alles auswählen

	       Typ      Tag  IP             Netzmaske
INTRANET: Intranet 5    192.168.40.10  255.255.248.0
DMZ:      DMZ      6    172.23.40.10   255.255.255.0
EXTRANET: DMZ      11   62.225.60.115  255.255.255.248

Extranet war schon immer ein DMZ-Netz, weil die Adressen dort nicht maskiert werden sollen, sondern dort direkt die externen Adressen verwendet werden.
Da nun die Rechner aus dem DMZ-Netz korrekt maskiert wurden, allerdings die aus dem Extranet-Netz fälschlicherweise ebenfalls maskiert wurden, hab ich die Routingtabelle nochmal erweitert:

Code: Alles auswählen

IP-Adresse       Netzmaske  Routing-Tag  Router        Maskierung
255.255.255.255  0.0.0.0    11           T-COMPCO      An (nur Intranet)
255.255.255.255  0.0.0.0    6            T-COMPCO      An
255.255.255.255  0.0.0.0    2            172.23.40.12  Aus
255.255.255.255  0.0.0.0    0            T-COMPCO      An (nur Intranet)

Erstmal hat die Änderung wieder keine Wirkung gezeigt. Nach einem Neustart dann die Änderung: Netz Extranet wurde richtig 'nicht maskiert' und Netz DMZ wurde ebenfalls nicht maskiert. Das hat mich jetzt doch etwas verwundert. Nach einigen Änderungen und ebenfalls einigen Routerneustarts hatte ich zum Test folgende Routingtabelle:

Code: Alles auswählen

IP-Adresse       Netzmaske  Routing-Tag  Router        Maskierung
255.255.255.255  0.0.0.0    123          T-COMPCO      An
255.255.255.255  0.0.0.0    0            T-COMPCO      An (nur Intranet)

Das (zumindest für mich) sehr verblüffende Ergebnis war, dass alle Netze vom Typ DMZ Maskiert wurden. Obwohl das Routing-Tag nirgends verwendet wird. Daran konnten auch Firewall-Regeln mit Routing-Tags und auch noch mehr Neustarts nichts rütteln.
Für mich sieht das nach einem fehlerhaften Verhalten aus.

Ich werd jetzt nun wohl erstmal auf den Proxy verzichten. Mal sehen ob Ihr noch nen Tipp habt. Evtl. frag ich ja auch mal direkt bei Lancom nach.
Danke fürs Lesen.
Gruß,
PaL

[backslash]

Hi pal

In das andere Netz kann ich nur routen wenn ich das Schnittstellen-Tag des anderen Netzes setze.

das ist der Sinn des ARF...

Wenn ich allerdings das Routing-Tag der Route setze, die den Squid-Rechner in der DMZ als Router beschreibt, wird nie in die DMZ geroutet.

das kann ja auch nicht funktionieren, denn der Router würde ein Netz mit dem Tag suchen und dabei nicht fündig werden...

Du mußt die Route zum Squid mit dem Tag versehen, das das Netz hat, in dem der Squid steht.

Hier wirds jetzt unverschämt (meiner Ansicht nach).

nein, du verstehst nur den router nicht...

Wie gesagt war Plan B, das DMZ-Netz als Typ 'DMZ' einzustellen. Damit ist das Netz ja von jedem anderen Netz aus 'sichtbar'.

das wäre prinzipiell die perfekte Lösung... nur leider hast du folgendes Problem zwar gesehen

Ich bin zwar nun zum Squid geroutet worden, aber der Squid kam nicht mehr ins Internet. Das naheliegendste war erstmal die Maskierungseinstellungen der Route. Die Default-Route war auf 'nur Intranet maskieren' gestellt.

aber irgendwie völlig falsch gelöst...

Dein Problem ist, daß du sowohl eine öffentliche DMZ (=> "EXTRANET") als auch den Squid in einem getrennten Netz mit privaten Adressen haben willst. Hinzu kommt, daß der Maskierungs-Schalter nicht routenabhängig, sondern eine Eigeschaft der Gegenstelle ist, d.h. es gilt das, was beim ersten Aufauchen einer Gegegstelle in der Routing-Tabelle steht...

Hier bleibt dir nur, entweder den Squid in die DMZ "EXTRANET" zu stellen - oder aber in ein eigenes Netz vom Typ "Intranet". Im letzen Fall muß die Route zum Squid halt mit dem Tag dieses Netzes versehen werden... Ebenso muß in der Firewall die Regel, die den Traffic zum Squid abgreift mit dem Tag versehen sein. Damit ergeben sich bei dir folgende Netze

Code: Alles auswählen

          Typ      Tag  IP             Netzmaske
INTRANET: Intranet 5    192.168.40.10  255.255.248.0
SQUID:    Intranet 6    172.23.40.10   255.255.255.0
EXTRANET: DMZ      11   62.225.60.115  255.255.255.248 

Regeln

Code: Alles auswählen

Rtg-Tag: 6
Aktion:  übertragen
Quelle:  lokales Netz INTRANET
Ziel:    alle Stationen
Dienste: HTTP, HTTPS

und Routen

Code: Alles auswählen

IP-Adresse       Netzmaske  Routing-Tag  Router        Maskierung
255.255.255.255  0.0.0.0    6            172.23.40.12  Aus
255.255.255.255  0.0.0.0    0            T-COMPCO      An (nur Intranet) 

fertig...

Gruß
Backslash

[pal]

Hallo Backslash,

vielen Dank für die ausführlichen Antworten. Das bringt ein wenig Licht ins Dunkel.

Bei dem ersten Versuch bin ich davon ausgegangen, dass der Router automatisch erkennt, dass das Ziel der Route in der DMZ steht und intern das dann schon richtig löst. Wenn man ein Gerät immer nur über eine gewisse Abstraktion sieht z.B. über die LANconfig-GUI, ohne dabei die interne Logik zu kennen, reimt man sich (oder zumindest ich) nach einer Zeit sein eigenes Modell zusammen. Dass dieses Modell dann mit der Realität nicht immer übereinstimmt, muss man dann leider bei solchen langwierigen Probieraktionen erleben.

Hinzu kommt, daß der Maskierungs-Schalter nicht routenabhängig, sondern eine Eigeschaft der Gegenstelle ist, d.h. es gilt das, was beim ersten Aufauchen einer Gegegstelle in der Routing-Tabelle steht...

Auf die Idee, dass der Maskierungsschalter nicht Routenabhängig sein könnte, bin ich garnicht gekommen. Das heißt ich könnte auch einfach eine neue Gegenstelle für das EXTRANET definieren.
Die andere Möglichkeit wäre dann, wie Du schon gesagt hast, ein eigenes Netz nur für den Squid zu erstellen.

Es ist zwar ein bisschen schade, dass ich dann meine Netzstruktur dem Lancom-Router anpassen muss statt andersrum, aber zumindest sollte es so dann funktionieren. Ich rühr mich hier dann nochmal wenn alles geklappt hat.


Vielen, vielen Dank, Backslash und schönen Gruß,
PaL

[backslash]

Hi pal

Bei dem ersten Versuch bin ich davon ausgegangen, dass der Router automatisch erkennt, dass das Ziel der Route in der DMZ steht und intern das dann schon richtig löst.

Das Problem dabei ist, daß du über das Policy-Based Routing dem HTTP-Traffic einen ARF-Kontext zugewiesen hast - in deinem Fall war das der Kontext 2. Da es aber kein Netzwerk mit dem Interface-Tag 2 gibt, schickt das LANCOM die Pakete dorthin, wo die 172.23.40.12 für diesen Konext sichtbar ist - das ist in diesem Fall nunmal die ungetaggte Defaultroute...


In dem Zusammenhang fällt mir ist da gerade noch ein Problem auf... Wenn du ein eigenes Netz für den Squid anlegst, dann kommt die Session, die der Squid öffnet, aus dem ARF-Kongtext des SQUID-Netzes - hier also 6. Das führt aber dazu, daß die dazugehörenden Pakete wieder auf die mit 6 getaggte Defaultroute treffen und an den Squid zurückgehen... Das muß natürlich verhindert werden - am einfachsten durch eine Firewallregel, die den Traffic, der vom Squid ausgeht, umtaggt, z.B. wieder zurück in den Kontext des Netzes INTRANET. Du mußt also noch eine weitere Firewallregel aufnehmen, die das erledigt:

Code: Alles auswählen

Rtg-Tag: 5
Aktion:  übertragen
Quelle:  IP-Adresse des Squid
Ziel:    alle Stationen
Dienste: HTTP, HTTPS 

In welchen Kontext gemappt wird, ist letztendlich egal - Hauptsache es existiert keine Defaultroute mit diesem Tag, so daß die ungetaggte Defaultroute als Ziel gewählt wird.

Gruß
Backslash

[pal]

Hallo,

mal eine kuze Statusmeldung zum Fortschritt bei mir.
Den Squid hab ich jetzt zum Teil zum Laufen gebracht. Wie Backslash schon gesagt hat, gab es erstmal das Problem, dass der Squid natürlich beim Rausrouten das Schnittstellen-Tag aus seinem Netz hatte und in der Routingtabelle für dieses Tag der Squid selbst als Router eingetragen war. Durch eine Firewall Regel, die dem ausgehenden Traffic ein anderes Tag setzt war das dann schnell behoben. Ich hatte am Anfang noch eine extra Route für dieses Tag definiert, aber wie Backslash ebenfalls sagte, reicht es ja, wenn das Tag noch nicht definiert ist und somit die Default-Route verwendet wird.

Das Problem, das ich jetzt noch habe ist, dass der Router für den Squid einfach nicht als DNS-Server funktionieren will. Evtl. muss ich dafür einstellen, dass die internen Dienste auch über den Router laufen. Mal sehen.
Ich rühr mich wieder, wenn ich dazu mehr weiß.

[backslash]

Hi pal

Das Problem, das ich jetzt noch habe ist, dass der Router für den Squid einfach nicht als DNS-Server funktionieren will.

das sollte er aber - zumindest, wenn du dem Squid als DNS_Server die IP des Router im SQUID-Netz (172.23.40.10) gibst. Wenn du eine andere Adresse (z.b. die des INTRANET) nimmst, dann kommen wieder die ARF-Sichtbarkeiten ins Spiel...

Was sein könnte ist der Punkt, daß bei nicht auflösbaren DNS-Namen der DNS-Server des Providers genommen wird und das Paket über die - zum SQUID-Netz gehörende - Defaultroute weitergeleitet wird. Probier mal in der Regel, die den Traffic des Squid ummappt auch DNS aufzunehmen, also

Code: Alles auswählen

Rtg-Tag: 5
Aktion:  übertragen
Quelle:  IP-Adresse des Squid
Ziel:    alle Stationen
Dienste: HTTP, HTTPS, DNS

wenn das nicht funktioniert, dann mach bitte mal einen DNS-Trace und einen auf "Port: 53" eingeschränkten IP-Router-Trace

trace # dns
trace # ip-router @ "Port: 53"

Evtl. muss ich dafür einstellen, dass die internen Dienste auch über den Router laufen. Mal sehen.

nein... Diese Einstellung hat einen ganz eigenen Sinn und sollte deaktiviert bleiben.

Gruß
Backslash

[pal]

Hallo Backslash,

ich hab den Trace jetzt grad eben mal gemacht.

Code: Alles auswählen

root@lcfw:/
> trace # dns @ "172.23.41."
DNS                 ON  @ "172.23.41."

root@lcfw:/
> trace # ip-router @ +"Port: 53"+"172.23.41"
IP-Router           ON  @ +"Port: 53" +"172.23.41"

Mit schwächeren Filterregeln sind einfach viel zu viele Meldungen gekommen.

Hier was ich am Squid gemacht hab:

Code: Alles auswählen

root@squid:~# nslookup heise.de
Server:   172.23.41.10
Address:  172.23.41.10#53

** server can't find adito.de: NXDOMAIN

Und das passiert am LC1711:

Code: Alles auswählen

[DNS] 2011/03/10 12:39:11,000
DNS Rx (LAN-1, SQUID): Src-IP 172.23.41.12
Query Request: STD A for adito.de
Not found in local DNS database, no route to next DNS server => not forwarded


[DNS] 2011/03/10 12:39:11,000
DNS Rx (LAN-1, SQUID): Src-IP 172.23.41.12
Query Request: STD A for adito.de.squid.local
Not found in local DNS database, query to own domain => not forwarded

Die Firewall-Regel für das RoutingTag bei ausgehenden DNS-Anforderung des Squid hat keine Änderung gebracht. Der Trace auf der Console war identisch.

Mal wieder vielen Dank für die Mühe und Geduld mit mir, Backslash.


Gruß,
PaL

[backslash]

Hi pal,

entschuldige, daß ich jetzt erst antworte, aber ich hatte bisher keine Zeit mir das genauer anzuschauen... Leider kann ich dir nur sagen, daß es bei mir problemlos funktioniert...

Letztendlich bleibt mir hier auch nur ein Achselzucken - es sei denn du hättest mittlerweile keine mit 0 getaggte Defaultroute mehr... Die Meldung "no route to next DNS server" kommt nämlich ganau dann...

Gruß
Backslash

[pal]

Ich hab mich jetzt nochmal mit dem Problem beschäftigt und etwas interessantes herausfinden können. Ich weiß, das Thema ist jetzt schon ein bisschen älter, aber es beschäftigt mich halt immernoch.

Wenn ich nun also als dns query class 'any' angebe, dann kann der Lancom-Router plötzlich einen next DNS-Server finden.

Eingabe am Server:

Code: Alles auswählen

dig @172.23.41.10 adito.de any

Traceausgabe mit den selben Einstellungen wie im letzten Post:

Code: Alles auswählen

root@lcfw2:/
>
[DNS] 2011/07/18 12:19:02,950
DNS Rx (LAN-1, SQUID): Src-IP 172.23.41.12
Query Request: unsupported type/class: 00ff0001 for adito.de
Unsupported request => forward to next server
NameQuery: Forward to locally configured DNS server


[DNS] 2011/07/18 12:19:02,980
DNS Rx (T-COMPCO): Src-IP 194.25.0.52
Query Response:
STD SOA adito.de (TTL = 83840)
  Primary Name Server: ns.udagdns.net
  Authority's mailbox:  hostmaster.united-domains.de
  Serial Number:        1
  Refresh interval:     10800
  Retry interval:       3600
  Expire:               604800
  Minumum TTL:          3600
forward to host 172.23.41.12

[IP-Router] 2011/07/18 12:19:02,980
IP-Router Rx (T-COMPCO, RtgTag: 31):
DstIP: 172.23.41.12, SrcIP: 172.23.41.10, Len: 130, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 38329, SrcPort: 53
Route: LAN-1 Tx (SQUID):

Eine Lösung für mein Problelm ist das zwar nicht, aber vielleicht fällt ja jemandem was dazu ein.
Ich werd nochmal ein bisschen weiterbohren und mich wieder melden wenn ich was finde.

Danke fürs lesen!

[pal]

Hallo,
so hier nochmal ne Rückmeldung. Jetzt klappts endlich auch mit dem DNS-Server des Routers (mittlerweile 1780EW-3G).
Das Netz in dem der Squid-Server steht hatte als Schnittstellen-Tag ebenfalls, wie die Route zum Squid, das Tag 30. Nun hab ich das Schnittstellen Tag auf 0 geändert und schon hat der DNS-Server funkioniert. Das Schnittstellen-Tag des Netzes ist ja egal, weil sowieso in der Firewall das entsprechende Tag für http-Traffic gesetzt wird. Eigentlich ganz einfach - nur draufkommen muss man halt.

Das tolle ist, dass ich jetzt festgestellt habe, dass ich den Squid wahrscheinlich langfristig garnicht als transparenten, sondern als ganz normalen Proxy betreiben will und somit das Ganze sowieso hinfällig ist.

Aber wie auch immer - vielen Dank an alle, die mir mit Tipps geholfen haben und auch an die, die nur gelesen haben

Gruß,
PaL