On Tue, Apr 19, 2005 at 07:37:33AM +0300, Can Erkin Acar wrote: > > I'm trying to set up a tftp server to host the configs of some PIX > > boxes. The PIXes and the tftp server are separated by a pf box. And > > before anyone gets smart and says "why not replace the PIXes with PF" > > that's a non-starter. I'd love to, but it ain't going to happen. > > > > Anyway onto the the problem. I see the tftp traffic pass in: > > Apr 18 13:46:59.438588 rule 23/0(match): pass in on de3: > > 172.17.16.250.1034 > 192.168.42.20.69: 32 WRQ "wsg-conf-200504180" [|tftp] > > Apr 18 13:46:59.438727 rule 25/0(match): pass out on xl0: > > 172.17.16.250.1034 > 192.168.42.20.69: 32 WRQ "wsg-conf-200504180" [|tftp] > > > > I see the daemon start from inetd and accept the connection. > > > > Then I get this: > > Apr 18 13:46:59.445133 rule 0/0(match): block in on xl0: > > 192.168.42.20.34472 > 172.17.16.250.1034: udp 21 (DF) > > > > Two questions: > > 1) is this "normal" tftp behaviour? I've not fooled around with it > > before. I would have expected a trivial file transfer protocol to reuse > > the existing sockets. > > Yes this is the normal, braindead tftp behaviour.
Indeed. > > 2) any suggestions on how to adapt the rules to deal with this? > > Obviously keep state is not enough, but I'm sure this has been solved > > before. > Hm, if you are running PF on the tftp box, you can match the > outgoing packets as 'user _tftp' > > If your PF box is separate, you would have to use a userland > tftp proxy (no such thing exists afaik) or something like > > pass from $tftp_server proto udp port > 1024 to ... For my house, where a Cisco router sits outside my PF firewall and the tftp server sits inside (on an RFC1918 net), I get by with a single ruleset allowing the first inbound packet to 69/udp, rdr'd to the internal tftp host, and the default "allow-outbound udp w/NAT, keep state" takes care of the rest of the conversation. I do have some notes in my pf.conf that suggests the "rdr pass" method I use for inbound first-packet tftp was not sufficient to get the first packet in over the internal interface, and so there's a second filter permit rule (on th einside interface) to that effect. This is on 3.6-STABLE, with the rules originally set up at 3.6-RELEASE. The things I do may not strictly be necessary anymore, but it didn't break with the various changes to -STABLE (I'm at GENERIC#16 just now) over the life of 3.6. I can furnish a pf.conf extract if this scribble doesn't do; please contact me directly. But if your local policy doesn't permit default-allow udp from tftp server to tftp client, don't bother. Spend your time writing a solid tftp application proxy. Someone, somewhere, will eventally thank you. -jml