PF: redirect mal ungewönlich

P

plepps

Active Member
Hallo,

ich habe ein kleines PF Problem.
es geht um eine Firewall welche zwei interne LAN verbindet

LAN1: 1.1.1.0/24
em0 FWIP1: 1.1.1.1

LAN2: 10.10.10.0/24
em1 FWIP2: 10.10.10.1

SRC

Es sollen jetzt Anfragen aus einem 3. Netz 2.2.2.0/24 welches via LAN1 ankommt ins LAN2 gehen. Jetzt sind Adressen aus LAN1 für LAN3 Tabu. Fragt nicht warum, es ist einfach so.

Sprich ich will folgende Verbindung einrichen:

2.2.2.1 -> 10.10.10.1 redirekt zu 10.10.10.50

Host im LAN3 Spricht direkt die FWIP2 an, nicht wie eigentlich üblich die FWIP1 und wird dann zu einem Host im LAN2 redirektet.

Bissl schräg, ich weis.

Versucht habe ich es mit:
match in on em0 proto tcp from 2.2.2.1 to 10.10.10.1 port 4711 rdr-to 10.10.10.50

ich sehe zwar den pass im pflog, aber es klappt nicht. Wo ist mein Denkfehler?

thx,
plepps
 
Hi,
ich würde mal schauen ob die Netze übärhaupt in den Routing Tabellen korrekt eingetragen sind.
Evtl. weiss außer Dir kein Routebär was Du da veranstalten möchtest und routed die Paketbären daher auch nicht wirklich zum Ziel. Die mittels NAT nochmals unsinnig umzuschreiben macht die Probleme sicher nur größer und nicht kleiner. Der Natbär sollte auch noch wissen woher und wohin um die eingehenden Verbindungen wieder zuordnen zu können. Das wird bei solchen sinnbefreiten Konstruktionen sicher nicht besser sondern eher schlechter.

Gruß Bummibär
 
Mir ist der Unsinn dahinter schon klar.
lan3 verbindet sich bereits zu Hosts im lan2 direkt, also das routing ist ok.
Ziel ist es für den Kunden aus LAN3 die Verbindungen zu LAN2 tranparent ändern zu können.
Ich könnte auf den LAN2 Hosts natürlich Alias-Adressen nehmen und diese dann ggf. auf einen anderen Host schwenken. Eleganter wäre es natürlich wenn er sich auf die FWIP von LAN2 verbinden würde und ich via redirect entscheide, wo es letztendlich hingeht.
Das er nicht die FWIP aus LAN1 verwendet hat den Grund, dass dieses LAN Segment beim Kunden nicht angesprochen werden darf, kann, was auch immer und da ist nicht drann zu rütteln.
Nun könnte man sagen, dann ändere ich eben LAN1 in ein Netz, welches für den Kunden akzeptabel ist, allerdings sind in diesem Netz bereits zig andere Netzanbindungen etc. was einen ungleich höheren Aufwand bedeuten würde und somit kommt man auf solche unsinnige Ideen.

Hoffe das war etwas verständlicher.

cheers,
plepps
 
Hoi,
was spricht gegen ein Netz für den "Kunden" mit VLAN Fixierung auf Port und MAC Ebene im Switch ?

Gruß Bummibär
 
hi

punkt 1 .

das 2.2.2.0 net muss der firewall beigebracht werden via routing.
ggf via rdom
im zweifel muss das lan1 eine ip aus diesem netz bekommen ( alias )

punkt 2

was dann erlaubt ist und was nicht mit pf regeln.

holger
 
Da ich mit einem ganz analogen Problem beschäftigt habe.

Redirekt auf einen Proxy Server im LAN, theoretisch könnte er in der DMZ an einem anderen Interface der FW hängen. Das habe ich noch nicht probiert. Wird zu anderen Regeln führen.

Hier die Regeln

pass in quick on $int_if proto tcp from <proxy> to any port {80, 443} rdr-to 10.xx.15.240 port 3127
pass out quick on $int_if proto tcp to 10.xx.15.240 port 3127 received-on $int_if nat-to $int_if

Der Proxyserver liegt im LAN der Clients. Jetzt bekomme ich für einige https Seiten eine Fehlermeldung.
 
Transparenter Proxy im gleichen Segment wie die Clients geht so:

Code: 
pass in quick on lan inet proto tcp from ! $proxy to port 80 rdr-to $proxy port 3128 tag TPROXY modulate state
pass out quick on lan tagged TPROXY nat-to (lan) modulate state

Dabei erscheinen alle Verbindungen allerdings, als kämen sie vom Router. Ideal wäre wirklich, Proxy im eigenen Segment zu haben.

Achso, dass https Probleme macht, wenn man es transparent an den Proxy leitet, ist klar. Woher soll der Proxy wissen, wo der Client hinwill?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben