I'm converting a pf ruleset to work with the new nat/rdr changes in 4.6
-current and I came across an issue that seems like a problem in the way
"tagged" rules are handled. It's breaking ftp-proxy with tagging when I
try to apply additional rules to the tagged packets. The result is that I
can login to an FTP server but the inbound data connection seems to get
lost--I don't get a passed or blocked packet in the pf log and the data
connection fails to establish.
If I remove my "tagged <TAGNAME>" rules, then everything works fine but
then I can't use the tags to do further processing of these packets.
Here's how to reproduce this using the 4.6 -current snapshot from November
08 2009:
(1) startup ftp-proxy with tagging enabled: "ftp-proxy -v -T FTPPROXY"
(2) enable pf using the following ruleset:
ext_if="bge0"
ext_addr="192.168.99.234"
ext_net="192.168.99.0/24"
int_if="bge1"
int_addr="10.0.1.30"
int_net="10.0.1.0/24"
block in log all
block out log all
anchor "ftp-proxy/*"
pass in log quick tagged FTPPROXY
pass out log quick tagged FTPPROXY
pass in log quick on $int_if proto tcp \
from $int_net to any port 21 rdr-to 127.0.0.1 port 8021
pass out log quick on $ext_if proto tcp from $ext_net to any modulate state
(3) connect to an external FTP server (192.168.99.237) from internal
client (10.0.1.21).
Initial login works fine, but when I try a "dir", the client shows:
ftp> dir
200 PORT command successful.
425 Can't build data connection: Connection refused.
My pf log shows only one rule hit--a pass in rule on the external
interface. It's matching rule "pass in log quick tagged FTPPROXY". But I
don't get any other pass or block, so the packet never seems to go out the
internal interface.
Nov 12 13:35:05 inttest01 pf: Nov 12 13:35:04.613474 rule 3/(match) pass
in on bge0: 192.168.99.237.20 > 192.168.99.234.54237: S
603831874:603831874(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK>
(DF)
Here are the anchor rules generated by ftp-proxy:
# pfctl -sA -v
ftp-proxy
ftp-proxy/16553.9
# pfctl -v -a ftp-proxy/16553.9 -sr
pass in log inet proto tcp from 192.168.99.237 to 192.168.99.234 port =
54237 flags S/SA keep state (max 1) tag FTPPROXY rtable 0 rdr-to 10.0.1.21
port 47008
[ Evaluations: 1 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 71 pid 16553 State Creations: 0 ]
pass out log inet proto tcp from 192.168.99.237 to 10.0.1.21 port = 47008
flags S/SA keep state (max 1) tag FTPPROXY rtable 0 nat-to 192.168.99.237
[ Evaluations: 1 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 71 pid 16553 State Creations: 0 ]
If I comment out the following two lines in pf.conf and reload the
ruleset, the data connection is established successfully.
#pass in log quick tagged FTPPROXY
#pass out log quick tagged FTPPROXY
Without these "tagged" rules, the pf log shows the pass in and pass out
rules from ftp-proxy:
Nov 12 13:39:12 inttest01 pf: Nov 12 13:39:11.652228 rule
2.16553.10.0/(match) pass in on bge0: 192.168.99.237.20 >
192.168.99.234.58347: S 664347264:664347264(0) win 49640 <mss
1460,nop,wscale 0,nop,nop,sackOK> (DF)
Nov 12 13:39:12 inttest01 pf: Nov 12 13:39:11.652252 rule
2.16553.10.1/(match) pass out on bge1: 192.168.99.237.20 >
10.0.1.21.49096: S 664347264:664347264(0) win 49640 <mss 1460,nop,wscale
0,nop,nop,sackOK> (DF)
Am I missing something? I don't see any obvious errors in my pf.conf and
I don't understand why I'm not getting either a "pass out on bge1:" or a
"block out on bge1:" log entry on the internal interface for the data
connection when using the tagged option. Every line in pf.conf has
logging enabled. It seems like pf is losing this packet entirely.
Please let me know if there is additional data I can collect to help track
down this problem.
Thanks!
Bryan
