On Sat, Aug 10, 2002 at 06:21:26PM -0700, Chris Willis wrote: > This would be VERY useful functionality to have in pF. By having pF look > for a trigger port (in this case, a connection outbound on tcp/5000) > BEFORE it opens ports for the inbound traffic, you can setup complex > rules that only activate when a certain application is requesting > communications thru the firewall.
Ok, I see what you mean. But it's not as simple as you might think, especially when these connections are NATed as well. First question is, what applications/protocols depend on this? I can only think of H.323 (voice over IP) and games. I don't know about the latter much, but the former wouldn't work even with such a 'trigger' setup, because the protocol transfers client IP addresses inside the data portion of packets as well, which would require translation by a proxy. In general, you can try to statically forward the UDP ports to a single local host (and pass them with filter rules) and then try to use the protocol from that local host. If that doesn't work, it's likely because the client embeds its (private) address in the data, and the external server uses it to connect back. We are talking about protocols that were not created with NAT and firewalls in mind, otherwise they'd use the single TCP connection as single channel. I mean, these multiple UDP backchannels are worse than ftp. The second issue occurs when multiple local hosts connect to the same external server with such protocols concurrently. A single redirection for incoming UDP packets would not deal with this sufficiently, you'd want to associate UDP streams with individual TCP connections and forward to the right internal host. This requires that the incoming UDP packets have some criterion (like external source port) that allows such a distinction. I don't think cluttering the packet filter syntax with such monstruous constructs is the way to go. Rather, I could imagine a userland proxy on the firewall that intercepts the outgoing TCP connections and then dynamically adds/removes filter and translation rules for the incoming UDP streams to the local hosts, similar to what authpf does, but without the authentication. If you don't mind the authentication, authpf could already do that. If the protocol transmits client IP addresses as data, the proxy has to understand the data and translate them. That's why a H.323 proxy is a non-trivial project. ftp-proxy does that for ftp, but the ftp protocol is simple, compared to H.323. > I don't think this would be feature bloat - I think it would be an > EXCELLENT way for a corporate administrator to fine-tune their firewall > to their particular environment. It's also a fine way to poke huge holes into the firewall if not used very carefully. And looking at netfilter example rule sets, I see plenty of misuses that allow _external_ hosts to trigger the rule relaxations. Daniel
