eigenes Geoblocking für eine IP Adresse umgehen

[shb256]

Hallo,

ich habe auf der WAN Schnittstelle in der Richtung OUT geoblocking aktiviert.
Nun möchte ich für eine IP das geoblocking umgehen. 192.168.178.220/32

leider wir die IP Adresse trotzdem geblockt.
Ich erwarte eigentlich, dass die Regeln von oben nach unten abgearbeitet werden und nach dem first match einfach durchgelassen werden

hier das Netzwerk:

Code Select Expand

Ethernet-Adapter Ethernet 5:

   Verbindungsspezifisches DNS-Suffix:
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.220
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.178.1

Wenn ich die zweite Regel deaktiviere komme ich auf die Webseite - aber dann logischerweise von allen

Ich glaube ich sehe den Wald vor lauter Bäumen nicht

Für hinweise bin ich dankbar

[Patrick M. Hausen]

Vielleicht benutzt das Endgerät IPv6?

[shb256]

Leider nicht, ich habe eine IPv4 die ich erreichen möchte

[Patrick M. Hausen]

Firewall live view, tcpdump ...

[tiermutter]

Sollten solche Regeln nicht besser auf LAN (...) in erstellt werden?

Wie ist es denn bei WAN out? Ist da überhaupt noch die LAN IP die Quelle oder ist hier schon NAT im Spiel sodass die LAN IP gar nicht relevant ist?

[kruemelmonster]

Sollten solche Regeln nicht besser auf LAN (...) in erstellt werden?

Wie ist es denn bei WAN out? Ist da überhaupt noch die LAN IP die Quelle oder ist hier schon NAT im Spiel sodass die LAN IP gar nicht relevant ist?

Ich habe die Woche eine Regel auf dem WAN erstellt, um den Internetzugang für eine IP aus dem LAN zu unterbinden. Hat nicht funktioniert (Auf dem Lan als eingehend eingerichtet, funktioniert das sehr wohl). Insofern bestätigt das deine Vermutung.

[Patrick M. Hausen]

Sollten solche Regeln nicht besser auf LAN (...) in erstellt werden?

Good catch! Hatte ich völlig übersehen. Natürlich müssen die Regeln auf LAN eingehend.

[tiermutter]

Weil ich es nur vermute:
Ist es in dem Fall denn so, dass hier schon das NAT erfolgt ist und die angegebene LAN IP als source daher nicht berücksichtigt wird? Oder ist es ein anderer Grund weshalb das so nicht funktioniert?

[tiermutter]

Oder anders gefragt, an welchem Punkt findet das NAT denn statt?
a) LAN in > LAN out > NAT > WAN in > WAN out
b) LAN in > LAN out > WAN in > NAT > WAN out
c) LAN in > LAN out > WAN in > WAN out > NAT

[JeGr]

NAT findet immer IN der Firewall statt.

Interface Regeln gelten AUSSEN beim EINTRITT in die Firewall. Daher sind alle Interface Regeln per default IN und QUICK (was sie auch bleiben sollten die meiste Zeit wenn man nicht explizit weiß was man tut).

Bei NAT hängt es also davon ab, von was wir sprechen:

- ingress NAT oder Port Fowardings sind natürlich auch IN und daher VOR Regeln angewendet. Erst wird umgestempelt, dann gefiltert.
- egress NAT oder Outbound NAT betrifft Kram der aus der Firewall auf dem definierten Interface OUTgoing rausgeht. Wird also auch erst beim Verlassen der Firewall angewendet - wieder VOR dem Filter.

Prinzipiell: NAT vor FILTER aber eben an der entsprechenden Stelle je nach Art von NAT. :)

Also:

-> NAT FW -> LAN IN -> Firewall -> NAT WAN OUT -> WAN out ->

@tiermutter:
Dein in/out Verständnis ist an der Stelle falsch, es geht nicht durch IN UND OUT, sondern nur auf dem einen Interface IN und auf dem anderen OUT. Umgekehrte Richtung hat dann umgekehrte Vorzeichen:

-> NAT WAN IN -> WAN IN -> Firewall -> NAT LAN OUT -> LAN OUT ->

Da default eine schwebende "pass out any" Regel ohne quick definiert ist, wird per default ausgehend alles erlaubt aus jedem Interface, was logisch ist, da man den Traffic erstmal "rein" lässt und dabei normalerweise filtert. Daher werden selten OUT Regeln benötigt und nur in spezifischen Situationen, der Rest sollte der Übersichtlichkeit halber besser default inbound gefiltert sein um Überraschungen zu vermeiden.

Cheers

[Patrick M. Hausen]

Oder anders gefragt, an welchem Punkt findet das NAT denn statt?
a) LAN in > LAN out > NAT > WAN in > WAN out
b) LAN in > LAN out > WAN in > NAT > WAN out
c) LAN in > LAN out > WAN in > WAN out > NAT

Es finden nie (selten? müsste jetzt überlegen einen Fall mit NAT und gesetztem Gateway zu konstruieren, für den das trotzdem passiert) "in" und "out" Prozesse für dasselbe Paket am selben Interface statt.

Standardfall: Client intern schickt Paket mit NAT ins Internet.

LAN in -> NAT -> WAN out

Warum sollte es da ein "LAN out" oder ein "WAN in" geben?

Anderer Fall: Portforwarding von außen auf einen Server innen:

WAN in -> Port Forwarding/NAT -> LAN out


Den Rest hat Jens ja schon geschrieben.  ;)

[tiermutter]

Ich hatte mir das so vorgestellt, dass etwas vom Client kommt (LAN in) und dann ja entsprechend an das nächste Interface übergeben wird. Bei dieser Übergabe habe ich mir vorgestellt, dass dann LAN out kommt und entsprechende Regeln greifen, bevor es am nächsten Interface angekommen ist und verarbeitet wird...

Dann lassen wir diese fehlerhaften Gedanken mal außen vor, somit wäre meine (bereits beantwortete) Frage gewesen:

... an welchem Punkt findet das NAT denn statt?
a) LAN in > NAT > WAN out
b) LAN in > NAT > WAN out (erübrigt sich nun)
c) LAN in > WAN out > NAT

Für das eigentliche Thema würde c) ja bedeuten, dass die erstellte Regel funktioniert. Für Fall a) (und b)) hat diese Regel somit keine Wirkung.
Meine Vermutung wurde damit bestätigt... ein Mitschüler aus der Meisterschule sagte immer "nicht nur wissen, sondern auch verstehen.", genau darum ging es mir :)