<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
Hello, <BR>
<BR>
I reported a bug (0000213 [OpenSWAN] :Other/Unknown major always 01-05-05 21:26 01-05-05 21:26) some days ago, but for the moment is not assigned. After some more probes reproducing the problem, I think I can now explain more clearly (I'll update BUG tool)<BR>
I'm not sure if this behaviour is dued to openswan or kernel 2.6 native ipsec stack because the problem arises when routing packets one time have correctly crossed the IPsec tunnel.<BR>
<BR>
The scenario:<BR>
Running kernel 2.6.5-1.358 and Openswan-2.2.0 on Linux box on Responder end (R)<BR>
Nortel Contivity on Initiator end (I)<BR>
NO NAT-T (real routing at both ends)<BR>
<BR>
Situation: <BR>
Tunnel negotiated successfully using PSK, traffic flows chipered from both networks. Tunnel up and ok.<BR>
Nortel does not do MTU PATH DISCOVERY and has 1500 MTU value in Ethernet and in WAN interfaces.<BR>
<BR>
Problem:<BR>
There is a special kind of traffic from (I) to (R) that DON'T WORK and it SHOULD.<BR>
<BR>
IF <BR>
<I>1) Traffic is generated in the inside (protected network) behind Nortel (Initiator end</I>) <BR>
AND<I> <BR>
2) this traffic wears the DF bit set</I><BR>
AND <BR>
<I>3) this packet is big enough to need the fragmentation of ESP (due to new header overheat)</I><BR>
<BR>
THEN<BR>
a) Nortel makes ESP paquet of data<BR>
b) Nortel splits in two packets because ESP header overhead<BR>
c) Nortel sends data to Openswan<BR>
d) ESP data reaches Openswan<BR>
e) ESP is reassembled<BR>
f) Orinal packet (outside the tunnel and exactly as the original that entered) is recovered in clear mode<BR>
-- Until here all is OK<BR>
<B>e) Openswan decides that this packet CAN'T be routed to the local (protected network) claiming that he has an MTU of 1500 and generates ICMP error to the packet originator<BR>
</B><BR>
This brokes some kind of traffic in the tunnel like for example RDP or any other using big packet size.<BR>
<BR>
Here I paste you a tcpdump caught in Openswan Ethernet Interface showing an example:<BR>
<BR>
<FONT SIZE="1"><B><TT>FRAGMENT 1</B><BR>
18:58:47.642701 IP (tos 0x0, ttl 246, id 29, offset 0, flags [+], proto 50, length: 1500) I.I.I.I > R.R.R.R: ESP(spi=0xa74589ad,seq=0x1e)<BR>
<B>FRAGMENT 2</B><BR>
18:58:47.645376 IP (tos 0x0, ttl 246, id 29, offset 1480, flags [none], proto 50, length: 72) I.I.I.I > R.R.R.R: ipv6-crypt<BR>
<B>ORIGINAL PACKET AS IT WAS (1460 payload + 20 TCP header + 20 IP header)</B><BR>
18:58:47.645376 IP (tos 0x0, ttl 127, id 22842, offset 0, flags [DF], proto 6, length: 1500) 192.168.6.1.1499 > 10.10.10.25.3389: . 1020:2480(1460) ack 7615 win 16837<BR>
<B>OPENSWAN GENERATES ICMP ERROR TO SOURCE</B><BR>
18:58:47.645776 IP (tos 0xc0, ttl 64, id 53563, offset 0, flags [none], proto 1, length: 576) R.R.R.R > 192.168.6.1: icmp 556: 10.10.10.25 unreachable - need to frag (mtu 1500) for IP (tos 0x0, ttl 126, id 22842, offset 0, flags [DF], proto 6, length: 1500)</TT></FONT><BR>
<BR>
In this example, original packet was 1500 bytes, but after a lot of changes in interfaces MTU and generate different kinds of traffic, it does not matter. ALWAYS that the conditions explained are meet (traffic with DF that is reassembled from various ESP received fragments), openswan generates ICMP error. This ICMP is not routed to Nortel, but in any case would be ignored because Nortel's MTU is yet 1500. Packet fits in network but Openswan thinks not.<BR>
<BR>
<B>NOTE: If this kind of traffic is directed to Openswan gateway itself, IT WORKS !!! so it must be something around routing decission after packet is received.<BR>
</B><BR>
DF bit is confusing openswan when appears in a reassembled packet.<BR>
This could be a kernel issue but I don't understand clearly which are ipsec native stack tasks and which openswan. <BR>
<B></B><BR>
Thanks in advance<BR>
Albert Agustí
</BODY>
</HTML>