[Openswan Users] Fragmentation/reassembly bad behaviour

[albert agusti]

Hello, 

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)
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.

The scenario:
Running kernel 2.6.5-1.358 and Openswan-2.2.0 on Linux box on Responder
end (R)
Nortel Contivity on Initiator end (I)
NO NAT-T (real routing at both ends)

Situation: 
Tunnel negotiated successfully using PSK, traffic flows chipered from
both networks. Tunnel up and ok.
Nortel does not do MTU PATH DISCOVERY and has 1500 MTU value in Ethernet
and in WAN interfaces.

Problem:
There is a special kind of traffic from (I) to (R) that DON'T WORK and
it SHOULD.

IF 
1) Traffic is generated in the inside (protected network) behind Nortel
(Initiator end) 
AND 
2) this traffic wears the DF bit set
AND 
3) this packet is big enough to need the fragmentation of ESP (due to
new header overheat)

THEN
a) Nortel makes ESP paquet of data
b) Nortel splits in two packets because ESP header overhead
c) Nortel sends data to Openswan
d) ESP data reaches Openswan
e) ESP is reassembled
f) Orinal packet (outside the tunnel and exactly as the original that
entered) is recovered in clear mode
-- Until here all is OK
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

This brokes some kind of traffic in the tunnel like for example RDP or
any other using big packet size.

Here I paste you a tcpdump caught in Openswan Ethernet Interface showing
an example:

FRAGMENT 1
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)
FRAGMENT 2
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
ORIGINAL PACKET AS IT WAS (1460 payload + 20 TCP header + 20 IP header)
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
OPENSWAN GENERATES ICMP ERROR TO SOURCE
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)

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.

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.

DF bit is confusing openswan when appears in a reassembled packet.
This could be a kernel issue but I don't understand clearly which are
ipsec native stack tasks and which openswan. 

Thanks in advance
Albert Agustí
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20050110/cce99d2f/attachment.htm