[Vpn-help] SSH connection hang with beta 2

[Tai-hwa Liang]

On Sat, 5 May 2007, Matthew Grooms wrote:
[...]
> I have seen pf drop packet fragments on an interface unless you specify the 
> following in your configuration file ...
>
> scrub all fragment reassemble

   I do have a "scrub in all" in my default pf.conf; furthermore, if I read
the man page correctly, this implies "scrub in all fragment reassemble,"
which doesn't work for me.

> ESP traffic is especially susceptible to this due to the encapsulation 
> overhead. If that doesn't work for you, specify a rule like ...
>
> scrub all fragment reassemble max-mss 1440
>
> ... which is similar to what NetBSD folks suggest when building a VPN Gateway 
> using ipf.
>
> http://www.netbsd.org/Documentation/network/ipsec/rasvpn.html#more_frag

   After a few trial-and-error, it appears to me that using max-mss 552
as suggested in aforementioned link works better:

 	scrub in fragment reassemble max-mss 552

   I presume that 1440 still hangs the VPN client because we are using
540 as the default packet size.  With this new pf setting, the chance
that I run into a hanging connection turns out to be fewer than before.

   However, the concurrent "ping -t vpn.lan.address" session returns
different result in comparied to the old pf settings; that is, in the old 
"scrub in all" configuration, I can still see ICMP replies in another window 
even the primary ssh connection hangs. On the other hand, in the "max-mss" 
configuration, "ping -t" simply returns "Request timed out" whilst the ssh
connection is hanging.  Meanwhilst, any ping request sends to VPN server
will timeout.

-- 
Cheers,

Tai-hwa Liang