Hello Heinz,

On Fri., Jan 28, 2011, Heinz TEICHMANN wrote:
>On Fri., Jan 21, 2011, Michael wrote:
>>>Probably there's a bug in the racoon version of m0n0wall. I've
>>>even updated to 1.33b1 after reading that something relating
>>>to dynamic IPs and IPSec had been improved (the resolv.conf
>>>I think.) Even with 1.33b1 I'm having the same problems.
>>>
>>I just adjusted the configuration which seems to help in my case.
>>Since the adjustment, all three m0n0wall routers are indeed able
>>to exchange traffic through their VPN tunnels even after one of
>>the three IP addresses change.
>>
>>The change in the configuration was in the menu Firewall/NAT.
>>If you choose 'Enable advanced outbound NAT' in the Outbound tab,
>>then make sure to deselect 'Disable port mapping' in the entries.
>>
>I can't confirm this. In my case "Disable port mapping" is always
>checked because of SIP.  Everywhere in the web interface you see
>the new address of the other party, but the racoon logs say that
>it is trying to establish a connection to the old IP address.
>The biggest trial was 3 sites with version 1.32 and all 3 behave
>the same way.
>
To be clear, I have a similar setup as you do (disable port
mapping to force RTP symmetrical traffic over the NAT.)

Here are my suggestions for you. Upgrade to the M0n0wall 1.33b1
beta released late December. That's what I'm using since it
seems to include some IPSec fixes relevant to dynamic IP
changes (resolv.conf logic according to the changelog.)

Most importantly, instead of a single outbound NAT rule for
the subnet in question, add two of them. If your devices are:

  Computing devices: 192.168.1.0/24   (entire subnet)
  Telephone devices: 192/168.1.64/28  (partial region)

...then check 'Enable advanced outbound NAT' and enter the custom
outbound NAT rules:

  Interface  Source           Destination  Target          Description
  WAN        192.168.1.0/24   *            *               Computers
  WAN        192/168.1.64/28  *            * (no portmap)  Telephones

If you do this and if my hypothesis is correct, then for at least
the devices in your 'Computers NAT region' your IPSec will start
working across dynamic IP address changes. I've tested this since
a few days now without any problems.

The beta release is on three M0n0wall routers here and I haven't
noticed any instability or beta artifacts. Only one of the three
M0n0wall routers experiences daily IP address changes, however.

By the way this is no solution to the problem, but just a good
workaround. A real solution would not involve manipulation of the
NAT rules. You must have other things in order as well before IPSec
works across IP address changes. For example, I assume that you
already have both 'Enable NAT Traversal (NAT-T)' and 'DPD interval'
enabled in your IPSec entries.

Hope that helps. If you get a chance to try these suggestions,
please report back to say if they worked for you.

Regards,
Michael