[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isakmpd and icmp dependencies



I found removing the Don't Fragment bit with pf via:
 scrub in all no-df
scrub out all no-df
rules was a 'fix' for transfering files larger then approx
1050 bytes. Pings and small file transfers worked without
this. I don't know if this was the correct 'fix', but things do
appear to be working with the test vpn I set up.
I had started looking at MTU sizes when I first realized it
was a file size issue, but found reference to the scrub rule flag
and stopped troubleshooting when things started working.
The connection always came up okay as it appears yours
does.


Todd Boyer wrote:

>A good explanation about this problem can be found at
>http://www.netheaven.com/pmtu.html
>ICMP Types and Numbers (with associated RFC's numbers) can be found here:
>http://www.iana.org/assignments/icmp-parameters
>Thanks for the reply and advice
>-Todd
>
>
>-----Original Message-----
>From: Hakan Olsson [mailto:ho@rfc.se]
>Sent: Monday, September 08, 2003 12:52 PM
>To: Todd Boyer
>Cc: 'misc@openbsd.org'
>Subject: RE: isakmpd and icmp dependencies
>
>
>On Mon, 8 Sep 2003, Todd Boyer wrote:
>
>  
>
>>Thanks for the reply.  I've set net.inet.ip.mtudisc = 0 and lowered the
>>    
>>
>MTU
>  
>
>>to 1400.  Still no luck.  netstat -rn shows all established links,
>>    
>>
>"ipsecadm
>  
>
>>show" shows all negotiations and looks fine.  My configuration worked
>>perfect until my upstream provider blew away icmp responses including type
>>    
>>
>3
>  
>
>>unreachable.  UDP 500 and IP 50 are open and obviously are enabled or the
>>    
>>
>...
>
>FWIW, your "ISP" just showed they really have no clue on how to be an ISP.
>ICMP, especially the uncreachable and time-exceeded types, are necessary
>for TCP/IP to work properly, as anyone with basic TCP/IP-knowledge should
>know. (For example to avoid those annoying waits before your favorite
>browser says "webserver not responding" or whatnot.)
>
>Sadly, this is an growing problem. In much the same way that many firewall
>admins only permit UDP port 53 for DNS, and not TCP. (Too much data in a
>packet -> failover to TCP.)
>
>Now, for your immediate problem -- make sure both side's MTUs are lowered.
>Say you send a short (<1400) "query", but the "response"-packet exceeds
>the limit and so it will very likely not reach you.
>
>You may want to experiment with max-mss also (see pf.conf(5).
>
>/H