Trouble with natd and path mtu discovery (ICMP_UNREACH_NEEDFRAG)

Rolf Grossmann grossman at progtech.net
Thu Jul 17 05:28:03 PDT 2003


Hi,

I'm currently running into a problem using natd with a private network
that does not have an overall mtu of 1500. Unfortunately the setup is
quite complex and I'd like to get by without explaining it all. So for
the moment I'll just ask about what I think is the problem and if you
need more information, you tell me so, okay ;)

The packet in question is here. This is what it looks like before natd
(received on internal interface):

14:04:43.688857 10.128.10.100 > 172.21.30.170: icmp: 10.129.16.1 unreachable - need to frag (mtu 1400) (DF) (ttl 253, id 0)

10.128.10.100 is the gateway that has a smaller mtu.
172.21.30.170 is the external host that was sending the big packet
10.129.16.1   is the internal host behind the gateway that requested the packet

Now when that packet passed natd it looks like this 
(transmitted on external interface):

14:04:43.689091 10.128.10.100 > 172.21.30.170: icmp: 192.168.89.1 unreachable - need to frag (mtu 1400) (DF) (ttl 252, id 0)

As you can see, the requesting host's ip has been adjusted to the "external"
address of the host running natd. Unfortunately, the gateway's ip has not.
Now if any router on the external side is doing reverse path checking
(and as it's not working I believe there is one doing that), it will just
drop the packet. And rightfully so, because it has an illegal source address.

Now my question is: Is that a bug in natd or is there some standard that
mandates the original ip must be preserved? And can someone please point
me at the code to change to get that packet aliased? (I've been looking
at libalias, but so far I don't quite get it.)

Thanks a lot,
Rolf.


More information about the freebsd-net mailing list