On Mon, Aug 29, 2005 at 05:09:55PM +0300, Chris Dionissopoulos wrote:
> >>On Mon, Aug 29, 2005 at 02:21:37PM +0100, Patrick Welche wrote:
> >>> >From ipnat -l, I have
> >>> 
> >>> map ex1 192.168.0.0/24 -> x.y.z.1/32 proxy port ftp ftp/tcp
> >>> map ex1 192.168.0.0/24 -> x.y.z.1/32 portmap tcp/udp 10000:65000
> >>> map ex1 192.168.0.0/24 -> x.y.z.1/32
> >>> bimap ex1 192.168.0.180/32 -> x.y.z.180/32 proxy port ftp ftp/tcp
> >>> 
> >>> yet, when I ssh out from 192.168.200.180, finger prlw1 tells me I am
> >>> connecting from x.y.z.1 rather than x.y.z.180.
> >>> 
> >>> According to the rules /32 should take precedence over /24, so what is
> >>> wrong?

> "Bimap" rule applies for IP-to-IP translations and not for particular 
> protocol/port, although
> ipnat config file syntax permits.

Ah! So though my bimap line obeys the BNF it is incorrect!

Thank you.

Now for everybody's favorite: active/passive ftp client connecting out.

With

map ex1 192.168.0.180/32 -> x.y.z.180/32 proxy port ftp ftp/tcp
bimap ex1 192.168.0.180/32 -> x.y.z.180/32
map ex1 192.168.0.0/24 -> x.y.z.1/32 proxy port ftp ftp/tcp
map ex1 192.168.0.0/24 -> x.y.z.1/32 portmap tcp/udp 10000:65000
map ex1 192.168.0.0/24 -> x.y.z.1/32

ftp -p ftp.microsoft.com
ftp -A ftp.microsoft.com

both work with a NetBSD ftp client, however when I try a debian client
ftp -p hangs building the data connection:

230 Anonymous user logged in.
Remote system type is Windows_NT.
ftp> dir
227 Entering Passive Mode (207,46,133,140,135,210)
ftp: connect: Connection timed out

by contrast NetBSD ftp -p does:

230 Anonymous user logged in.
Remote system type is Windows_NT.
ftp> dir
500 'EPSV': command not understood
227 Entering Passive Mode (207,46,133,140,51,226)
125 Data connection already open; Transfer starting.
dr-xr-xr-x   1 owner    group               0 Nov 25  2002 bussys
...


Naturally once the NetBSD ftp client behaved so admirably, I thought "great
the ipf firewall works", but unfortunately we have to worry about the
"antivirus software gets its updates via ftp" bad ftp client scenario.
debian's ftp client might be more respectable than the antivirus updater..

So, should the above rules work for all run-of-the-mill ftp clients?

Cheers,

Patrick