---

Når jeg connecter til min ProFTPd bag min IPTables firewall, kan jeg ikke få
den til at virke med PASV, uanset hvor i landet jeg befinder mig, og uanset
hvilken forbindelse/udbyder der bruges...

Jeg har forwardet både port 20 og 21 i firewallen, så hvad kan fejlen være
her??

Mvh. Morten Trab

ps. ALT udgående fra LAN er tilladt

---

In news:3f8843d4$0$9826$edfadb0f@dread14.news.tele.dk,
Morten Trab <mortenREMOVE@trab.dk> wrote:

> Når jeg connecter til min ProFTPd bag min IPTables firewall, kan jeg
> ikke få den til at virke med PASV, uanset hvor i landet jeg befinder
> mig, og uanset hvilken forbindelse/udbyder der bruges...
>
> Jeg har forwardet både port 20 og 21 i firewallen, så hvad kan fejlen
> være her??

For at FTP virker skal der så vidt jeg husker mindst være support for
connection tracking.

Se evt. om filen /proc/net/ip_conntrack findes.


> ps. ALT udgående fra LAN er tilladt

tsk tsk tsk, det er da ikke så sikkert :)

Det er "bedre" (ja, meget sværere og mere tidskrævende) at gå ud fra DROP på
alle chains, og herefter tillade det som virkelig skal tillades...

--
Michal

---

"Michal" <nonexistant@fakedomain.INVALID> skrev i en meddelelse
news:bm9h9f$7jg$2@sunsite.dk...

>
> For at FTP virker skal der så vidt jeg husker mindst være support for
> connection tracking.
>
> Se evt. om filen /proc/net/ip_conntrack findes.
>

Det ser ikke ud til at hverken den eller ip_conntrack_ftp findes på
systemet, men tilgengæld giver en modprobe ip_conntrack og ip_conntrack_ftp
heller ikke fejl...
Og aktiv (PORT) FTP virker fint...

>
> > ps. ALT udgående fra LAN er tilladt
>
> tsk tsk tsk, det er da ikke så sikkert :)
>
> Det er "bedre" (ja, meget sværere og mere tidskrævende) at gå ud fra DROP
på
> alle chains, og herefter tillade det som virkelig skal tillades...

Kan kun give dig ret...Men der er altså meget at skulle tilføje 65500 (ca.)
porte TCP/UDP for at tillade alt fra LAN og ud... :)


--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

In news:bm9idj$sih$1@svr-1.homedir.dk,
Morten Trab <mortenREMOVE@trab.dk> wrote:

>> For at FTP virker skal der så vidt jeg husker mindst være support for
>> connection tracking.
>>
>> Se evt. om filen /proc/net/ip_conntrack findes.
>>
>
> Det ser ikke ud til at hverken den eller ip_conntrack_ftp findes på
> systemet, men tilgengæld giver en modprobe ip_conntrack og
> ip_conntrack_ftp heller ikke fejl...
> Og aktiv (PORT) FTP virker fint...

Har du prøvet med en lsmod bagefter?

Du kan evt. også køre med statefull inspection.


>>> ps. ALT udgående fra LAN er tilladt
>>
>> tsk tsk tsk, det er da ikke så sikkert :)
>>
>> Det er "bedre" (ja, meget sværere og mere tidskrævende) at gå ud fra
>> DROP på alle chains, og herefter tillade det som virkelig skal
>> tillades...
>
> Kan kun give dig ret...Men der er altså meget at skulle tilføje 65500
> (ca.) porte TCP/UDP for at tillade alt fra LAN og ud... :)

65535 så vidt jeg husker ;)

Hvorfor tillade så mange porte fra LAN og ud?

F.eks. tillader du så også windows netværk portene ud? Dette muliggør f.eks.
spredning af visse viruser fra dit netværk og ud på nettet...

--
Michal

---

"Michal" <nonexistant@fakedomain.INVALID> skrev i en meddelelse
news:bm9k5r$ltd$1@sunsite.dk...

> Har du prøvet med en lsmod bagefter?
>
> Du kan evt. også køre med statefull inspection.
>

> 65535 så vidt jeg husker ;)
>
> Hvorfor tillade så mange porte fra LAN og ud?

