PF+NAT mit RDR und ftp-proxy, aktiver FTP Problem

[asg]

Moin,

Kunde hat ein "tolles" Programm mit dem man auf seinen Server via aktiven FTP connectet.

Client -> GW -> NAT-Server -> FW -> Internet -> Kunde

Verbindung zu "kunde" wird hergestellt aber FTP-DATA geht nicht.
Also beim "NAT-Server" Regeln aufgenommen:

rdr on $int_if proto tcp from 10.4.1.26 to any port 21 -> 127.0.0.1 port 8021
pass in on $ext_if inet proto tcp from port 20 to $ext_if user proxy flags S/SA keep state

in /etc/inetd.conf:

127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -n

Dies alles laut http://www.openbsd.org/faq/pf/ftp.html

Soweit so gut. Die Verbindung zum aktiven FTP von "Kunde" funktioniert von "Client" aus.

Nun kommt das Problem.
Kunden können auf unseren FTP Server noch zugreifen, ABER, von intern kommt man nicht mehr auf unseren FTP-Server, der auf dem "NAT-Server" läuft, nicht mehr drauf.
deaktiviere ich die obigen Regeln geht dies wieder, dafür kommt kann der Client aber keine FTP-Data connection mehr zu "Kunde" aufbauen. Scheisse am dampfen.

Hier noch die ganze /etc/pf.conf vom "NAT-Server":

# Variablen
ext_if = "xl0"
int_if = "xl1"
clu_if = "xl2"

int_ip = "212.202.224.248/29"
blu_ip = "192.168.233.254"
ext_ip = "212.202.xxx.aae"
sfwd_ip = "{ 212.202.xxx.aaa, 212.202.xxx.aab, 212.202.xxx.aac, 212.202.xxx.aad, 212.202.xxx.aae }"
spar_server = "213.150.2.xxx"
spar_client = "{ 10.4.1.24, 10.4.1.26, 10.4.1.50, 10.4.1.235 }"
spar_port = "3048"
ausnahme = "{ 192.168.155.56, 192.168.233.4 }"

set loginterface $ext_if
set loginterface $int_if

# asg
# packet normalizer gegen hackversuche durch ueberlange pakete
scrub in all

# NAT
nat on $ext_if from $int_if:network to $ausnahme -> $blu_ip
nat on $ext_if from 10.3.1.0/24 to $ausnahme -> $blu_ip
nat on $ext_if from 10.2.1.0/24 to $ausnahme -> $blu_ip
nat on $ext_if from 10.1.1.0/24 to $ausnahme -> $blu_ip

nat on $ext_if from $int_if:network to ! (192.168.155.56) -> $ext_ip
nat on $ext_if from $int_if:network to ! (192.168.233.4) -> $ext_ip
nat on $ext_if from 10.3.1.0/24 to ! (192.168.155.56) -> $ext_ip
nat on $ext_if from 10.3.1.0/24 to ! (192.168.233.4) -> $ext_ip
nat on $ext_if from 10.2.1.0/24 to ! (192.168.155.56) -> $ext_ip
nat on $ext_if from 10.2.1.0/24 to ! (192.168.233.4) -> $ext_ip
nat on $ext_if from 10.1.1.0/24 to ! (192.168.155.56) -> $ext_ip
nat on $ext_if from 10.1.1.0/24 to ! (192.168.233.4) -> $ext_ip

# Redirect Spar
rdr on $ext_if proto udp from $spar_server to any port $spar_port -> $spar_client port $spar_port
rdr on $int_if proto udp from $spar_client to any port $spar_port -> $spar_server port $spar_port

rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

block log all
pass out log from any to any keep state
pass in log from any to any keep state

pass in on $ext_if inet proto tcp from port 20 to $ext_if user proxy flags S/SA keep state

So, wie nun die dusselige Regel für den aktiven FTP, FTP-Proxy, schreiben das wir von innen noch auf den FTP-Server kommen ("NAT-Server") und das der "Client" (10.4.1.26) auch eine ftp data connection zum "Kunde" aufbauen kann?

 

[asg]

Keiner ne Idee?
Was noch seltsamer ist, gestern ging es noch, also zumindest der Zugriff auf "Kunde", intern ging ftp auf den internen FTP nicht.
Und jetzt? Ich habe an den Rules nichts geändert, ok, nur der eine "NAT-Server" hat die rules aktiviert (aber über den geht auch der traffic), und mit aktivierten rules kann ich jetzt keine ftp-data verbindung mehr zum kunden aufbauen.
Ach, gar kein ftp geht mehr raus

 

[juedan]

Hallo asg,

da ich leider mit PF noch nicht vertraut bin, kann ich Dir nur folgenden Tip geben:
einfdach mal tcpdump mitlaufen lassen un d die Ausgabe auf den Drucker umleiten, der vorzugsweise am Parallel-Port angeschlossen ist (sonst mußt Du die Daten auch noch herausklabüsern).

