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

Oleg Tarasov subscriber at osk.com.ua
Tue Dec 27 07:57:50 PST 2005


Hello,

Gleb Smirnoff <glebius at FreeBSD.org> wrote:


> The problem is that you've got a PPPoE link between local net and internet.

> (internet cloud, MTU 1500)-(your ISP)-[mtu 1492]-(your server)-[mtu 1500]-(your
> clients).

> So, when your Windows create a new outgoing connection they set TCP MSS
> value to 1460, since they don't know about a 1492 MTU link on the way.
> And this link limits TCP MSS to 1452.

> There are numerous solutions to fix this:

> 1) ports/net/tcpmssd - a divert daemon, like natd. You need to divert
>    traffic thru it, and it will alter the TCP MSS value to set limit.
> 2) ng_tcpmss(4) - a netgraph node, implementing same code in kernel.
>    You usually need ng_ipfw(4) to divert traffic via ng_tcpmss(4)
> 3) Recently I have committed ng_tcpmss support into mpd, but this
>    code is not yet included into any new release. If you are brave,
>    you can checkout mpd from CVS and use it. It will configure ng_tcpmss
>    node automatically.

I have analysed the problem further and came to a conclusion that my
ISP's server is blocking ICMP type 3 packets what leads to the
malfunction.

I have the latest version of ported mpd (3.18_3) installed and tried
to insert
         set iface enable tcpmssfix
but no positive result, but I understand that this option should help
in this situation.
 
Can you possibly tell me what am I doing wrong?
I'll say again that setting MTU on client machine to 1492 helps.
What can be the reason for tcpmssfix option not to be working? Maybe
there should be an additional kernel module loaded? I didnt find any
words mentioning usage of tcpmssfix in mpd's log file.


-- 
Best regards,
 Oleg Tarasov                          mailto:subscriber at osk.com.ua



More information about the freebsd-net mailing list