Fordi det er et hjemme LAN, kun for denne lille husstand (2 voksne og 2
unger på under 3 år)

> F.eks. tillader du så også windows netværk portene ud? Dette muliggør
f.eks.
> spredning af visse viruser fra dit netværk og ud på nettet...

Jeg vælger at gøre det modsatte...ALLOW på alt udgående, og så droppe de
porte som skal droppes... :)

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

In news:bm9kkv$t8a$1@svr-1.homedir.dk,
Morten Trab <mortenREMOVE@trab.dk> wrote:

>> Har du prøvet med en lsmod bagefter?
>>
>> Du kan evt. også køre med statefull inspection.
>>
>
>> 65535 så vidt jeg husker ;)
>>
>> Hvorfor tillade så mange porte fra LAN og ud?
>
> Fordi det er et hjemme LAN, kun for denne lille husstand (2 voksne og
> 2 unger på under 3 år)

Det er så i orden :)


>> F.eks. tillader du så også windows netværk portene ud? Dette
>> muliggør f.eks. spredning af visse viruser fra dit netværk og ud på
>> nettet...
>
> Jeg vælger at gøre det modsatte...ALLOW på alt udgående, og så droppe
> de porte som skal droppes... :)

Selvom jeg kun laver net for 2 andre samt mig går jeg alligevel udfra en
DROP policy ;)

Måske fordi jeg mener det er for uoverskueligt at DROP'e alle de
forbindelser jeg ved er skadelige/uønskede... Men det er en smagssag :)

--
Michal

---

"Michal" <nonexistant@fakedomain.INVALID> writes:

>> ps. ALT udgående fra LAN er tilladt

>tsk tsk tsk, det er da ikke så sikkert :)

Hvis det er en enkelt server, der kun kører ftp-server, og som er
beskyttet af en flok bevæbnede vagter med ordre om at skyde først
og spørge bagefter, hvorfor mener du så, det er et problem?

(Hint: sikkerhed har intet med firewalls at gøre. Det har alt med
omstændigheder, risikovurdering, sikkerhedspolitik og procedurer
at gøre. En firewall er en meget lille - omend i visse tilfælde
ret vigtig - biting i den sammenhæng)

Mvh.
   Klaus.

---

In news:bm9kst$hj7$1@katie.ellegaard.dk,
Klaus Ellegaard <klausellegaard@msn.com> wrote:

>>> ps. ALT udgående fra LAN er tilladt
>
>> tsk tsk tsk, det er da ikke så sikkert :)
>
> Hvis det er en enkelt server, der kun kører ftp-server, og som er
> beskyttet af en flok bevæbnede vagter med ordre om at skyde først
> og spørge bagefter, hvorfor mener du så, det er et problem?
>
> (Hint: sikkerhed har intet med firewalls at gøre. Det har alt med
> omstændigheder, risikovurdering, sikkerhedspolitik og procedurer
> at gøre. En firewall er en meget lille - omend i visse tilfælde
> ret vigtig - biting i den sammenhæng)

Ja det ved jeg, men jeg mener så også at hvis hændelsen nu er ude og en
computer bliver "overtaget", så kan den i det mindste kun gøre begrænset
skade udaftil.

--
Michal

---

Den Sat, 11 Oct 2003 21:36:45 +0200 skrev Michal:
>In news:bm9kst$hj7$1@katie.ellegaard.dk,
>Klaus Ellegaard <klausellegaard@msn.com> wrote:
>
>>>> ps. ALT udgående fra LAN er tilladt
>>
>>> tsk tsk tsk, det er da ikke så sikkert :)
>>
>> Hvis det er en enkelt server, der kun kører ftp-server, og som er
>> beskyttet af en flok bevæbnede vagter med ordre om at skyde først
>> og spørge bagefter, hvorfor mener du så, det er et problem?
>>
>> (Hint: sikkerhed har intet med firewalls at gøre. Det har alt med
>> omstændigheder, risikovurdering, sikkerhedspolitik og procedurer
>> at gøre. En firewall er en meget lille - omend i visse tilfælde
>> ret vigtig - biting i den sammenhæng)
>
>Ja det ved jeg, men jeg mener så også at hvis hændelsen nu er ude og en
>computer bliver "overtaget", så kan den i det mindste kun gøre begrænset
>skade udaftil.

