On Mon, Apr 18, 2005 at 02:09:12PM -0400, Jason Murray 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.
> 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 ...
Can
