[Openswan Users] PAYLOAD_MALFORMED

harald.meyer7 at freenet.de harald.meyer7 at freenet.de
Fri Dec 19 04:11:00 EST 2008


Hi Tim!

> That does make sense and probably explains the malformed packets.

(You didn't have this idea [traffic from outdated SAs] by yourself if
you're "killing" one end!? ;-)  )


> The
> real trouble is that once both ends have established new phase 1 and
> phase
> 2 SAs, pings between the hosts are still failing in both directions
> and
> will do for hours, until I do an "ipsec --up <con name>".

Are you sure that there is no auto reconnect after your ipsec restart?
(This should be done if <conn name> is "auto=add" or "auto=start" in
ipsec.conf, I suppose.)

If not, here should be the problem, I suppose.

If you've "auto=start" at this <conn name> it perhaps failed becaus NICs
aren't up reliably - perhaps at system reboots?


> Maybe the non restarted end is using an old SA for all packets and
> therefore the restarted end can't decrypt the packets.

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.

But the successful reconnect of the restarted site should do the same.

It would be nice if the non restarted end would get answers from
the restarted end which will let it realize that other sites SAs aren't
valid anymore. But I don't know if this is possible outside of an
esteblished SA / tunnel. (I suppose this is only possible with a
regular rekeying attempt - from one of both ends.)


> But why haven't I
> seen this with previous versions of openswan that I have used? (circa
> 2 years old). Also why are only some connections affected?

Who should know this? ;-) Perhaps other configs / systems /
observations?


Harald









#adBox3 {display:none;}





More information about the Users mailing list