Hi,
Is it possible, given the nasty way that tftp works to get natted clients
to talk to an outside tftp server?
In this case the tftp clients are a handful of cisco phones that want to
periodically pull down their configs.
A failed request looks like this:
(tcpdump of phone asking for config)
02:01:55.698286 btn.nat.fasttrackmonkey.com.50361 >
205-252-5-186.btnaccess.net.tftp: 20 RRQ "OS79XX.TXT" [tos 0x10]
02:01:56.697798 btn.nat.fasttrackmonkey.com.50361 >
205-252-5-186.btnaccess.net.tftp: 20 RRQ "OS79XX.TXT" [tos 0x10]
02:02:00.697584 btn.nat.fasttrackmonkey.com.50361 >
205-252-5-186.btnaccess.net.tftp: 20 RRQ "OS79XX.TXT" [tos 0x10]
(pflog of tftp server trying to answer - yes timestamps are off)
Oct 06 00:59:16.778480 rule 32/0(match): block in on xl0:
205.252.5.186.3954 > 216.220.116.154.49793: udp 16
Oct 06 00:59:17.778761 rule 32/0(match): block in on xl0:
205.252.5.186.3955 > 216.220.116.154.49793: udp 16
Oct 06 00:59:21.791347 rule 32/0(match): block in on xl0:
205.252.5.186.3956 > 216.220.116.154.49793: udp 16
It seems like I might have half a chance if the server sourced from port
69, but I'm just not seeing how to get this working since there's nothing
to really match on. I suppose I could shove all udp from that host at the
phone via a rdr, but if that same IP also does the SIP stuff, I might
break something.
Any ideas? All I know about the remote side is that they are running
Broadsoft's switch software. The client side is my Cisco 7960G.
Thanks,
Charles