Hvis computeren bliver overtaget, hvad forhindrer så angriberen i
at skrive iptables -P OUTPUT ACCEPT?

Mvh
Kent
--
Journalist: En der har forstand på at skrive artikler, men typisk
ikke på det artiklerne handler om.

---

In news:bm9pvd$ecv$1@sunsite.dk,
Kent Friis <leeloo@phreaker.net> wrote:

>>>>> ps. ALT udgående fra LAN er tilladt
>>>
>>>> tsk tsk tsk, det er da ikke så sikkert :)
>>>
>>> Hvis det er en enkelt server, der kun kører ftp-server, og som er
>>> beskyttet af en flok bevæbnede vagter med ordre om at skyde først
>>> og spørge bagefter, hvorfor mener du så, det er et problem?
>>>
>>> (Hint: sikkerhed har intet med firewalls at gøre. Det har alt med
>>> omstændigheder, risikovurdering, sikkerhedspolitik og procedurer
>>> at gøre. En firewall er en meget lille - omend i visse tilfælde
>>> ret vigtig - biting i den sammenhæng)
>>
>> Ja det ved jeg, men jeg mener så også at hvis hændelsen nu er ude og
>> en computer bliver "overtaget", så kan den i det mindste kun gøre
>> begrænset skade udaftil.
>
> Hvis computeren bliver overtaget, hvad forhindrer så angriberen i
> at skrive iptables -P OUTPUT ACCEPT?

Så vidt jeg har forstået er ftpen bag firewallen, og ikke på samme maskine.

Desuden må man vel regne med at ftpen _hvis_ den kørte på firewallen ikke
kørte som root, vel?

--
Michal

---

"Michal" <nonexistant@fakedomain.INVALID> writes:

>Desuden må man vel regne med at ftpen _hvis_ den kørte på firewallen ikke
>kørte som root, vel?

Det kommer an på anvendelsen.

Den skal nødvendigvis køre som root, hvis den skal understøtte mere
end én "rigtig" bruger på systemet.

Mvh.
   Klaus.

---

In news:bm9tgd$ljq$1@katie.ellegaard.dk,
Klaus Ellegaard <klausellegaard@msn.com> wrote:

>> Desuden må man vel regne med at ftpen _hvis_ den kørte på firewallen
>> ikke kørte som root, vel?
>
> Det kommer an på anvendelsen.
>
> Den skal nødvendigvis køre som root, hvis den skal understøtte mere
> end én "rigtig" bruger på systemet.

Ja, og kunne binde til en priviligieret port... men jeg ved da at proftpd
benytter bl.a. linux' mulighed til at droppe rettigheder.

Og den kører vel forhåbentligt stadig ikke med normale brugere medmindre man
benytter SSL?

Jeg ville godt nok aldrig tillade en "rigtig" brugers password blive sendt i
plaintext. Men det er vel også blot en holdning.


--
Michal

---

"Michal" <nonexistant@fakedomain.INVALID> writes:

>Jeg ville godt nok aldrig tillade en "rigtig" brugers password blive sendt i
>plaintext. Men det er vel også blot en holdning.

Det sker hele tiden. Folk bruger jo heller ikke SSL, når de
henter mail med POP3 fra en netcafe.

Bevares, man kan hælde folks POP3-password i en separat database,
så det ikke er dét, de bruger, når de logger på maskinen. Det
samme kan man gøre med ftp-passwords.

Men forskellen er ens: folk kan ikke huske passwords, så de bruger
det samme password til deres mail, deres ftp og deres shell. Det
vil sige, at man har spildt en masse tid på at lave tre forskellige
login-systemer, der hver for sig gør præcis det samme, og som på
ingen måde øger sikkerheden. Tværtimod skaber den falsk tryghed,
fordi man TROR, man har omgået problemet, når man i virkeligheden
har gjort den samlede sikkerhed ringere (øget kompleksitet).

Igen: sikkerhed har meget, meget lidt med systemadministration
at gøre. Det er den mindste og letteste del af arbejdet.

Mvh.
   Klaus.

---

