<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Ok....<br>
<br>
I read your statement about pinging subnets and this is true. <br>
<br>
I try to test this on the 1und1 machine.<br>
<br>
A ping to 192.168.0.11 offers the following traces from tcpdump:<br>
<br>
<u><b>on 1und1: </b></u><br>
<b># ping 192.168.0.11</b><br>
<tt>PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.<br>
(NO OUTPUT BETWEEN THIS)<br>
--- 192.168.0.11 ping statistics ---<br>
65 packets transmitted, 0 received, 100% packet loss, time 64018ms</tt><br>
<b><br>
# tcpdump -n -v icmp and host 192.168.0.11</b><br>
<tt>tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture
size 96 bytes<br>
^[[A^C (NO OUTPUT BETWEEN THIS)<br>
0 packets captured<br>
0 packets received by filter<br>
0 packets dropped by kernel</tt><br>
<br>
<b># tcpdump -n -v icmp and host 217.91.16.223</b><br>
<tt>tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture
size 96 bytes<br>
13:47:03.413391 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 217.91.16.223 > 87.106.244.79: ICMP echo
request, id 59482, seq 11313, length 64<br>
13:47:03.413438 IP (tos 0x0, ttl 64, id 47334, offset 0, flags [none],
proto ICMP (1), length 84) 87.106.244.79 > 217.91.16.223: ICMP echo
reply, id 59482, seq 11313, length 64<br>
13:47:33.421405 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 217.91.16.223 > 87.106.244.79: ICMP echo
request, id 59482, seq 11314, length 64<br>
13:47:33.421449 IP (tos 0x0, ttl 64, id 47335, offset 0, flags [none],
proto ICMP (1), length 84) 87.106.244.79 > 217.91.16.223: ICMP echo
reply, id 59482, seq 11314, length 64</tt><br>
<br>
<u><b>ON MY 0.11
SYSTEM: </b></u><br>
<b># tcpdump -n -v host 192.168.0.100</b><br>
....<br>
<tt>13:47:32.782577 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF],
proto ICMP (1), length 84) <b>192.168.0.100 > 192.168.0.11</b>:
ICMP echo request, id 7447, seq 62, length 64<br>
13:47:32.782601 IP (tos 0x0, ttl 64, id 22891, offset 0, flags [none],
proto ICMP (1), length 84) <b>192.168.0.11 > 192.168.0.100</b>:
ICMP echo reply, id 7447, seq 62, length 64<br>
13:47:33.783123 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 192.168.0.100 > 192.168.0.11: ICMP echo
request, id 7447, seq 63, length 64<br>
13:47:33.783151 IP (tos 0x0, ttl 64, id 22892, offset 0, flags [none],
proto ICMP (1), length 84) 192.168.0.11 > 192.168.0.100: ICMP echo
reply, id 7447, seq 63, length 64<br>
13:47:34.782695 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 192.168.0.100 > 192.168.0.11: ICMP echo
request, id 7447, seq 64, length 64<br>
13:47:34.782719 IP (tos 0x0, ttl 64, id 22893, offset 0, flags [none],
proto ICMP (1), length 84) 192.168.0.11 > 192.168.0.100: ICMP echo
reply, id 7447, seq 64, length 64<br>
13:47:35.782762 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84) 192.168.0.100 > 192.168.0.11: ICMP echo
request, id 7447, seq 65, length 64<br>
13:47:35.782788 IP (tos 0x0, ttl 64, id 22894, offset 0, flags [none],
proto ICMP (1), length 84) 192.168.0.11 > 192.168.0.100: ICMP echo
reply, id 7447, seq 65, length 64</tt><br>
<br>
<u><b>ON MY 0.11
SYSTEM: </b></u><br>
<pre># debug ip nat
May 18 13:59:58.582 MESZ: NAT*: s=192.168.0.11->217.91.16.223, d=84.61.48.241 [31541]
May 18 13:59:58.626 MESZ: NAT*: s=84.61.48.241, d=217.91.16.223->192.168.0.11 [6962]
May 18 13:59:58.626 MESZ: NAT*: s=192.168.0.11->217.91.16.223, d=84.61.48.241 [31542]
May 18 14:00:00.130 MESZ: NAT: s=192.168.0.11->217.91.16.223, d=172.16.10.81 [53556]
May 18 14:00:01.721 MESZ: NAT*: s=192.168.0.200->217.91.16.223, d=145.253.242.114 [25350]
May 18 14:00:01.813 MESZ: NAT*: s=145.253.242.114, d=217.91.16.223->192.168.0.200 [58732]
May 18 14:00:02.313 MESZ: NAT*: s=192.168.0.200->217.91.16.223, d=145.253.242.114 [25351]
May 18 14:00:02.329 MESZ: NAT*: s=62.245.129.67, d=217.91.16.223->192.168.0.244 [19739]
May 18 14:00:02.329 MESZ: NAT*: s=62.245.129.67, d=217.91.16.223->192.168.0.244 [51523]
May 18 14:00:02.333 MESZ: NAT*: s=192.168.0.244->217.91.16.223, d=62.245.129.67 [2927]
May 18 14:00:03.109 MESZ: NAT*: s=62.245.129.67, d=217.91.16.223->192.168.0.244 [8176]
May 18 14:00:03.109 MESZ: NAT*: s=62.245.129.67, d=217.91.16.223->192.168.0.244 [48715]
May 18 14:00:03.109 MESZ: NAT*: s=192.168.0.244->217.91.16.223, d=62.245.129.67 [2928]
</pre>
no natting for packets towards 1und1.<br>
<br>
<br>
# debug ip packet<br>
<pre>May 18 14:05:41.758 MESZ: IP: tableid=0, s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), routed via RIB
May 18 14:05:41.758 MESZ: IP: s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), len 40, rcvd 3
May 18 14:05:41.758 MESZ: IP: tableid=0, s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), routed via RIB
May 18 14:05:41.758 MESZ: IP: s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), len 40, rcvd 3
May 18 14:05:41.758 MESZ: IP: tableid=0, s=192.168.0.254 (local), d=192.168.0.11 (BVI1), routed via FIB
May 18 14:05:41.758 MESZ: IP: s=192.168.0.254 (local), d=192.168.0.11 (BVI1), len 800, sending
May 18 14:05:41.762 MESZ: IP: tableid=0, s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), routed via RIB
May 18 14:05:41.762 MESZ: IP: s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), len 40, rcvd 3
May 18 14:05:42.454 MESZ: IP: tableid=0, s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), routed via RIB
May 18 14:05:42.454 MESZ: IP: s=192.168.0.11 (BVI1), d=192.168.0.254 (BVI1), len 72, rcvd 3
May 18 14:05:42.458 MESZ: IP: tableid=0, s=192.168.0.254 (local), d=192.168.0.11 (BVI1), routed via FIB
</pre>
<br>
<br>
You see .... the configuration on CISCO and 1und1 has NOT changed as it
works before (routes, nat and stuff). <br>
I can see now that openswan now regonizes "NAT-T on both sides" - and I
am sure it doesn't before suse 11.0 , but there is a chance that I am
confused about this.<br>
<br>
What the hell can this be! I think it is natting, because the packets
are received by my system and replied to 1und1 ... but never arraive at
1und1.<br>
<br>
I can try with "ping -i 192.168.0.0 192.168.0.11" and is the same
result as without "-I ". This is the routing table:<br>
<tt># route -n<br>
Kernel IP Routentabelle<br>
Ziel Router Genmask Flags Metric Ref Use
Iface<br>
10.255.255.1 0.0.0.0 255.255.255.255 UH 0 0 0
eth0<br>
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0<br>
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
eth0<br>
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
lo<br>
0.0.0.0 10.255.255.1 0.0.0.0 UG 0 0 0
eth0</tt><br>
<br>
<br>
Can it be that the "tun0"-interface is missing within 1und1 system ?? I
guess because I saw that in whack status:<br>
<tt>000 #5: "IPSECTUNNEL" <a class="moz-txt-link-abbreviated" href="mailto:esp.c67019db@217.91.16.223">esp.c67019db@217.91.16.223</a>
<a class="moz-txt-link-abbreviated" href="mailto:esp.7d7520f6@87.106.244.79">esp.7d7520f6@87.106.244.79</a> <b>tun</b>.0@217.91.16.223 <b><big>tun</big></b>.0@87.106.244.79</tt><br>
<br>
<br>
Thanks Paul and please stay with me, because I don't want back to suse
10.3. :)<br>
<br>
Regards Markus<br>
<br>
<br>
<br>
Am 2009-05-15 13:15, Paul Wouters schrieb:<br>
> On Fri, 15 May 2009, Markus Locher wrote:<br>
> <br>
> > -----------<br>
> > ==> ping 192.168.0.11<br>
> <br>
> > 192.168.0.0/24===80.16.24.9...21.9.1.23===192.168.0.0/24;
erouted;<br>
> <br>
> See my email yesterday on the list on pinging from a gateway with a<br>
> subnet-subnet tunnel. either add leftsourceip= or add host-subnet
and<br>
> subnet-host tunnels.<br>
> <br>
> Paul<br>
> <br>
>
</body>
</html>