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

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.
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: SBS 2003 Setup recommendation
    ... Your suggestion about MTU looks very interesting. ... We want something lige the following setup: http://pings.dk/sbssetup.gif ... agaist SBS2003 server. ... IPSec adds a small overhead the size of a packet which would make packets ...
    (microsoft.public.windows.server.sbs)
  • Re: Fragmented Packets Problem On Virtual PC for MAC(Shared Networking Mode)
    ... I had tried adjusted the MTU in windows, I'm connect my iBook to cable ... The maximum size of packets ... no matter how I adjust ...
    (microsoft.public.mac.virtualpc)
  • Re: Problem of blocking ICMP packet while calculating Path MTU
    ... > I am in process of implementing Path MTU detection technique. ... > process the received ICMP ECHO reply packets. ... > there is no need to write server code at all. ...
    (comp.os.linux.networking)
  • Re: Cisco VPN3000 gateway MTU overflow
    ... Path MTU Discovery and Client MTU determination. ... the Concentrator responds to internal ICMP/PMTUD requests and requests an ... Since the concentrator does fragment large packets, ...
    (Bugtraq)
  • Re: Can see some sites, not others from Client PC.
    ... > Hi Chuck, ... the instructions were either unclear or in the ... but had gleaned that the problem may be caused by too high a MTU ... I imagine its like packets of data) at the Client? ...
    (microsoft.public.windowsxp.network_web)