strongSwan

sorry i copied not the complete %default

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
uniqueids=yes
fragicmp=no
nocrsend=yes
charonstart=no
nat_traversal=yes

conn %default
keyingtries=0
type=tunnel
keyexchange=ikev1
keylife=8h
authby=rsasig
auto=add
compress=yes
dpdaction=clear
dpddelay=10
dpdtimeout=30

uniqueids and dpd is active. in this case that won't work. with an older version of strongswan (2.8) it works.
i won't have a pool for the clients, because i've iptables rules for each client. the client should always have
the same ip.

Yes, in older versions (before 4.1.7) pluto also compared the port in addition to the IP address when it cleared out existing connections due to uniqueids=yes. Thus, clients behind a NAT would most likely have triggered that check with each new connection attempt (even if the IP did not change).
The changelog for 4.1.7 and the original commit message (see 8129cc84) cite an incompatibility between multiple Quick Mode exchanges and NAT Traversal as reason for removing the port check. This means, to restore the previous behavior you can either try to add the port check again or try to remove the IP address check altogether, as mentioned previously.

uniqueids and dpd is active. in this case that won't work.

Not sure what you mean. With your config the old SA should be deleted after 30 seconds of inactivity. Unless, of course, the client doesn't support DPD - in which case you'd actually have a problem.

By the way, if the firewall runs on the same box as pluto you could also install the rules dynamically in a custom updown script depending not on the IP address but on the actual ID of the client.

strongswan without the check

---snip---
3082 if (d->kind >= CK_PERMANENT &&
3083 c->spd.this.id->equals(c->spd.this.id, d->spd.this.id) &&
3084 c->spd.that.id->equals(c->spd.that.id, d->spd.that.id))
3085
3086 {
3087 release_connection(d, FALSE);
---snip---

no connection possible, strongswan restarts with the following message in the kern.log
---snip---
Mar 30 15:48:41 gate kernel: pluto²⁹²¹⁷: segfault at 1a8 ip 08060522 sp bce090c0 error 4 in pluto[8048000+6c000]
---snip---

the diff from revision 8129cc84 is also not working ...

---snip---
3082 if (d->kind >= CK_PERMANENT
3083 && same_id(&c->spd.this.id, &d->spd.this.id)
3084 && same_id(&c->spd.that.id, &d->spd.that.id)
3085 && (!sameaddr(&c->spd.that.host_addr, &d->spd.that.host_addr) ||
3086 (c->spd.that.host_port != d->spd.that.host_port)))
3087 {
---snip---

kernel message
---snip---
Mar 30 16:13:27 gate kernel: pluto²⁹⁹⁰¹: segfault at 1a8 ip 08060522 sp b526e470 error 4 in pluto[8048000+6c000]
---snip---

Hm, ok. I guess pluto deletes the current connection without that check. Perhaps a comparison like

&& c != d

that works

some questions:
- there are any problems about this changes ?
- this pooling is disabled with that patch, isn't it ?
- will this code be released ?

issue with that changes
---snip---
000 "roadwarrior183"[24]: 0.0.0.0/0===8.15.11.23[C=DE, ST=NRW, L=M, O=ABC, OU=roadwarrior-ca, CN=gate.abc.de, E=s.j@abc.de]---8.15.11.22...79.245.89.88[C=DE, ST=NRW, L=M, O=ABC, OU=roadwarrior-ca, CN=roadwarrior288, E=w.c@abc.de]===0.0.0.0/0; erouted; eroute owner: #558
---snip---

left and right is 0.0.0.0 and all traffic will be routed to the roadwarrior

- there are any problems about this changes ?

Could be, no idea.

- this pooling is disabled with that patch, isn't it ?

I suppose, as any connection with the same IDs except the current one will be deleted.

- will this code be released ?

Nope.

issue with that changes
---snip---
000 "roadwarrior183"[24]: 0.0.0.0/0===8.15.11.23[C=DE, ST=NRW, L=M, O=ABC, OU=roadwarrior-ca, CN=gate.abc.de, E=s.j@abc.de]---8.15.11.22...79.245.89.88[C=DE, ST=NRW, L=M, O=ABC, OU=roadwarrior-ca, CN=roadwarrior288, E=w.c@abc.de]===0.0.0.0/0; erouted; eroute owner: #558
---snip---

left and right is 0.0.0.0 and all traffic will be routed to the roadwarrior

Hm, I don't really know pluto that well. It's strange, though, that this change would cause this.