Den Sat, 11 Oct 2003 23:43:29 +0200 skrev Michal:
>In news:bm9pvd$ecv$1@sunsite.dk,
>Kent Friis <leeloo@phreaker.net> wrote:
>
>>>>>> ps. ALT udgående fra LAN er tilladt
>>>>
>>>>> tsk tsk tsk, det er da ikke så sikkert :)
>>>>
>>>> Hvis det er en enkelt server, der kun kører ftp-server, og som er
>>>> beskyttet af en flok bevæbnede vagter med ordre om at skyde først
>>>> og spørge bagefter, hvorfor mener du så, det er et problem?
>>>>
>>>> (Hint: sikkerhed har intet med firewalls at gøre. Det har alt med
>>>> omstændigheder, risikovurdering, sikkerhedspolitik og procedurer
>>>> at gøre. En firewall er en meget lille - omend i visse tilfælde
>>>> ret vigtig - biting i den sammenhæng)
>>>
>>> Ja det ved jeg, men jeg mener så også at hvis hændelsen nu er ude og
>>> en computer bliver "overtaget", så kan den i det mindste kun gøre
>>> begrænset skade udaftil.
>>
>> Hvis computeren bliver overtaget, hvad forhindrer så angriberen i
>> at skrive iptables -P OUTPUT ACCEPT?
>
>Så vidt jeg har forstået er ftpen bag firewallen, og ikke på samme maskine.

Det var ordet "udgående" der forvirrede...

>Desuden må man vel regne med at ftpen _hvis_ den kørte på firewallen ikke
>kørte som root, vel?

Det gør de fleste ftp-servere da.

Mvh
Kent
--
"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

>Når jeg connecter til min ProFTPd bag min IPTables firewall, kan jeg ikke få
>den til at virke med PASV, uanset hvor i landet jeg befinder mig, og uanset
>hvilken forbindelse/udbyder der bruges...

>Jeg har forwardet både port 20 og 21 i firewallen, så hvad kan fejlen være
>her??

PASV betyder, at serveren fortæller klienten, at den skal connecte
til en bestemt (men forskellig fra gang til gang) port over 1023.

For at undgå at skulle åbne for samtlige porte, kan man i blandt
andet ProFTPd specificere en række porte, som serveren kan bruge:

PassivePorts 12345 23456

Mvh.
   Klaus.

---

"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bm9kjd$hig$1@katie.ellegaard.dk...

> For at undgå at skulle åbne for samtlige porte, kan man i blandt
> andet ProFTPd specificere en række porte, som serveren kan bruge:
>
> PassivePorts 12345 23456

Jo tak, det virkede tildels at give den en range...MEN...
Måtte smide MasqueradeAddress med ind i conf til den også...Nu virker PASV
så ikke på vores LAN mere, og da vi af og til har besøg af nogle BØFFER hvad
IT angår, ville det jo være optimalt hvis både PASV og PORT virkede på begge
sider af routeren...

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

>Jo tak, det virkede tildels at give den en range...MEN...
>Måtte smide MasqueradeAddress med ind i conf til den også...Nu virker PASV
>så ikke på vores LAN mere, og da vi af og til har besøg af nogle BØFFER hvad
>IT angår, ville det jo være optimalt hvis både PASV og PORT virkede på begge
>sider af routeren...

Hvis det ser således ud...

==========
== ==
= Internet =
== ==
========== FTP-
| klient server
------------ | |
|NAT-router|-------+----------+-----|
------------ LAN

....kan jeg ikke se nogen grund til, at masquerading er vigtigt
for at få det til at køre. Her skulle NAT'en i routeren (med en
passende mapping indad) gerne virke.

Hvis routeren derimod er ftp-serveren selv, burde det virke fra
begge sider, hvis du blot ftp'er til ydersiden både udefra og
indefra. Med passende tilretninger af filtrene, så der tillades
lokalnet-adresser til ydersidens IP (ikke ydersiden som helhed).

Mvh.
   Klaus.

---

"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bm9m5p$hs5$1@katie.ellegaard.dk...

> Hvis det ser således ud...
>
> ==========
> == ==
> = Internet =
> == ==
> ========== FTP-
> | klient server
> ------------ | |
> |NAT-router|-------+----------+-----|
> ------------ LAN