Viele Grüße und viel Erfolg

Jürgen

 

[socke]

Hallo asg,

mir fallen da 2 dinge ein die als Loesung in betracht kommen

deine ftp-proxy Regel hatte sicher vorher das flag '-n' nicht.
Erstelle einen 2. Eintrag, erhoehe den Port und ergaenze das Regelwerk (somit hast du z.B. als standart PASSIV und fuer eben diesen Kunden AKTIV FTP)

127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -n
127.0.0.1:8121 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy

Erstellen einer Liste aller Problematischen FTP's

aktive_ftp_servers= "{XXX.XXX.XXX.XXX}"

die Regel

rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

anpassen zu:

rdr on $int_if proto tcp from any to ! $aktive_ftp_servers port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to $aktive_ftp_servers port 21 -> 127.0.0.1 port 8021

-> das target "any" genauer angeben,

kann es hier nicht nachvollziehen, da meine Topo anders aussieht

 

[asg]

@juedan
Vor lauter tcpdumps wird mir schon ganz anders, ich muss irgendwie blind sein.

@socke
Habe das so versucht, leider gleiches Spiel.
Wenn ich

rdr on $int_if proto tcp from any to ! (194.151.aaa.xx) port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to ! (193.172.bb.yy) port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to 194.151.aaa.xx port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to 193.172.bb.yy port 21 -> 127.0.0.1 port 8021

drin habe dann geht kein FTP mehr vom Client nach nirgendwo.

tcpdump sagt dazu auf den Server auf dem NAT und RDR rennt:

000000 rule 20/0(match): pass in on xl1: IP 10.4.1.99.52325 > 127.0.0.1.8121: S 3111577879:3111577879(0) win 65535 <mss 1460,nop,nop,sackOK,[|tcp]>

Das bei dem Versuch ftp.freebsd.org oder anderen FTP-Server zu erreichen.

Bei dem versuch einen der angegeben aktiven FTP-Server zu erreichen:

000000 rule 20/0(match): pass in on xl1: IP 10.4.1.99.49295 > 127.0.0.1.8021: S 3578225143:3578225143(0) win 65535 <mss 1460,nop,nop,sackOK,[|tcp]>

Ok, verdammt.
Habe ich die obigen Regeln bezgl. rdr auf den proxy aktiviert, dann sehe ich bei einem tcpdump auf der FW, also der Rechner ganz vorne über den der NAT-Server geht, rein gar nichts. Null. Leer.
Verdammt.
Nur, warum? Ich meine dann ist es kein Wunder wenn weder das eine noch das andere (ftp aktiv oder passiv) von einem client aus funktioniert.

 

[juedan]

Hallo asg,

blöde Fragen:
(1) Wie wird inetd gestartet?
(2) wie sieht denn /etc/hosts.allow aus?
(auf dem Rechner, auf dem ftp-proxy läuft)
Laß den ftp-proxy doch auch mal im debug-Modus laufen.

Viele Grüße

Jürgen

 

[asg]

@juedan
inetd via /etc/rc.conf:
inetd_enable="YES"
Der rennt ja auch, so zumindest die Prozessliste.

/etc/hosts.allow
Ist unangetastet bisher auf der Maschine, keine Änderungen der Defaultwerte (dort sollten auch keine Änderungen nötig sein).

ftp-proxy wird nun via inetd.conf mit "-D3" gestartet.
Problem dabei, ich sehe keine Einträge in der /var/log/debug.log was mich etwas missmutig stimmt. Auch ein anderes log zeigt mir nicht mehr an...

Ein sockstat -l4 oder auch netstat zeigt gerade keinen ftp-proxy auf einem der angebenen Ports llauschen....

Ein tcpdump -n -e -ttt -i pflog0

2. 407207 rule 2/0(match): pass in on xl1: IP 10.4.1.99.50926 > 127.0.0.1.8121: S 3623169352:3623169352(0) win 65535 <mss 1460,nop,nop,sackOK,[|tcp]>

Ein tcpdump -i xl1 port 21

16:03:52.174714 IP 10.4.1.99.58587 > ftp.beastie.tdk.net.ftp: S 3471511073:3471511073(0) win 65535 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 35347920 0>

Beides mal mit den aktivierten rdr Regeln...

 

[juedan]

Hallo asg,

wenn ich mir Deine Regeln so ansehe mit meinem bescheidenen pf-Kenntnissen und mir diverse andere pf-Konfigurationen ansehe, fällt mir auf, dass das loopback-Interface nicht erwähnt wird.
Kann es sein, dass pf das automatisch blockt, wenn keine Angaben gemacht werden?

 # Loopback Interface
pass in quick on lo0 all
pass out quick on lo0 all

Meines Erachtens ist das loopback blockiert. Aber ich kann mich irren, da ich mich noch nicht so tief in pf eingarbeitet habe.

Viele Grüße

Jürgen

 

[socke]

Hallo asg,

kann mich juedan anschliessen.

