[NAT (iptables+freeswan)] Connection tracking for 500/udp

[Axel Thimm]

Hello Users and Netfilters,

a successfull created IPSec connection breaks off after some while with the
following log message:

Oct  4 08:52:55 bacchus Pluto[25223]: "bonzow2k-bacchus" #2: STATE_QUICK_R2: IPsec SA established
[...]
Oct  4 09:03:25 bacchus Pluto[25223]: some IKE message we sent has been rejected with ECONNREFUSED (kernel supplied no details)
Oct  4 09:03:25 bacchus Pluto[25223]: extended network error info for message to xxx.xx.xxx.xx port 500: compainant xxx.xx.xxx.xx, errno 111 Connection refused, origin ICMP (not authenticated) 2, type 3, code 3
[...]

Setup:
bonzow2k (private IP, IPsec, W2K) --- Firewall & NAT (iptables w conn. track.) --- ... --- bacchus (FreeSWAN FW)

I guess that after 10 min. (?) FreeSWAN (bacchus) sends some 500/udp packets
for IKE rekeying. When bonzow2k is initiating udp traffic iptables keeps a
record of this and knowns how to pass incoming 500/udp from the peer back to
bonzow2k.

It seems that iptables' connection tracking is caching this information for
less than 10 min.

- Can FreeSWAN be instructed to be passive in IKE connections? I.e. to have
  always the other peer send the first 500/udp packet?
- Can iptables be instructed to cache such "ESTABLISHED" or "RELATED"
  connections longer?

Of course the first solution would be better, as other firewalls would also
have to be handled specially. If FreeSWAN were to be told to only "answer" on
500/udp, then any firewall with connection tracking could participate (If the
firewall does not support connection tracking for udp, then you loose, as you
would only be able to redirect 500/udp packets to one and only host).

Regards, Axel.
-- 
Axel.Thimm+freeswan@physik.fu-berlin.de