Re: Simple IPSEC client with certificate - phase 1 time out

[Brett Lymn <blymn%internode.on.net@localhost>]

On Wed, Mar 02, 2016 at 12:40:30PM +0100, Frank Wille wrote:
> >
> > OK and here is where things fall apart.  The client sends an "are you
> > there" request and vpn server sends a reply but it seems like the
> > packet did not get through and then things go bad from there...
> 
> What makes you think so? Looking at the tcpdump directly from the NetBSD
> client shows that the ACK from the Lancom router arrived (those were the
> only packets at 11:52:27):
> 
> 11:52:27.567012 IP 192.168.1.5.4500 > 1.2.3.4.4500: NONESP-encap: isakmp:
> phase 2/others I inf[E]
> 11:52:27.609318 IP 1.2.3.4.4500 > 192.168.1.5.4500: NONESP-encap: isakmp:
> phase 2/others R inf[E]
> 
> IMHO, DPD works fine.
> 

Because racoon says that it didn't receive the ack from the lancom -
either it received the packet and didn't like it or racoon didn't see it
for some reason.  It is good that the packet made it all the way back,
it would be better if we could understand what, if anything, racoon did
with it.

> 
> >> [VPN-Status] 2016/03/01 11:52:37,096
> >> VPN: connection for VPNCLIENT15EF90 (91.56.237.127) timed out: no
> >> response
> 
> BTW, this timeout is always 30 seconds after phase1 has been established. No
> matter what I do. With of without DPD. With or without mode_cfg.
> 

Right, that is the lancom losing patience and tearing down its side of
the connection.

> 
> > OK so what we can see here is that there seems to be some packet loss
> > that is causing the NetBSD client to wait for an answer but during that
> > time the vpn server decides nothing is happening and tears the
> > connection down.  So, some things to consider:
> 
> I'm not so sure about that packet loss. The only possible packet loss, which
> Greg already noticed in a parallel thread on tech-net, seems to be with
> NAT-T keepalive. But a test with a working Windows client using the same
> certificate on the same LAN showed that those keepalive messages are not
> replied either.
> 

Well, let's say packet loss from the point of view of racoon, ipsec can
be very sensitive to lossy networks so it is good the eliminate that as
a cause.  The test with the windows client is valuable, it shows that
ipsec can work from where you are.  As for the keep alives, the handling
of those depends on the client and/or its configuration - maybe the
windows client is configured to ignore the keep alives?

> 
> > 0) How reliable is the internet connection on the client side?  It
> > seems these days there is an assumption the connection is fast.
> 
> ADSL with approx. 6 MBit down and 1 MBit up. But our DSLAM is already
> capable of 50 or 100 MBit, and only 30m away.
> 
> I do not remember having any reliability problems.
> 

Good - another thing we can tick off as not being a cause.

> 
> > 1) Since one side is doing NAT-T, do you have port forwarding on the
> > router so that the IKE packets (udp 500 and 4500) are forwarded back to
> > the vpn client?  Though it seems you must already have this right to
> > get the phase 1 done...
> 
> That's an interesting question. No, I don't have port forwarding enabled. Do
> I really need that? I thought one of the reasons for using NAT-T is to work
> around such problems?
> 

Yes, I think you are correct... my flaky memory is probably throwing
that up because I was running a vpn server behind a NAT and had to do
the port forwarding.  As you have stated, NAT-T is supposed to work
around those issues.

> But, as you said, I see UDP 500 and 4500 packets coming through on both
> sides, and the Windows client is working over the same router. So I guess
> everything is fine...
> 

Yes, at a network infrastructure level it seems so given that the
windows client just works.

> 
> without. Now I did:
> 
> pass in from any to any
> pass out from any to any
> 
> ...for a test. But it didn't change anything. So I don't think there is a
> firewall problem.
> 

OK, that sounds like it eliminates a firewall issue.

> 
> > 3) some firewalls/routers don't like large udp packets, there are some
> > racoon settings for fragmenting packets - perhaps you need those.
> 
> I already had "ike_frag on" in my config. Now I also added "esp_frag 552",
> without making any difference.
> 

Try dropping the esp_frag to, say, 352 just to see what happens.  I know
the man page says 552 should be safe but that seems a bit close to the
minimum mtu which is 576.  At least a very low frag value will eliminate
the possibility of the packet getting fragmented.  Also, does the NetBSD
client network interface have any tcp checksum offload turned on?

> My current racoon.conf:
> 

That all looks fairly sensible to me...

> 
> Unfortunately "log debug" doesn't work at all. I get no debug messages out
> of racoon.
> 

I do recall being able to get logging out of racoon.  Have you tried
running racoon in the foreground (i.e. using the -F flag along with
multiple -d) also have you used the -l flag to log to a file instead of
syslog?

> Also I'm getting doubt whether "authentication_method rsasig" is working at
> all. Until now I found no success stories with such a configuration on the
> net, especially when using mode_cfg.
> 

As for a lot of things, it is hard to find success stories on the net -
if people have things working most don't seem to write anything about
it.  Most of what you find is people having issues and reaching out for
help.

Your authentication must be working at least to some extent - there is
no way that you would get a security association set up without that
happening.

> Did anybody ever use "rsasig"?
> 

I have only done hybrid-xauth, part of that was validating a
certificate.  One thought, how familiar are you with the configuration
of the windows vpn client?  Are you certain that there is not an
embedded username/password lurking there somewhere?  Does that client
have logging?  Perhaps you can try analysing the working windows client
logs to see what they are up to.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.