Hello Dima,thank you for your answer. One thing first - I think I underestimated the complexity of an IPSEC setup like this. It has too many components in which I only have a half-knowledge yet.
Am 08.06.21 um 12:05 schrieb Dima Veselov:
On Tue, Jun 08, 2021 at 10:04:44AM +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?
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.
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.
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:version:4 n:network-ike-port:500 n:network-mtu-size:1380 n:client-addr-auto:1 n:network-natt-port:4500 n:network-natt-rate:15 n:network-frag-size:540 n:network-dpd-enable:1 n:client-banner-enable:1 n:network-notify-enable:1 n:client-dns-used:1 n:client-dns-auto:0 n:client-dns-suffix-auto:1 n:client-splitdns-used:1 n:client-splitdns-auto:1 n:client-wins-used:1 n:client-wins-auto:1 n:phase1-dhgroup:2 n:phase1-life-secs:86400 n:phase1-life-kbytes:0 n:vendor-chkpt-enable: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:client-auto-mode:pull s:client-iface:virtual s:network-natt-mode:enable s:network-frag-mode:enable s:client-dns-addr:192.168.111.1 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 s:policy-level:auto ```
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.
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?
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'sID, 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.
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.
Kind regards Matthias
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature