[Openswan Users] Some kind of fragmentation or MTU problem

[Robin Cornelius]

Hi Guys, having a problem on Deban Sarge with openswan (sarge's 2.6.8 kernel 
and Debian's openswan 2.2.0)

My set up is like this ->

my PC (real internet address)			        |--------192.168.0.20 
x.x.x.x					     (adsl)		| 
---------------------------------------------------(router)------------------192.168.0.3 
	       (internet)	                  192.168.0.1			(VPN)


192.168.0.3 is the VPN server. So there is a tunnel from "My pc" to 
192.168.0.3 Or in case two MY PC is behind a NAT. 

Either way I can create a tunnel from my pc to 192.168.0.3, i can ping 
192.168.0.3. with my pc being either debian/openswan or winXP.

I can access everything on 192.168.0.20 and the reset of the subnet no 
problems but if i try to access anything real on 192.168.0.3 it breaks.

I.e i can access http/pop3/smb on 192.168.0.20 but NOT on 192.168.0.3. The 
connections just hang, Ping results for 192.168.0.3 are intresting however :-

ping 192.168.0.3 -s 30000  (all OK)

debian:/home/robin# ping 192.168.0.3 -s 40000
PING 192.168.0.3 (192.168.0.3) 40000(40028) bytes of data.
40008 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=2855 ms
40008 bytes from 192.168.0.3: icmp_seq=3 ttl=64 time=2831 ms
40008 bytes from 192.168.0.3: icmp_seq=4 ttl=64 time=3340 ms
40008 bytes from 192.168.0.3: icmp_seq=8 ttl=64 time=2864 ms

or nothing at all.

if i ssh to 192.168.0.3 and try dmesg it locks the terminal. BUT if i ssh to 
192.168.0.20 THEN to 192.168.0.3 it is OK.

This implyies a MTU type problem, BUT i can't change the mtu!, the mtu on 
192.168.0.3's eth0 interface is 1400, if this is at the standard 1500 then 
access to the subnet (eg 192.168.0.20) breaks, which is understandable. If i 
reduce the mtu futher then I also limit the size of the ESP packets and hence 
always have a MTU problem for direct access to 192.168.0.3.

What can i do?

Can iptables claiming rules help me here? 

Can i force the MTU somehow? i don't have a physical interface to set on 
192.168.0.3 as that IS the tunnel endpoing.


Any ideas greatly recieved

Many thanks

-- 
Robin Cornelius
---------------------------------------------------
robin at cornelius.demon.co.uk
http://www.cornelius.demon.co.uk
http://sourceforge.net/projects/rt2400
GPG Key ID: 0x729A79A23B7EE764
http://www.biglumber.com/x/web?qs=0x729A79A23B7EE764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20050616/fc9fab61/attachment.bin