[c-nsp] IPSEC + TFTP don't work

[Robert E. Seastrom]

Victor Sudakov <vas at mpeks.tomsk.su> writes:

> Randy wrote:
>> Victor wrote:
>> > RS wrote:
>> > > 
>> > > Try setting the MTU on the ethernet on the TFTP server to 1400 or so
>> > > rather than 1500.  That oughta fix the problem, assuming that the tftp
>> > > server software is sanely written.  If it were TCP (tftpboot is of
>> > > course udp) that would DTRT.
>> > 
>> > Actually I have tried something like 
>> > 
>> > route add -net $protected_net -mtu 1300 $ipsec_gateway
>> > 
>> > on the TFTP server and it did not help. I think the TFTP
>> > server just
>> > sends its packets as requested by the client and does not
>> > care if the
>> > MTU is small.
>> 
>> 
>> What you tried, wouldn't work because TFTP is UDP and the mtu size
>> is decided by application in question; unlike TCP.
>
> Therefore I thought that the above advice ("try setting the MTU on the
> ethernet") would not work either.

It might not.  I qualified that advice with "if the server software is
sanely written".  I have enough gray hair to remember stuff like
ProNet80, Hyperchannel, FDDI, and IBM Token Ring (both speeds), each
with a different MTU.  Heck, you might get lucky and have 10ge with
jumbo frames big enough to stick the entirety of pxeboot(8) in a
single packet.  Anyway, it would never occur to me to write something
that sent UDP packets (which I intended to arrive un-fragmented
because typically the stacks that speak TFTP are brain-dead and can't
handle reassembly) without groveling through whatever gymnastics I had
to in the OS to crawl through the routing table, determine the exit
interface, and set the size of the packets I wanted to send
accordingly.

Guessing at the OS and specific release of software you're running and
performing a code review to see if whoever wrote that TFTP server
wrote it in the way that I would have is, obviously, beyond the scope
of the free advice you're likely to get in an august forum such as
this.

-r