I had such a problem and it ended up having to do with the remote subnet 
and remote gateway entered. I now have "network" entered for local 
subnet type, and I have 192.168.1.0/24 in the address box. For the 
remote subnet I have 192.168.2.0/24 in the address box.

IIRC I ran into problems either with local subnet not set to "network", 
or the address not ending with a zero (192.168.1.0).

Hope this helps!
Andy

Robert Rich wrote:
> Hey Folks,
>
> We're having some stability issues with our m0n0 <=> m0n0 ipsec 
> tunnels.  They work for a while then stop.
>
> Just this morning i tested a tunnel and got this message on the source 
> end of the traffic:
>
> Oct 27 09:51:45     racoon: ERROR: none message must be encrypted
> Oct 27 09:51:45     racoon: INFO: initiate new phase 2 negotiation: 
> h.o.m.e[0]<=>w.o.r.k[0]
>
>
> On the 'head end', i get this in response:
>
> Oct 27 09:52:15     racoon: ERROR: w.o.r.k give up to get IPsec-SA due 
> to time up to wait.
> Oct 27 09:52:05     last message repeated 2 times
> Oct 27 09:51:45     racoon: ERROR: none message must be encrypted
> Oct 27 09:51:45     racoon: INFO: initiate new phase 2 negotiation: 
> h.o.m.e[0]<=>w.o.r.k[0]
>
>
> 'Head end' m0n0 is on 1.2b3 on WRAP.   'Client' m0n0 is 1.21 on WRAP.  
> These are mobile client tunnels (home systems are on DHCP).  Phase 2 
> lifetime is configured to be extremely high (1 year) to avoid 
> renegotiation too frequently..could that be the cause?
>
> Any ideas?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>