Claudio Jeker wrote:
On Fri, Nov 13, 2009 at 05:44:41PM +0100, Henning Brauer wrote:
* Bryan S. Leaman <[email protected]> [2009-11-13 17:37]:
Henning Brauer wrote:
* Bryan S. Leaman <[email protected]> [2009-11-13 01:12]:
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 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 ]
hrm. ftp-proxy would need to use match instead of pass in that case.
Can you please elaborate on this? I know the ftp-proxy code already
supresses the "quick" keyword when using the tagging option, so
wouldn't that be sufficient for pf to continue processing the packet
with the additional "tagged FTPPROXY" rule? In previous releases I
was able to use "pass out" and then later a "pass out quick" to
match what was passed by the previous rule. Is this handled
differently with the new nat/rdr changes in -current or am I
misunderstanding something? It's working for the first ftp-proxy
rule (pass in), but not the second (pass out). Thanks!
nat-to and rdr-to on pass rules are only applied if it is the last
matching rule. for match rules they're always applied.
Maybe something like this. The result are that you need to have a
"pass tagged FTPTAG" rule after the anchor (or one rule per direction) or
the traffic may be blocked.
Your patch works fine. Before I saw your response, I also tried the
following which works as well. I just added to the existing condition
statement that was put in for suppressing "quick". As you pointed out,
when ftp-proxy uses "match" then there must be a pair of "pass tagged"
rules or else the traffic is blocked. But at least it shows up in my
log as blocked, unlike what I saw yesterday in which the packet seemed
to disappear.
# diff -u filter.c.1.9 filter.c
--- filter.c.1.9 Mon Nov 9 18:43:18 2009
+++ filter.c Fri Nov 13 13:21:24 2009
@@ -247,6 +247,7 @@
strlcpy(pfr.rule.qname, qname, sizeof pfr.rule.qname);
if (tagname != NULL) {
pfr.rule.quick = 0;
+ pfr.rule.action = PF_MATCH;
strlcpy(pfr.rule.tagname, tagname,
sizeof pfr.rule.tagname);
}
