Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Dec 2003 17:53:28 -0500
From:      "fbsd_user" <fbsd_user@a1poweruser.com>
To:        "freebsd-questions@FreeBSD. ORG" <freebsd-questions@FreeBSD.ORG>
Subject:   ipnat built in FTP proxy
Message-ID:  <MIEPLLIBMLEEABPDBIEGKEJAEPAA.fbsd_user@a1poweruser.com>

next in thread | raw e-mail | index | archive | help
I running FreeBSD 4.9 gateway with IPFILTER version 3.4.31 firewall.
Have ms/windows boxes on private lan behind firewall. Have IPNAT
running with FTP proxy enabled. From the ms/win lan users view point
every things is working fine for FTP client active and passive
access to public FTP sites. The problem is I am finding default log
messages for inbound port 21 requests in the log file. The out rule
which passes the port=21 packet is an keep state rule and it looks
like that when the FTP session conversation is completed the keep
state table is releasing some left over stuff.

In an effort to better understand what I was seeing I set up an test
configured as follows.

The contents on my ipnat.rules file
# Provide special NAT services for Active/Pasv FTP from LAN users.
map rl0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp

# Provide NAT services for LAN users.
# NAT my private LAN ip address to what every my dynamic ISP address
is.
map rl0 10.0.10.0/29 -> 0/32

# Provide NAT services for user ppp Dial in tun0 connections.
map tun0 10.0.0.0/29 -> 0/32


The content of my test filter rules ipf.rules file
pass out quick on rl0 proto udp from any to any port = 53 keep state
pass out quick on rl0 proto tcp from any to any port = 53 keep state
pass out quick on rl0 proto tcp from any to any port = 67 keep state

# Allow out LAN PC client FTP to public Internet
pass out quick on rl0 proto tcp from any to any port = 21 flags S
keep state

# Deny Everything else trying to get out.
block out log quick on rl0 all

# Allow traffic in from ISP's DHCP server.
pass in quick on rl0 proto udp from x.x.x.x to any port = 68 keep
state

# Block and log all remaining traffic coming into the firewall
block in log quick on rl0 all

pass in  quick on xl0 all
pass out quick on xl0 all

pass in  quick on lo0 all
pass out quick on lo0 all


To test I used the FTP client on one of the LAN ms/win boxes. I
first went to 8 public FTP sites in active mode. I checked my log
file during the navigation and downloading of data from each site as
I tested it and no log messages are posted. But when I tell the FTP
client to close the connection 5 of the 8 sites cause log message.
Later when I tried to go to the FTP sites that did not generate and
log messages, I did get the log messages any way. Log file included
later in the post.

I then saved the log file and created empty log file for next round
of tests.

In the second round of tests I went to the same 8 public FTP sites
in passive mode. Again I checked my log file during the navigation
and downloading of data from each site as I tested it and no log
messages are posted. But when I tell the FTP client to close the
connection 8 of the 8 sites cause log message.

In my book this is an bug.  Now I can put block in rule on port 21
to keep this junk messages from populating my log file. But that is
not the way one gets things fixed. Now if I am doing some thing
wrong please enlighten me.


Log messages for active test
test lan FTP client active mode with nat ftp proxy

trumpet news reader site 203.5.119.62  no log msgs

USROBOTICS Microsoft ftp server leaves the following when exiting
server
Dec  4 12:47:25 gateway ipmon[51]: 12:47:24.717411 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1291 PR tcp len 20 40 -AF IN
Dec  4 13:06:30 gateway ipmon[51]: 13:06:30.244686 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1330 PR tcp len 20 40 -AF IN

ftp1.ipswitch.com ws_ftp server leaves the following when exiting
server
Dec  4 13:13:12 gateway ipmon[51]: 13:13:11.508454 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1339 PR tcp len 20 40 -AF IN

Sunsite UNC pro_ftp server leaves the following  when exiting server
Dec  4 13:21:39 gateway ipmon[51]: 13:21:38.844747 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1348 PR tcp len 20 40 -AF IN
Dec  4 13:28:23 gateway ipmon[51]: 13:28:22.548626 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1355 PR tcp len 20 40 -AF IN

IBM site 207.25.253.40  no log msgs

AOL site 64.12.168.246  no log msgs

Cdrom.com Nc_ftp server leaves the following  when exiting server
Dec  4 13:45:44 gateway ipmon[51]: 13:45:43.750464 rl0 @0:2 b
207.250.14.6,21 -> 67.20.101.103,1393 PR tcp len 20 40 -AF IN

Qualcomm.com ftp server leaves the following  when exiting server
Dec  4 13:50:39 gateway ipmon[51]: 13:50:39.488162 2x rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1397 PR tcp len 20 70 -AP IN
Dec  4 13:51:19 gateway ipmon[51]: 13:51:18.324295 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1397 PR tcp len 20 40 -AF IN


Log messages for passive test
test lan FTP client passive mode with nat ftp proxy

