Re: NetBSD as IPSEC client with NAT-T / PSK / XAUTH - can't get it to work :-/

[Dima Veselov <kab00m%lich.phys.spbu.ru@localhost>]

On Tue, Jun 08, 2021 at 10:04:44AM +0200, Matthias Petermann wrote:
> I would like to connect a NetBSD client to a remote LAN via IPSEC. 
> Unfortunately, I am stuck at a very early point and would like to know 
> if I am making a basic mistake or if I am expecting something from 
> NetBSD that it cannot do.

> 2021-06-08 07:32:08: ERROR: phase1 negotiation failed due to time up. 

> 6) Observations / Summary
>
> It looks like I'm not getting any response at all from the remote 
> endpoint. Therefore, racoon tries to send the phase1 packet several 
> times and finally gives up via a timeout.

First of all you forgot to build (or to mention) ipsec tunnel specification
which usually is set in /etc/ipsec.conf. Tunnel specification includes
external addresses, internal addresses and protocols. Most of firewalls
will not answer if offered tunnel specification is not expected.

Your second problem is the tunnel itself. Your setup is more likely
site-to-site clean IPSEC, but site-to-site must be configured on both
sides. Client-to-site VPN use different approach.
It is very likely you can't build both from behind same NAT. If your
task is not the digging up into IPSEC you may want to use
security/openvpn from pkgsrc.

> 1) Does my configuration match the spec of the endpoint, or have I 
> missed something fundamental? Especially for the fact that the 
> Fritzbox does not support authentication headers, I do not know how to 
> check this part in my racoon configuration.

We have to know what specification router do expect. It should have
some configured options to look at.

> 2) Is NAT-T known to work without problems in NetBSD 9.2? I have read 
> some mailing list posts, also from times when this was apparently not 
> yet supported / broken / questionable for patent reasons. Where 
> options(8) mentions under IPSEC_DEBUG that NAT-T is supported.

I guess it work right with open source compatible routers.

> 3) Switching to a kernel with IPSEC_DEBUG didn't seem to do anything - 
> I don't see any additional IPSEC messages in the logfiles during my 
> connection attempts. Of course, this could also mean that I didn't 
> even get as far as running anything through ipsec's kernel engines.

There is some gap about IPSEC knowledge. You have tried to use isakmp
daemon (e.g. racoon) only, no IPSEC was ever used. This how it works:

1. Stage 1. isakmp daemon connect to other isakmp daemon and they talk
to each other. Upon success they have mutual security association and
now they can exchange keys. This is called phase 1 or ISAKMP security
association (also known as IKE).

2. Stage 2. Via encrypted channel they exchange keys for IPSEC encryption.
Upon success they reach Phase 2, which is called IPSEC. isakmp daemon
put exchanged keys into kernel and kernel now can encrypt flowing traffic.

You do not need IPSEC_DEBUG because IPSEC work when it is set, kernel do
not know anything before phase 2 is reached. It may call isakmp daemon
if you would have any rules in /etc/ipsec.conf either manually installed
via setkey(8), but its not about the kernel to negotiate the other side,
its all about racoon.

> 4) What "classic" errors does one usually make in such a setup as 
> above and how can I check this? As I said - I'm sure my racoon.conf is 
> far from finished. But the fact that no response comes back (or 
> doesn't find its way back - NAT-T?) irritates me a lot.

By the way your racoon.conf have same address in psk.txt and in 
my_identifier, that obviously may not happen. my_identifier is racoon's
ID, but in psk.txt you have to put peer's address.

If you still want to try using plain IPSEC you should start from
analyzing proposal which racoon make to the other side. Show us router
configuration and be so kind to clarify the goal.

--
Sincerely yours,
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University