On 13.05.2018 02:37, Andreas Scherrer wrote: > My interpretation of [2]'s statement: > > "If no security association is found, the packet is put on hold and the > IKE daemon is asked to negotiate an appropriate one." > > is that it should somehow be automagic. But in my current configuration, > that does not happen. I never see FreeBSD initiate any IKE traffic > (500/udp) and 'setkey -D' always reports "No SAD entries.".
Hi, You need to run racoon in debug mode and then, I think, you will see how ACQUIRE happens, and why it doesn't work. > Can anybody point me in the right direction (be it more documentation or > a working config example)? That would be awesome. Recently there was the discussion about it, and a config that worked for one tunnel was published: https://lists.freebsd.org/pipermail/freebsd-net/2018-April/050271.html You can read the entire topic to get additional info. > Best regards > andreas > > Ps.: I have tried the "old" approach which I know better using 'gif' > interfaces. With that I have managed to get racoon negotiate SAs for the > same tunnel (i.e. with libreswan on the RPi). Unfortunately I cannot > wrap my head around the routing with that approach (no 'gif' on > Raspbian). And the documentation also mentions this as a limitation of > 'gif' [3]: "you cannot usually use gif to talk with IPsec devices that > use IPsec tunnel mode" You can use gif+IPsec in transport mode from one side, and IPsec device with tunnel mode from other side. Technically this is the same. But I don't know how hard configure this using IKE. -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