trumput ftp server leaves the following when exiting server
Dec  4 14:04:35 gateway ipmon[51]: 14:04:35.839256 rl0 @0:2 b
203.5.119.62,21 -> 67.20.101.103,1416 PR tcp len 20 40 -A IN
Dec  4 14:04:36 gateway ipmon[51]: 14:04:36.362787 rl0 @0:2 b
203.5.119.62,21 -> 67.20.101.103,1416 PR tcp len 20 40 -A IN
Dec  4 14:04:37 gateway ipmon[51]: 14:04:37.561296 rl0 @0:2 b
203.5.119.62,21 -> 67.20.101.103,1416 PR tcp len 20 40 -A IN
Dec  4 14:04:39 gateway ipmon[51]: 14:04:39.963130 rl0 @0:2 b
203.5.119.62,21 -> 67.20.101.103,1416 PR tcp len 20 40 -A IN
Dec  4 14:04:45 gateway ipmon[51]: 14:04:44.761627 rl0 @0:2 b
203.5.119.62,21 -> 67.20.101.103,1416 PR tcp len 20 40 -A IN


USROBOTICS Microsoft ftp server leaves the following when exiting
server
Dec  4 14:10:46 gateway ipmon[51]: 14:10:45.756155 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -AF IN
Dec  4 14:10:46 gateway ipmon[51]: 14:10:45.820280 2x rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -A IN
Dec  4 14:10:46 gateway ipmon[51]: 14:10:46.622260 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -AF IN
Dec  4 14:10:47 gateway ipmon[51]: 14:10:47.270242 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -A IN
Dec  4 14:10:48 gateway ipmon[51]: 14:10:48.264196 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -AF IN
Dec  4 14:10:49 gateway ipmon[51]: 14:10:49.270574 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -A IN
Dec  4 14:10:51 gateway ipmon[51]: 14:10:51.545117 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -AF IN
Dec  4 14:10:53 gateway ipmon[51]: 14:10:53.270965 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -A IN
Dec  4 14:10:58 gateway ipmon[51]: 14:10:57.998796 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -AF IN
Dec  4 14:11:01 gateway ipmon[51]: 14:11:01.272128 rl0 @0:2 b
65.61.164.30,21 -> 67.20.101.103,1424 PR tcp len 20 40 -A IN

ws_ftp server leaves the following when exiting server
Dec  4 14:14:35 gateway ipmon[51]: 14:14:34.910130 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN
Dec  4 14:14:35 gateway ipmon[51]: 14:14:34.953900 2x rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -A IN
Dec  4 14:14:35 gateway ipmon[51]: 14:14:35.444562 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN
Dec  4 14:14:35 gateway ipmon[51]: 14:14:35.769868 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -A IN
Dec  4 14:14:36 gateway ipmon[51]: 14:14:36.538616 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN
Dec  4 14:14:37 gateway ipmon[51]: 14:14:36.969970 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -A IN
Dec  4 14:14:38 gateway ipmon[51]: 14:14:38.726478 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN
Dec  4 14:14:39 gateway ipmon[51]: 14:14:39.370286 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -A IN
Dec  4 14:14:43 gateway ipmon[51]: 14:14:43.102220 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN
Dec  4 14:14:44 gateway ipmon[51]: 14:14:44.169455 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -A IN
Dec  4 14:14:52 gateway ipmon[51]: 14:14:51.853859 rl0 @0:2 b
156.21.4.254,21 -> 67.20.101.103,1429 PR tcp len 20 40 -AF IN

SUNSITE pro_ftp server leaves the following  when exiting server
Dec  4 14:21:15 gateway ipmon[51]: 14:21:15.648639 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -AF IN
Dec  4 14:21:15 gateway ipmon[51]: 14:21:15.688032 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -A IN
Dec  4 14:21:17 gateway ipmon[51]: 14:21:17.305724 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -AF IN
Dec  4 14:21:17 gateway ipmon[51]: 14:21:17.596209 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -A IN
Dec  4 14:21:20 gateway ipmon[51]: 14:21:20.575037 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -AF IN
Dec  4 14:21:21 gateway ipmon[51]: 14:21:21.709693 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -A IN
Dec  4 14:21:27 gateway ipmon[51]: 14:21:27.027198 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -AF IN
Dec  4 14:21:30 gateway ipmon[51]: 14:21:29.769070 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -A IN
Dec  4 14:22:57 gateway ipmon[51]: 14:22:57.807362 rl0 @0:2 b
152.2.210.81,21 -> 67.20.101.103,1435 PR tcp len 20 40 -AF IN

IBM FTP  server leaves the following  when exiting server
Dec  4 14:24:18 gateway ipmon[51]: 14:24:18.150204 rl0 @0:2 b
207.25.253.40,21 -> 67.20.101.103,1440 PR tcp len 20 40 -A IN

