[vpn-help] Updated package and problem reports

Matthew Grooms mgrooms at shrew.net
Thu Aug 17 21:44:01 CDT 2006


Peter,

	A encountered a second anomaly when using NetBSD as a gateway. I 
enabled the esp_frag option in racoon and set it to 1024. This worked 
for a while until I encountered some large packets. When I sniffed the 
public interface I noticed that NetBSD was sending ICMP messages to the 
web server telling it that the destination ( the client ) was 
unreachable because the packet needed fragmenting. I have included a 
packet dump that illustrates this.

10.2.11.1 = NetBSD Gateway
200.46.204.197 = www.shrew.net

	The packet dump shown is just the client trying to simply open the web 
page with a "GET / HTTP/1.1" request.

	After reading the NetBSD Client VPN howto, it states that you have to 
use TCP MSS clamping as the solution. Sure enough, I added the pf 
equivalent ( scrub mss-max 800 ) and every site that I went to worked fine.

	IMHO, dropping the packet and sending an ICMP message is the wrong 
thing to do but I'm not a NetBSD developer. It seems like a hack as it 
relies on firewall packet manipulation to make everything work properly. 
I will post a message to the NetBSD list and ask them if there is a way 
to turn off the ICMP message and just fragment and forward the packet. 
After all, if both IPSEC peers know how to do pre-fragmentation ( like 
NetBSD and the Shrew Soft Client ), this isn't even necessary.

Anyhow, here is the link.

http://www.netbsd.org/Documentation/network/ipsec/rasvpn.html#more_frag

	I believe the Cisco VPN Client works without this as it has the ability 
to play tricks with its virutal adapter MTU. The Windows IP stack will 
adjust the TCP MSS size to fit the MTU so the whole issue is avoided. I 
may add an option to the client to do this as well but it doesn't really 
set well with me. I think both a VPN Gateway and even the client ( since 
its a mini gateway with a private and public interface ) should do what 
routers do ... fragment the packet when the interfaces have different 
MTU sizes and forward them on to the next destination.

-Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: natt.cap
Type: application/octet-stream
Size: 18730 bytes
Desc: not available
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20060817/1c2b9bb3/attachment-0002.obj>


More information about the vpn-help mailing list