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 Thu, Jun 10, 2021 at 02:41:23PM +0200, Matthias Petermann wrote:

> > 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.
>
> You are absolutely right - I completely ignored that part. And now I 
> think I understand that it is essential. That is, if I have not 
> misunderstood, Racoon in its role as key manager does nothing other 
> than distribute the keys between the hosts and configure IPSec via 
> setkey so that the traffic is encrypted with these keys?

Yes, that's right, IPSEC is fast symmetric packet encryption done
by the kernel, racoon does high security non-symmetric key exchange and
encryption (ISAKMP or IKE) to keep IPSEC keys safe. This combination
make ISAKMP/IPSEC fast and safe on all stages.

> I have always preferred OpenVPN in the past because I understood the 
> setup there :-) This time IPSEC is actually set, because the remote 
> station (FritzBox) is an appliance for which OpenVPN is not available 
> as an option. I had let myself be guided by the fact that the 
> connection setup with the Shrew Soft VPN Client was quite easy - but 
> obviously this client also hides a lot of small-scale negotiations 
> with the endpoint from the user.

I am not sure you can do better setup than OpenVPN but we can give
it a try. That explanation make your goal client-server VPN, which
clarify things a bit.

> > We have to know what specification router do expect. It should have
> > some configured options to look at.
> I thought I had listed the specification of the router (Fritzbox 7490) 
> in my original email. The admin interface of the router does not show 
> me any further information. It is also more of a consumer hardware 
> that is trimmed for simplicity on the surface.
>
> On the other hand - if I export the working client configuration of 
> the Shrew Soft Client and open it in a text editor, it reveals hardly 
> anything special - many parameters are set to "auto" there:
>
> n:network-natt-port:4500
> n:phase1-dhgroup:2
> n:phase1-life-secs:86400
> n:phase1-life-kbytes:0
> n:phase2-life-secs:3600
> n:phase2-life-kbytes:0
> n:policy-nailed:0
> n:policy-list-auto:1
> s:network-host:vpn.example.com
> s:auth-method:mutual-psk-xauth
> s:ident-client-type:keyid
> s:ident-server-type:address
> s:ident-client-data:user
> b:auth-mutual-psk:xxxxxxxxxxxxxxxxxx==
> s:phase1-exchange:aggressive
> s:phase1-cipher:auto
> s:phase1-hash:auto
> s:phase2-transform:auto
> s:phase2-hmac:auto
> s:ipcomp-transform:disabled
> n:phase2-pfsgroup:-1

That looks relevant.

> Does this mean that the fact that my Racoon does not get an answer 
> from the remote station has nothing to do with IPSEC, but is a pure 
> UDP-over-NAT issue? And possibly not even that - if I understand 
> correctly, one reason for the non-response of the remote station may 
> be that the proposal of my racoon is inappropriate or invalid?

That can be either. But it is the first thing you should try.
ISAKMP port 500 is expected to have source port 500 and it is
impossible, so you have to force racoon use NAT-T 4500 from the
very beginning. Not sure why your "natt force" is not working.
It can be not compiled in (check logs) or it may be not used
because of no IPSEC. I suggest creating loose spec in /etc/ipsec.conf
and specifying host in racoon.conf instead of anonymous.

> > 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.
>
> I will work on that - in any case, you have helped me a lot with the 
> explanations. I think I first have to fill in gaps in my knowledge and 
> try to recapitulate what I have already done.
>
> As far as the goal is concerned, I can say that I want to connect a 
> local network to a remote network via a NetBSD router using VPN. 
> NetBSD seems to me to be suitable for this because it already has 
> everything necessary in the basic system.

Its okay if you keep in mind that you will have to use some other
stuff like ppp or l2tp as a transport layer and will have to use
NAT on NetBSD because client-server VPN is not loyal to foreign
networks.

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