[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: Question/suggestions about tftp
From:       John Ladwig <jladwig () mango ! lioness ! net>
Date:       2005-04-19 11:34:21
Message-ID: 20050419113421.GA16567 () mango ! internal
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]