Lidt fortegnet, men ja...

> ...kan jeg ikke se nogen grund til, at masquerading er vigtigt
> for at få det til at køre. Her skulle NAT'en i routeren (med en
> passende mapping indad) gerne virke.

Ville jeg jo også mene...
Det her er delen af firewall'en der har med FTP at gøre...

# FTP traffik
$IPTABLES -A INPUT -p tcp -d 192.168.2.10 --dport 20:21 -i $EXTERNALIF -j
ACCEPT$IPTABLES -A PREROUTING -t nat -p tcp -i $EXTERNALIF --dport 20:21 -j
DNAT --to-destination 192.168.2.10
$IPTABLES -A FORWARD -p tcp -d 192.168.2.10 --dport 20:21 -i $EXTERNALIF -j
ACCEPT

$IPTABLES -A INPUT -p tcp -d 192.168.2.10 --dport 12000:12500 -i
$EXTERNALIF -j ACCEPT
$IPTABLES -A PREROUTING -t nat -p tcp -i $EXTERNALIF --dport 12000:12500 -j
DNAT --to-destination 192.168.2.10
$IPTABLES -A FORWARD -p tcp -d 192.168.2.10 --dport 12000:12500 -i
$EXTERNALIF -j ACCEPT

> Hvis routeren derimod er ftp-serveren selv, burde det virke fra
> begge sider, hvis du blot ftp'er til ydersiden både udefra og
> indefra. Med passende tilretninger af filtrene, så der tillades
> lokalnet-adresser til ydersidens IP (ikke ydersiden som helhed).

Det er en selvstændig server...

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

>Ville jeg jo også mene...
>Det her er delen af firewall'en der har med FTP at gøre...

Jeg er ikke særlig klog på iptables, men der er vel ikke noget
i vejen for, at du på de lokale maskiner ftp'er til 192.168.2.10?

Jeg kan godt se, at det næppe vil virke at ftp'e til den eksterne
adresse, for tilladelsen kommer fra trafik via EXTERNALIF. Det
sker jo ikke for trafik indefra.

Mvh.
   Klaus.

---

"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bma0rj$mca$1@katie.ellegaard.dk...

> Jeg er ikke særlig klog på iptables, men der er vel ikke noget
> i vejen for, at du på de lokale maskiner ftp'er til 192.168.2.10?

Det er også det jeg gør, men eftersom den kører med MasqueradeAddress, så
svarer den tilbage med min ext.IP ved PASV på LAN...

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

>> Jeg er ikke særlig klog på iptables, men der er vel ikke noget
>> i vejen for, at du på de lokale maskiner ftp'er til 192.168.2.10?

>Det er også det jeg gør, men eftersom den kører med MasqueradeAddress, så
>svarer den tilbage med min ext.IP ved PASV på LAN...

Din ftp-server masquerader vel ikke? Det skulle der ikke være
nogen grund til - det er NAT-boksens opgave.

Mvh.
   Klaus.

---

"Klaus Ellegaard" <klausellegaard@msn.com> skrev i en meddelelse
news:bmav17$1b4$1@katie.ellegaard.dk...
> "Morten Trab" <mortenREMOVE@trab.dk> writes:

> Din ftp-server masquerader vel ikke? Det skulle der ikke være
> nogen grund til - det er NAT-boksens opgave.

Som jeg skrev tidligere bliver jeg nødt til at bruge MasqueradeAddress på
ProFTPd'en, for at PASV vil virke udefra...Nu virker PASV så bare ikke
indefra...

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

>> Din ftp-server masquerader vel ikke? Det skulle der ikke være
>> nogen grund til - det er NAT-boksens opgave.

>Som jeg skrev tidligere bliver jeg nødt til at bruge MasqueradeAddress på
>ProFTPd'en, for at PASV vil virke udefra...Nu virker PASV så bare ikke
>indefra...

Det næste er så at finde ud af, hvorfor det er nødvendigt (for
det bør det ikke være).

Der skulle gerne ske det, at NAT'en ved ftp ændrer $EXTERNALIP
til at være 192.168.2.10 og NAT'er klienten igennem. Når ftp-
serveren svarer tilbage til klienten, skal NAT'en på samme måde
ændre 192.168.2.10 til $EXTERNALIP. For ftp-serveren skal det
derfor se ud som om den sagtens kan snakke med sin 192.168.2.10-
adresse til hele verden.

