Re: [Ipsec-tools-users] roadwarrior IPSec tunneled vpn works only for clients behind nat (!)

[Mick <mic...@gm...>]

On Thursday 19 Jan 2012 15:05:58 you wrote:

[snip ...]

> > So the real question is why isakmp_post_acquire uses a TRUE value, which
> > means that the remote configuration mustn't be passive. I am not really
> > an expert on IKE and IPSec so I cannot (at least not yet) understand why
> > quite yet.

I'm no expert either, but this is how I understand it:

The gateway MUST have passive on, because it will not be initiating 
connections.  The VPN clients will.

Therefore the test you described is to ensure that when the gateway is 
passive, the client is *not* passive and therefore in a position to 
(legitimately) initiate a connection.


> >> I would try setting:
> >>        proposal_check obey;
> >>        generate_policy unique;
> > 
> > Yes, I already use those two settings.

Good.

> >> on the gateway.  Flush the SAs before you try new settings.
> > 
> > setkey -D and setkey -DP do not show anything strange. When nobody's
> > connected, I can see no SAs. When a client (nat or no nat) is connected I
> > can see a pair of SAs with the appropriate type (esp-udp or esp
> > respectively).

Also good.  Just wanted to make sure there were no stale SAs in there.


> >> Would also check what type of nat-traversal the client has (some have
> >> different
> >> NAT-T options;  e.g. draft, or rfc compliant).
> > 
> > Well, the relevant document  (
> > http://help.apple.com/iosdeployment-vpn/#app36c95bff ) says "Standard NAT
> > Transversal" (sic).
> > 
> > I think apple uses racoon, so there *should* no problem on this front.

Yes, there shouldn't ... assuming client and server have compatible versions 
and there no bug clash between them.  ;-)


> Ok, here's an update.
> 
> I removed 'passive on' and noticed that although I can now see quick mode
> messages, both peers try to initiate phase 2. The client tries once and
> succeeds. Here are is an excerpt from system.log on the client:
> 
> macosx client:
> Jan 19 15:02:20 racoon[12655]: IPSec Phase2 started (Initiated by me).
> Jan 19 15:02:20 racoon[12655]: IKE Packet: transmit success. (Initiator,
> Quick-Mode message 1).
> Jan 19 15:02:20 racoon[12655]: IKE Packet: receive success. (Initiator,
> Quick-Mode message 2).
> Jan 19 15:02:20 racoon[12655]: IKE Packet: transmit success. (Initiator,
> Quick-Mode message 3).
> Jan 19 15:02:20 racoon[12655]: IKEv1 Phase2 Initiator: success. (Initiator,
> Quick-Mode).
> Jan 19 15:02:20 racoon[12655]: IPSec Phase2 established (Initiated by me).

This is good, the client can initiate and establish a connection.


> But, the racoon server tries continuously to initiate phase 2 itself as
> well, establishing several IPSec SAs whose number is constantly growing.

The problem here is that the server should be passive - i.e. not initiating a 
connection and await for IKE sessions to start from the client.  So it must 
have:  passive on

It is worth noting that these tunnels are not NAT-ted.


> What's interesting is that the client receives those messages and declares
> each time that phase 2 is established:

Because the client responds to legitimate connection sessions.

Have you set up a mod_cfg section on the gateway for the client to know what 
subnet to acquire?

Do you have subnets configured on both end-points using the same nomenclature?


> But the server keeps pounding on and on.

The established SA is collapsing.  Then it starts all over again.  I'm not 
sure that this should be happening - typically it is an indication of 
mismatched subnets, but in this case it could be some bug or a configuration 
problem.


> (* It is worth noting that even with passive=on on the server, the client
> still thinks the phase 2 is established like above,  while the server
> itself emits the errors I described in my previous emails)

Yes, these errors should not happen.


> At this point what I would really like is to be told authoritatively
> whether I need to have passive=on on my server or not.

passive=on because the server will not be initiating a connection - in all 
cases the clients will.

-- 
Regards,
Mick