Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction

Brian Candler B.Candler at pobox.com
Tue Dec 27 01:28:43 PST 2005


On Mon, Dec 26, 2005 at 01:41:50PM +0200, Oleg Tarasov wrote:
> mpd configuration is attached in mpd.conf and mpd.links. Shortly, ng0
> is a PPPoE connection on rl1 interface.
       ^^^^^

Sounds to me like an MTU problem. Windows machine sends a 1500-byte packet,
but it can't fit into an ethernet frame along with PPPoE encapsulation, so
the router should either send back an ICMP error (if DF bit is set), or it
should fragment (if DF bit is not set). With DF, the Windows client is
supposed to automatically detect that the path MTU has been exceeded, and
try again with a smaller MTU.

The tcpdumps you show indicate DF is set. They don't show any ICMP
responses, but then again you didn't show the *exact* tcpdump command line
you gave.

I am guessing you did something like

   tcpdump -i rl0 tcp port 80

because you let tcpdump perform DNS lookups which means you omitted the -n
flag (bad idea), but I don't see the DNS packets going back and forth, which
means you had some sort of tcpdump filter which doesn't show DNS packets.

Better would be:

    # tcpdump -i ng0 -n -s 1500 -X host 209.132.176.176
    # tcpdump -i rl0 -n -s 1500 -X host 192.168.82.111

so that you see all packets to/from the clients, _including_ ICMP.

Something is causing a 'R' (RST) to be sent, terminating the TCP connection.
I'm not sure which device this is.

Anyway, there's an easy way you can prove whether MTU is the problem or not:
on the Windows client, manually set the MTU to something smaller, like 1460.
If that works, you know exactly what the problem is.

I _think_ your problem is that you are using natd, which is creaking and
ancient and maybe does not support NAT for path MTU discovery. But it maybe
that PPPoE doesn't support DF properly either. You didn't show your full
ipfw ruleset and natd configuration so it's hard to analyse further.

Does the PPPoE connection set up some sort of virtual interface, e.g. a
'tun' interface? If so you could try setting a lower MTU on it. Otherwise,
personally I would try switching from ipfw/natd to pf.

Hope that gives you a few ideas.

Brian.


More information about the freebsd-net mailing list