I've got a machine set up with NAT and a low-MTU uplink (ie, the
"outside" interface for the NAT).

This breaks PMTU-D for machines "inside" the NAT.  After adding
debugging code, I'm convinced that what's happening is:

- Large packet arrives from "inside"
- NAT does nothing on input
- ip_input calls ip_forward
- ip_forward calls ip_output
- ip_output calls the pfil_hook which NATs the packet
- ip_output discovers the packet doesn't fit
- ip_output calls icmp_error
- icmp_error constructs a packet with ip_src being the machine's
  "inside" address (the one the packet arrived on) and ip_dst being the
  machine's "outside" address (the ip_src of the post-NAT packet)
- icmp_error calls icmp_reflect calls icmp_send calls ip_output
- The ICMP packet is not un-NATted because it never goes through
  ip_input and thus is never seen by the pfil_hook which would normally
  back-NAT it
- ICMP packet never makes it back to sending machine

Result: a PMTU-D black hole.

I poked around a bit, and upon looking at the code for -current, I
don't see anything that would prevent this from happening just as
described above.  However, I don't have a -current setup I can test
with.  Does anyone know - or can test - whether this is still a problem
with -current?  If not, can anyone explain why not?  I don't think
changing versions is an option here, but importing the fix may be, if
it's simple enough.

If even -current still suffers from it, any thoughts on the best fix?
I'm inclined to arrange to have the icmp_reflected packet appear as
input on the interface that refused to accept the output packet as far
as NAT is concerned, perhaps by calling ip_input or perhaps by
duplicating enough of it to de-NAT the packet properly....

Of course, the best fix would be to do away with NAT.  I think that's
even less likely to fly in this case. :-(

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B