Dermed opnår du også, at du kan snakke med 192.168.2.10 på dit
LAN.

Meneh... nu er jeg Solaris/HP-UX/Tru64-gut, så at give løsningen
på det i Linux, bliver svært.

Mvh.
   Klaus.

---

Klaus Ellegaard wrote:
> "Morten Trab" <mortenREMOVE@trab.dk> writes:
>
>
>>>Din ftp-server masquerader vel ikke? Det skulle der ikke være
>>>nogen grund til - det er NAT-boksens opgave.
>>
>
>>Som jeg skrev tidligere bliver jeg nødt til at bruge MasqueradeAddress på
>>ProFTPd'en, for at PASV vil virke udefra...Nu virker PASV så bare ikke
>>indefra...
>
>
> Det næste er så at finde ud af, hvorfor det er nødvendigt (for
> det bør det ikke være).
>
> Der skulle gerne ske det, at NAT'en ved ftp ændrer $EXTERNALIP
> til at være 192.168.2.10 og NAT'er klienten igennem. Når ftp-
> serveren svarer tilbage til klienten, skal NAT'en på samme måde
> ændre 192.168.2.10 til $EXTERNALIP. For ftp-serveren skal det
> derfor se ud som om den sagtens kan snakke med sin 192.168.2.10-
> adresse til hele verden.
>
> Dermed opnår du også, at du kan snakke med 192.168.2.10 på dit
> LAN.
>
> Meneh... nu er jeg Solaris/HP-UX/Tru64-gut, så at give løsningen
> på det i Linux, bliver svært.
>
> Mvh.
>    Klaus.

Jeg har sat en proftp server op hos mig, og har ikke configureret noget
med masqurading, og den er fint tilgængelig indefra og udefra (LAN/WAN)
gennem en hardwarerouter.

m.v.h. Mikael

---

"Mikael Hansen" <mikael.hansen@DELETE.post.cybercity.dk> skrev i en
meddelelse news:3F896CEF.4000405@DELETE.post.cybercity.dk...


> Jeg har sat en proftp server op hos mig, og har ikke configureret noget
> med masqurading, og den er fint tilgængelig indefra og udefra (LAN/WAN)
> gennem en hardwarerouter.

Ville det sikkert også gøre her, men som antyder i tidligere tråd er det en
IPtables firewall, der ligger på en anden Linux box...

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk

---

"Morten Trab" <mortenREMOVE@trab.dk> writes:

> Når jeg connecter til min ProFTPd bag min IPTables firewall, kan jeg ikke få
> den til at virke med PASV, uanset hvor i landet jeg befinder mig, og uanset
> hvilken forbindelse/udbyder der bruges...
>
> Jeg har forwardet både port 20 og 21 i firewallen, så hvad kan fejlen være
> her??

Hvis du indlæser ip_conntrack_ftp og ip_nat_ftp og tillader alle
forbindelser, der er state ESTABLISHED og RELATED, samt tillader
indgående port 21 (20 er så ikke nødvendig) vil både aktiv og
passiv ftp fungere problemfrit - det har jeg gode erfaringer med.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
A computer without Windows, is like a fish without a bicycle.
----------------------------------[ moffe at amagerkollegiet dot dk ] --

---

"Rasmus Bøg Hansen" <spam@amagerkollegiet.dk> skrev i en meddelelse
news:87zng63zn0.fsf@grignard.amagerkollegiet.dk...

> Hvis du indlæser ip_conntrack_ftp og ip_nat_ftp og tillader alle
> forbindelser, der er state ESTABLISHED og RELATED, samt tillader
> indgående port 21 (20 er så ikke nødvendig) vil både aktiv og
> passiv ftp fungere problemfrit - det har jeg gode erfaringer med.

Den manglede åbenbart ip_nat_ftp, for da jeg probede den virkede det fint :)

--
Mvh. Morten Trab
--
Svar venligst kun i NG, med mindre det er MEGET vigtigt.
Ved mail, slet REMOVE i min adresse.

Web: http://www.blackchart.dk