Frage:
hast du mal versucht die reihenfolge zu ändern?
Meines erachten wird sonst der !(...) Part durch die nächste Regel überschrieben.

von:

rdr on $int_if proto tcp from any to ! (194.151.aaa.xx) port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to ! (193.172.bb.yy) port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to 194.151.aaa.xx port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to 193.172.bb.yy port 21 -> 127.0.0.1 port 8021

nach

rdr on $int_if proto tcp from any to 194.151.aaa.xx port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to 193.172.bb.yy port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to ! (194.151.aaa.xx) port 21 -> 127.0.0.1 port 8121
rdr on $int_if proto tcp from any to ! (193.172.bb.yy) port 21 -> 127.0.0.1 port 8121

Um die Pakete zu verfolgen die genatted werden ist es evtl. hilfreich ein "tag" auf die Pakete zu setzen (so lassen sie sich besser nachverfolgen).

PS:
Ich schaue mir das Regelwerk meist mit "pfctl -sa | tee ~/pfrule.log" nochmals an, somit sehe ich was pf wirklich daraus macht.

olli

 

[asg]

@juedan
Ja, lo0 hatte ich auch schon drin. Da es nichts brachte habe ich es seitdem nicht mehr erwähnt...
Er versucht auf den Server zuzugreifen, die Pakete kommen aber schon bei der FW nie an. Daher muss es wohl am ftp-proxy liegen. Sobald ich die Regeln, die den Proxy betreffen, entferne, geht der FTP-Zugriff (aber eben nur auf passives FTP - bzw. eben nicht von diesem einen Client auf den FTP unseres Kunden).

@socke
Ich hab die Reihenfolge schon geändert das ich nicht merh weiss wo hinten und vorne ist.
Ein tcpdump auf pflog0 zeigt mir nur an das es bist 127.0.0.1 $port-ftpproxy geht, auf der FW sehe ich nix, null, gar nix. Also scheint das Problem beim Proxy zu liegen (springt der überhaupt an? ich sehe nichts im debug log - obwohl -D3 und ich sehe auch nichts bei netstat).

 

[maus]

Nun kommt das Problem.
Kunden können auf unseren FTP Server noch zugreifen, ABER, von intern kommt man nicht mehr auf unseren FTP-Server, der auf dem "NAT-Server" läuft, nicht mehr drauf.

m0n0: webGUI Configuration

It is not possible to access NATed services using the WAN IP address
from within LAN (or an optional network).

Ich würde Jacek Artymiak fragen, der hat schließlich ein 320-seitiges Buch zu PF geschrieben.
www.devguide.net
openbsdpf-ed-02@devguide.net

 

[asg]

@maus
Ahja, ok. Werd ich machen.
Zuvor muss ich aber noch das andere Problem lösen...

 

[AceX5]

Vielleicht solltest du es mal mit einem anderen FTP Proxy probieren. Habe auf der pf-Mailinglist etwas von pftpx gelesen. Vielleicht bekommt man den unter FreeBSD zum laufen...

 

[juedan]

Hallo asg,

starte den ftp-proxy doch mal direkt, ohne inetd:
/usr/libexec/ftp-proxy -D3

 

[asg]

@AceX5
Ja, das wäre auch ein Weg, einen anderen FTP-Proxy zu nehmen. Mal sehen was sich in den Ports tummelt. pftpx soweit ich weiss (noch) nicht.

@juedan
Das Teil rennt nur via inetd wenn ich das richtig sehe.

 

[asg]

So, scheint nun zu gehen:

# Weiterleitung auf den FTP-Proxy
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

# FTP fuer all
pass log quick proto tcp from any to 127.0.0.1 port 8021 keep state
# block in log quick proto tcp from !<protected_lans> to 127.0.0.1 port 8021
pass out log quick proto tcp from $sfwd_ip to any port > 1023 keep state

# Erlaube dem entfernten FTP-Server (auf data port 20) auf unseren Proxy zu antworten
# aktives FTP zum Internet
pass in log quick on $ext_if proto tcp from any port 20 to $ext_if port 55000 >< 57000 flags S/SA keep state
pass out log quick on $ext_if proto tcp from $ext_if to any port {20,21} flags S/AUPRFS modulate state
pass out log quick on $ext_if proto tcp from $ext_if port 55000 >< 57000 to any flags S/SAFR keep state
# Erlaube alles auf dem loopback Interface
# wichtig fuer ftp-proxy und aktives FTP
pass quick on lo0 all

Nach einem killall des inetd (ich trau mittlerweile keinem HUP mehr - reiner Aberglaube) und einem neustart, sowie einem laden der rules, scheint es nun zu gehen.
Zumindest kann ich mit den geladenen rules auf interne ftp server, komme auch auf extern. Ob das mit dem aktiven FTP 100% klappt werde ich morgen sehen wenn ich wieder diese dusselige Bankensoftware vor mir habe.

Danke an alle mitdenkenden.