[Openswan Users] PAYLOAD_MALFORMED

openswan at thefeds.net openswan at thefeds.net
Sat Dec 20 17:00:11 EST 2008


I have dpd turned on with a restart action. I also have auto=start.

Phase 1 is fine, DPD is doing it's job. The only sign of a phase 1 problem 
is the log messages which are most likly nothing.

I do have a phase 2 problem however. Under normal rekeying situations 
something is going wrong and I am seeing each side having one SA, with 
different SPIs seen as current on each side (both own SPI and other SPI 
are different on both sides). Obviously traffic is failing to pass as the 
ESP packets cannot be decrypted.

I have monitoring running on each of the 12 servers, polling every minute 
to check that it can ping each other server and that there is >1 ISAKMP SA 
and >1 IPSEC SA. Over the last 24 hours I have had no instances of 0 phase 
1 or phase 2 SAs, but I have had about a dozen instances of phase 2 
problems accross the 66 SAs that make up a full mesh between the 12 
servers. I have not restarted ipsec or rebooted any of the servers in this 
24 hours.

When I looked at /var/log/secure for one of the phase 2 failures I saw a 
new phase 2 SA was installed roughly 20 minutes before the failure. 
Imediatly after the new phase 2 SA was installed phase 1 malformed packets 
started to be logged. 19 minutes later a new phase 1 SA was installed and 
the malformed packets stopped being logged. But the ping test stopped 
working on its next poll. This doesn't seem to make any sense to me. On 
Monday I will look at more logs to see if the same pattern is happening 
every time. I will also contrast the log messages to a working phase 2 
then phase 1 rekey.

Tim


On Fri, 19 Dec 2008, Paul Wouters wrote:

> On Fri, 19 Dec 2008, harald.meyer7 at freenet.de wrote:
>
>> The non restarted end have to be informed that the opposite site
>> isn't ready for their old SA packets.
>>
>> I suppose you have to activate some sort of DPD detection or to
>> lower your SA reassignment periods / timeouts.
>
> DPD only works on phase1, not phase2.
> The rebooting end should restart the tunnel and negotiate a new SA.
> Then the non-rebooted end will replace its SA with the new one.
>
> Paul
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>


More information about the Users mailing list