AOL sunos FTP  server leaves the following  when exiting server
Dec  4 14:28:09 gateway ipmon[51]: 14:28:09.561241 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -A IN
Dec  4 14:28:10 gateway ipmon[51]: 14:28:10.072881 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:28:11 gateway ipmon[51]: 14:28:11.113132 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:28:14 gateway ipmon[51]: 14:28:13.193178 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:28:18 gateway ipmon[51]: 14:28:17.364044 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:28:26 gateway ipmon[51]: 14:28:25.715691 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN

Cdrom.con Nc_ftp server leaves the following  when exiting server
Dec  4 14:30:16 gateway ipmon[51]: 14:30:15.832374 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:31:14 gateway ipmon[51]: 14:31:14.057852 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:31:14 gateway ipmon[51]: 14:31:14.132484 2x rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -A IN
Dec  4 14:31:15 gateway ipmon[51]: 14:31:15.280079 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -A IN
Dec  4 14:31:15 gateway ipmon[51]: 14:31:15.552373 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:31:16 gateway ipmon[51]: 14:31:15.841406 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:31:17 gateway ipmon[51]: 14:31:16.890357 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -A IN
Dec  4 14:31:18 gateway ipmon[51]: 14:31:18.552508 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:31:20 gateway ipmon[51]: 14:31:20.080181 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -A IN
Dec  4 14:31:24 gateway ipmon[51]: 14:31:24.553305 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:31:26 gateway ipmon[51]: 14:31:26.481369 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -A IN
Dec  4 14:31:37 gateway ipmon[51]: 14:31:36.556126 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN

Qualcomm ftp server leaves the following  when exiting server
Dec  4 14:33:49 gateway ipmon[51]: 14:33:48.577109 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:34:04 gateway ipmon[51]: 14:34:04.260661 4x rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 43 -AP IN
Dec  4 14:34:16 gateway ipmon[51]: 14:34:15.869395 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:34:48 gateway ipmon[51]: 14:34:48.589607 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:35:16 gateway ipmon[51]: 14:35:15.878805 rl0 @0:2 b
205.188.212.118,21 -> 67.20.101.103,1445 PR tcp len 20 40 -AF IN
Dec  4 14:35:49 gateway ipmon[51]: 14:35:48.597047 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:36:49 gateway ipmon[51]: 14:36:48.608011 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:37:48 gateway ipmon[51]: 14:37:48.617000 rl0 @0:2 b
208.217.74.248,21 -> 67.20.101.103,1453 PR tcp len 20 40 -AF IN
Dec  4 14:38:36 gateway ipmon[51]: 14:38:36.125743 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 40 -A IN
Dec  4 14:38:37 gateway ipmon[51]: 14:38:36.894581 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 40 -AF IN
Dec  4 14:38:39 gateway ipmon[51]: 14:38:38.525179 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 40 -AF IN
Dec  4 14:38:42 gateway ipmon[51]: 14:38:41.796571 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 40 -AF IN
Dec  4 14:41:20 gateway ipmon[51]: 14:41:19.962586 rl0 @0:2 b
199.106.114.201,21 -> 67.20.101.103,1457 PR tcp len 20 40 -AF IN




In my book this is an bug.



The IPFILTER documentation says
The second type of client transfer, active, is a bit more
troublesome, but nonetheless a solved problem. Active transfers
cause the server to open up a second connection back to the client
for data to flow through. This is normally a problem when there's a
firewall in the middle, stopping outside connections from coming
back in. To solve this, ipfilter includes an ipnat proxy which
temporarily opens up a hole in the firewall just for the FTP server
to get back to the client. Even if you're not using ipnat to do nat,
the proxy is still effective. The following rules is the bare
minimum to add to the ipnat configuration file (ep0 should be the
interface name of the outbound network connection):
map ep0 0/0 -> 0/32 proxy port 21 ftp/tcp

I have this rule in my Nat rules file. I can see my filter rule
allow the FTP request to pass through, but I don't see packet return
back on high port number for data transmission. IT looks like the
NAT proxy is not opening hole for return data port.

The Nat rules I am using follow
# Provide special NAT services for Active FTP from LAN users.
map rl0 0/0 -> 0/32 proxy port 21 ftp/tcp

# Provide NAT services for LAN users.
# NAT my private LAN ip address to what every my dynamic ISP address
is.
map rl0 10.0.10.0/29 -> 0/32

# Provide NAT services for user ppp Dial in tun0 connections.
map tun0 10.0.0.0/29 -> 0/32

ipf filter rules
# Allow out client FTP for LAN PC FTP to public Internet
pass out quick on rl0 proto tcp from any to any port = 21 flags S
keep state

I can not figure out what is wrong.
Any help or pointers or examples would be appreciated.








I have privat

When  this ipnat rule is used to enable the built in FTP proxy
map rl0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp
it



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MIEPLLIBMLEEABPDBIEGKEJAEPAA.fbsd_user>