Re: IKEv2/IPsec VPN
On Fri, Sep 22, 2017 at 02:21:53PM -0400, Chuck Zmudzinski wrote: > > I didn't share my patches because i was not sure NetBSD wanted to > implement RFC 3948 because it had been said a long time ago in another > place that it might be encumbered by a patent. I will post my patch for > netbsd-7 kernels on a tech-net shortly and we can discuss further over > there. The patch uses the NAT original address information from the peer > that IKE nat-t extensions provide, as described in RFC 3948. > I am a bit surprised that this didn't just work for you. I did a consult about 10 years ago where both the server and clients were behind NAT and, at the time, everything worked. I guess nobody noticed the lossage before now. One thing that did bite me when I was setting my project up was making sure the udp packets did not fragment. Some commodity grade routers don't handle UDP fragmentation well at all. The symptoms I had was the connection would come up and the client could ping the remote net fine but trying to start a remote display or something more serious would stall - the ping packets were small enough to get through but the lager packets would lose. I ended up writing a small bit of vbscript that tweaked the MTU down on the VPN interface on the client so it was low enough that, after encapsulation, the final UDP packet payload did not need to be fragmented. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: IKEv2/IPsec VPN
On 9/22/2017 2:31 PM, Gerard Lally wrote: On Fri, 22 Sep 2017, at 19:21, Chuck Zmudzinski wrote: On 9/22/2017 3:49 AM, Christos Zoulas wrote: On Sep 21, 9:18pm, frchu...@gmail.com (Chuck Zmudzinski) wrote: -- Subject: Re: IKEv2/IPsec VPN This has been fascinating so far. Sorry I haven't replied -- been tied up with hospital visits the past week. Keep at it Fr Zmudzinski -- many a breakthrough in human knowledge has been made by clerics! ;-) Thanks for the encouragement! We clerics need that as much as anyone else...
Re: IKEv2/IPsec VPN
On Fri, 22 Sep 2017, at 19:21, Chuck Zmudzinski wrote: > On 9/22/2017 3:49 AM, Christos Zoulas wrote: > > On Sep 21, 9:18pm, frchu...@gmail.com (Chuck Zmudzinski) wrote: > > -- Subject: Re: IKEv2/IPsec VPN This has been fascinating so far. Sorry I haven't replied -- been tied up with hospital visits the past week. Keep at it Fr Zmudzinski -- many a breakthrough in human knowledge has been made by clerics! ;-)
Re: IKEv2/IPsec VPN
On 9/22/2017 3:49 AM, Christos Zoulas wrote: On Sep 21, 9:18pm, frchu...@gmail.com (Chuck Zmudzinski) wrote: -- Subject: Re: IKEv2/IPsec VPN | My results show that neither 8 nor current works for the case when the | windows (or ios or android) L2TP/IPsec VPN client is not behind NAT but | NetBSD | L2TP/IPsec server is behind a NAT. In that case, my tests conclusively show | that the NetBSD kernel, not even 8 and current, implements RFC 3948 "UDP | Encapsulation of IPsec ESP packets" for the transport mode case, and | that is why | private kernel patches that implement RFC 3948 for transport mode are | necessary | for the connection to succeed in this case. I have verified this by | applying my own | private patches to the netbsd-6 and netbsd-7 kernels that implement RFC 3948 | for the transport mode case and make the connection work when the NetBSD | L2TP/IPsec server is behind a NAT. My tests also show netbsd does not | work when | both the windows, ios or android L2TP/IPsec VPN client and the netbsd | L2TP/IPsec | VPN server are behind NAT, again because of lack of implementation of | RFC 3948 | for the transport mode case in the netbsd kernel, and my test also show | that patches | to the netbsd kernel that implement RFC 3948 for the transport mode case | can fix | this for the case of both client and NetBSD server behind NAT. Well, why don't you share those patches? There is also the lack of ability to multiplex multiple IPSEC tunnels from the same NATed endpoint. Having said that, you can create a single IPSEC tunnel between two endpoints that are both NATed provided that you do all the work on the "server" side in the firewall (i.e. direct all IPSED traffic to that server). Then the client initiates and all is well. Having said that, I only tested tunnel mode. | I suspect if it was the other way around, that is, if the windows (or | ios or android) | L2TP/IPsec client is behind NAT but the NetBSD L2TP/IPsec server is NOT | behind NAT, | the connection would succeed for all stock netbsd kernels as far back as | at least | netbsd-6, as shown in the wiki tutorial page that Christos referred to | earlier in this | thread. If one looks carefully at the logs showing a successful | connection on that wiki | page, you will see that racoon reports that NAT was detected only for | the PEER, and not | for ME. For the common case of a server that is not behind a NAT, this | is sufficient | because more often than not it is the client, not the server, that is | behind NAT. | | For the case Gerard Lally is interested in, which involves substituting | an IKEv2 | IPsec solution for an OpenVPN solution in a scenario where both ends | of the secure tunnel are a NetBSD box, the question is whether or not NetBSD | can handle any issues that NAT traversal might cause. As far as I know, | OpenVPN | handles NAT traversal more readily than IPsec does. I think the stock NetBSD | kernel would work fine for IKEv2 as long as both NetBSD boxes are NOT behind | NAT, and each would use the racoon2 package for IKEv2. If one or both NetBSD | boxes are behind a NAT, then it depends on whether or not NetBSD can be | easily configured to support UDP encapsulation in tunnel mode (RFC 3948), | because the IKEv2 VPNs use tunnel mode, in contrast to the transport | mode that | L2TP/IPsec VPNs use. My tests, which are for L2TP/IPsec which uses IPsec | transport | mode, definitively show that no version of the netbsd kernel, not 8 nor | current, | nor the earlier versions, supports UDP encapsulation in transport mode, | for any | case when a NetBSD box is behind the NAT. | | Based on my reading of RFC 3948, I think it is likely a solution for the NAT | problem for IKEv2 VPNs which use tunnel mode instead of transport mode | would be easier than for the transport mode case and would probably not | require patching the kernel but would just involve setting up the | security policies | and NAT rules properly in the configuration files according to the rules | given | in RFC 3948 for tunnel mode. This could probably be accomplished using tools | provided by the racoon2 package and without patching the kernel, although I | have never tried racoon2 or IKEv2. The transport mode NAT problem is more | complicated and requires kernel patches because, as RFC 3948 observes, | the UDP checksum is invalidated by NAT for the transport mode case, and | the fix for | this needs to be done in the kernel where the UDP checksum is verified. | As far | as I can tell, all versions of netbsd fail to make the corrections to | the UDP checksum | called for in RFC 3948, for the transport mode case, and that is why | L2TP/IPsec | connections to an L2TP/IPsec NetBSD server located behind a NAT box | always fail, | no matter how hard one might try to tweak the configuration files and | security | policies. I believe that the code to fix the checksum is in HEAD, but not in -8 and that in itself is not done efficiently. christos S
Re: IKEv2/IPsec VPN
On 9/20/2017 8:48 PM, Chuck Zmudzinski wrote: > On 9/20/2017 5:12 PM, Christos Zoulas wrote: >> In article , >> Chuck Zmudzinski wrote: >>> I have used netbsd-6 and netbsd-7 with racoon to set up >>> IKEv1/L2TP/IPsec >>> VPN with Windows clients. I have not tried IKEv2 and based on the >>> little >>> research I have done I don't think it is possible using an out of >>> the box >>> NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD >>> kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and >>> I used >>> a locally modified version of the ancient and apparently no longer >>> maintained rp-l2tp package to set up l2tp tunnels. If you don't need >>> NAT >>> traversal, that is, if neither clients nor the server are behind a >>> NAT box, >>> it might be easier to do... >> In current and 8 it should work out of the box... >> >> https://wiki.netbsd.org/tutorials/how_to_create_an_l2tp_ipsec_tunnel_between_an_android_or_iphone_or_ios_device_to_netbsd/ >> >> >> >> christos > I will try 8 and current and post my result in the next few days. I > also will try racoon2 with > IKEv2 sometime with 8 and current. As I understand it, racoon2 is in > pkgsrc. It's also good > to know xl2tpd works for l2tp/ipsec. I have been planning on trying it > instead of using the > ancient rp-l2tp. > > Chuck > My results show that neither 8 nor current works for the case when the windows (or ios or android) L2TP/IPsec VPN client is not behind NAT but NetBSD L2TP/IPsec server is behind a NAT. In that case, my tests conclusively show that the NetBSD kernel, not even 8 and current, implements RFC 3948 "UDP Encapsulation of IPsec ESP packets" for the transport mode case, and that is why private kernel patches that implement RFC 3948 for transport mode are necessary for the connection to succeed in this case. I have verified this by applying my own private patches to the netbsd-6 and netbsd-7 kernels that implement RFC 3948 for the transport mode case and make the connection work when the NetBSD L2TP/IPsec server is behind a NAT. My tests also show netbsd does not work when both the windows, ios or android L2TP/IPsec VPN client and the netbsd L2TP/IPsec VPN server are behind NAT, again because of lack of implementation of RFC 3948 for the transport mode case in the netbsd kernel, and my test also show that patches to the netbsd kernel that implement RFC 3948 for the transport mode case can fix this for the case of both client and NetBSD server behind NAT. I suspect if it was the other way around, that is, if the windows (or ios or android) L2TP/IPsec client is behind NAT but the NetBSD L2TP/IPsec server is NOT behind NAT, the connection would succeed for all stock netbsd kernels as far back as at least netbsd-6, as shown in the wiki tutorial page that Christos referred to earlier in this thread. If one looks carefully at the logs showing a successful connection on that wiki page, you will see that racoon reports that NAT was detected only for the PEER, and not for ME. For the common case of a server that is not behind a NAT, this is sufficient because more often than not it is the client, not the server, that is behind NAT. For the case Gerard Lally is interested in, which involves substituting an IKEv2 IPsec solution for an OpenVPN solution in a scenario where both ends of the secure tunnel are a NetBSD box, the question is whether or not NetBSD can handle any issues that NAT traversal might cause. As far as I know, OpenVPN handles NAT traversal more readily than IPsec does. I think the stock NetBSD kernel would work fine for IKEv2 as long as both NetBSD boxes are NOT behind NAT, and each would use the racoon2 package for IKEv2. If one or both NetBSD boxes are behind a NAT, then it depends on whether or not NetBSD can be easily configured to support UDP encapsulation in tunnel mode (RFC 3948), because the IKEv2 VPNs use tunnel mode, in contrast to the transport mode that L2TP/IPsec VPNs use. My tests, which are for L2TP/IPsec which uses IPsec transport mode, definitively show that no version of the netbsd kernel, not 8 nor current, nor the earlier versions, supports UDP encapsulation in transport mode, for any case when a NetBSD box is behind the NAT. Based on my reading of RFC 3948, I think it is likely a solution for the NAT problem for IKEv2 VPNs which use tunnel mode instead of transport mode would be easier than for the transport mode case and would probably not require patching the kernel but would just involve setting up the security policies and NAT rules properly in the configuration files according to the rules given in RFC 3948 for tunnel mode. This could probably be accomplished using tools provided by the racoon2 package and without patching the kernel, although I have never tried racoon2 or IKEv2. The transport mode NAT problem is more complicated and requires kernel patches because, as RFC 3948 observes, the UDP checksum is invalidated by NAT for the tran
Re: IKEv2/IPsec VPN
On Sep 21, 9:18pm, frchu...@gmail.com (Chuck Zmudzinski) wrote: -- Subject: Re: IKEv2/IPsec VPN | My results show that neither 8 nor current works for the case when the | windows (or ios or android) L2TP/IPsec VPN client is not behind NAT but | NetBSD | L2TP/IPsec server is behind a NAT. In that case, my tests conclusively show | that the NetBSD kernel, not even 8 and current, implements RFC 3948 "UDP | Encapsulation of IPsec ESP packets" for the transport mode case, and | that is why | private kernel patches that implement RFC 3948 for transport mode are | necessary | for the connection to succeed in this case. I have verified this by | applying my own | private patches to the netbsd-6 and netbsd-7 kernels that implement RFC 3948 | for the transport mode case and make the connection work when the NetBSD | L2TP/IPsec server is behind a NAT. My tests also show netbsd does not | work when | both the windows, ios or android L2TP/IPsec VPN client and the netbsd | L2TP/IPsec | VPN server are behind NAT, again because of lack of implementation of | RFC 3948 | for the transport mode case in the netbsd kernel, and my test also show | that patches | to the netbsd kernel that implement RFC 3948 for the transport mode case | can fix | this for the case of both client and NetBSD server behind NAT. Well, why don't you share those patches? There is also the lack of ability to multiplex multiple IPSEC tunnels from the same NATed endpoint. Having said that, you can create a single IPSEC tunnel between two endpoints that are both NATed provided that you do all the work on the "server" side in the firewall (i.e. direct all IPSED traffic to that server). Then the client initiates and all is well. Having said that, I only tested tunnel mode. | I suspect if it was the other way around, that is, if the windows (or | ios or android) | L2TP/IPsec client is behind NAT but the NetBSD L2TP/IPsec server is NOT | behind NAT, | the connection would succeed for all stock netbsd kernels as far back as | at least | netbsd-6, as shown in the wiki tutorial page that Christos referred to | earlier in this | thread. If one looks carefully at the logs showing a successful | connection on that wiki | page, you will see that racoon reports that NAT was detected only for | the PEER, and not | for ME. For the common case of a server that is not behind a NAT, this | is sufficient | because more often than not it is the client, not the server, that is | behind NAT. | | For the case Gerard Lally is interested in, which involves substituting | an IKEv2 | IPsec solution for an OpenVPN solution in a scenario where both ends | of the secure tunnel are a NetBSD box, the question is whether or not NetBSD | can handle any issues that NAT traversal might cause. As far as I know, | OpenVPN | handles NAT traversal more readily than IPsec does. I think the stock NetBSD | kernel would work fine for IKEv2 as long as both NetBSD boxes are NOT behind | NAT, and each would use the racoon2 package for IKEv2. If one or both NetBSD | boxes are behind a NAT, then it depends on whether or not NetBSD can be | easily configured to support UDP encapsulation in tunnel mode (RFC 3948), | because the IKEv2 VPNs use tunnel mode, in contrast to the transport | mode that | L2TP/IPsec VPNs use. My tests, which are for L2TP/IPsec which uses IPsec | transport | mode, definitively show that no version of the netbsd kernel, not 8 nor | current, | nor the earlier versions, supports UDP encapsulation in transport mode, | for any | case when a NetBSD box is behind the NAT. | | Based on my reading of RFC 3948, I think it is likely a solution for the NAT | problem for IKEv2 VPNs which use tunnel mode instead of transport mode | would be easier than for the transport mode case and would probably not | require patching the kernel but would just involve setting up the | security policies | and NAT rules properly in the configuration files according to the rules | given | in RFC 3948 for tunnel mode. This could probably be accomplished using tools | provided by the racoon2 package and without patching the kernel, although I | have never tried racoon2 or IKEv2. The transport mode NAT problem is more | complicated and requires kernel patches because, as RFC 3948 observes, | the UDP checksum is invalidated by NAT for the transport mode case, and | the fix for | this needs to be done in the kernel where the UDP checksum is verified. | As far | as I can tell, all versions of netbsd fail to make the corrections to | the UDP checksum | called for in RFC 3948, for the transport mode case, and that is why | L2TP/IPsec | connections to an L2TP/IPsec NetBSD server located behind a NAT box | always fail, | no matter how hard one might try to tweak the configuration files and | security | policies. I believe that the code to fix the checksum is in HEAD, but not in -8 and that in itself is not done efficiently. christos
Re: IKEv2/IPsec VPN
On 9/20/2017 8:48 PM, Chuck Zmudzinski wrote: On 9/20/2017 5:12 PM, Christos Zoulas wrote: In article , Chuck Zmudzinski wrote: I have used netbsd-6 and netbsd-7 with racoon to set up IKEv1/L2TP/IPsec VPN with Windows clients. I have not tried IKEv2 and based on the little research I have done I don't think it is possible using an out of the box NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and I used a locally modified version of the ancient and apparently no longer maintained rp-l2tp package to set up l2tp tunnels. If you don't need NAT traversal, that is, if neither clients nor the server are behind a NAT box, it might be easier to do... In current and 8 it should work out of the box... https://wiki.netbsd.org/tutorials/how_to_create_an_l2tp_ipsec_tunnel_between_an_android_or_iphone_or_ios_device_to_netbsd/ christos I will try 8 and current and post my result in the next few days. I also will try racoon2 with IKEv2 sometime with 8 and current. As I understand it, racoon2 is in pkgsrc. It's also good to know xl2tpd works for l2tp/ipsec. I have been planning on trying it instead of using the ancient rp-l2tp. Chuck My results show that neither 8 nor current works for the case when the windows (or ios or android) L2TP/IPsec VPN client is not behind NAT but NetBSD L2TP/IPsec server is behind a NAT. In that case, my tests conclusively show that the NetBSD kernel, not even 8 and current, implements RFC 3948 "UDP Encapsulation of IPsec ESP packets" for the transport mode case, and that is why private kernel patches that implement RFC 3948 for transport mode are necessary for the connection to succeed in this case. I have verified this by applying my own private patches to the netbsd-6 and netbsd-7 kernels that implement RFC 3948 for the transport mode case and make the connection work when the NetBSD L2TP/IPsec server is behind a NAT. My tests also show netbsd does not work when both the windows, ios or android L2TP/IPsec VPN client and the netbsd L2TP/IPsec VPN server are behind NAT, again because of lack of implementation of RFC 3948 for the transport mode case in the netbsd kernel, and my test also show that patches to the netbsd kernel that implement RFC 3948 for the transport mode case can fix this for the case of both client and NetBSD server behind NAT. I suspect if it was the other way around, that is, if the windows (or ios or android) L2TP/IPsec client is behind NAT but the NetBSD L2TP/IPsec server is NOT behind NAT, the connection would succeed for all stock netbsd kernels as far back as at least netbsd-6, as shown in the wiki tutorial page that Christos referred to earlier in this thread. If one looks carefully at the logs showing a successful connection on that wiki page, you will see that racoon reports that NAT was detected only for the PEER, and not for ME. For the common case of a server that is not behind a NAT, this is sufficient because more often than not it is the client, not the server, that is behind NAT. For the case Gerard Lally is interested in, which involves substituting an IKEv2 IPsec solution for an OpenVPN solution in a scenario where both ends of the secure tunnel are a NetBSD box, the question is whether or not NetBSD can handle any issues that NAT traversal might cause. As far as I know, OpenVPN handles NAT traversal more readily than IPsec does. I think the stock NetBSD kernel would work fine for IKEv2 as long as both NetBSD boxes are NOT behind NAT, and each would use the racoon2 package for IKEv2. If one or both NetBSD boxes are behind a NAT, then it depends on whether or not NetBSD can be easily configured to support UDP encapsulation in tunnel mode (RFC 3948), because the IKEv2 VPNs use tunnel mode, in contrast to the transport mode that L2TP/IPsec VPNs use. My tests, which are for L2TP/IPsec which uses IPsec transport mode, definitively show that no version of the netbsd kernel, not 8 nor current, nor the earlier versions, supports UDP encapsulation in transport mode, for any case when a NetBSD box is behind the NAT. Based on my reading of RFC 3948, I think it is likely a solution for the NAT problem for IKEv2 VPNs which use tunnel mode instead of transport mode would be easier than for the transport mode case and would probably not require patching the kernel but would just involve setting up the security policies and NAT rules properly in the configuration files according to the rules given in RFC 3948 for tunnel mode. This could probably be accomplished using tools provided by the racoon2 package and without patching the kernel, although I have never tried racoon2 or IKEv2. The transport mode NAT problem is more complicated and requires kernel patches because, as RFC 3948 observes, the UDP checksum is invalidated by NAT for the transport mode case, and the fix for this needs to be done in the kernel where the UDP che
Re: IKEv2/IPsec VPN
On 9/20/2017 5:12 PM, Christos Zoulas wrote: In article , Chuck Zmudzinski wrote: I have used netbsd-6 and netbsd-7 with racoon to set up IKEv1/L2TP/IPsec VPN with Windows clients. I have not tried IKEv2 and based on the little research I have done I don't think it is possible using an out of the box NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and I used a locally modified version of the ancient and apparently no longer maintained rp-l2tp package to set up l2tp tunnels. If you don't need NAT traversal, that is, if neither clients nor the server are behind a NAT box, it might be easier to do... In current and 8 it should work out of the box... https://wiki.netbsd.org/tutorials/how_to_create_an_l2tp_ipsec_tunnel_between_an_android_or_iphone_or_ios_device_to_netbsd/ christos I will try 8 and current and post my result in the next few days. I also will try racoon2 with IKEv2 sometime with 8 and current. As I understand it, racoon2 is in pkgsrc. It's also good to know xl2tpd works for l2tp/ipsec. I have been planning on trying it instead of using the ancient rp-l2tp. Chuck
Re: IKEv2/IPsec VPN
In article , Chuck Zmudzinski wrote: >I have used netbsd-6 and netbsd-7 with racoon to set up IKEv1/L2TP/IPsec >VPN with Windows clients. I have not tried IKEv2 and based on the little >research I have done I don't think it is possible using an out of the box >NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD >kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and I used >a locally modified version of the ancient and apparently no longer >maintained rp-l2tp package to set up l2tp tunnels. If you don't need NAT >traversal, that is, if neither clients nor the server are behind a NAT box, >it might be easier to do... In current and 8 it should work out of the box... https://wiki.netbsd.org/tutorials/how_to_create_an_l2tp_ipsec_tunnel_between_an_android_or_iphone_or_ios_device_to_netbsd/ christos
Re: IKEv2/IPsec VPN
I have used netbsd-6 and netbsd-7 with racoon to set up IKEv1/L2TP/IPsec VPN with Windows clients. I have not tried IKEv2 and based on the little research I have done I don't think it is possible using an out of the box NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and I used a locally modified version of the ancient and apparently no longer maintained rp-l2tp package to set up l2tp tunnels. If you don't need NAT traversal, that is, if neither clients nor the server are behind a NAT box, it might be easier to do... Good luck finding a solution for IKEv2. If you solve it, I would be interested to know how you got it working... Chuck Zmudzinski On 9/19/2017 5:49 PM, Gerard Lally wrote: Some years ago I successfully set up netbsd-6 OpenVPN endpoints, with 20-30 remote Windows clients connecting. I'd now like to set up a netbsd-8 VPN, based on IKEv2/IPsec. The documentation doesn't make it clear -- to me -- if such a setup is possible. Ideally it would be nice if strongSwan was supported on NetBSD but it seems this is not the case. So where to begin? Does racoon support IKEv2? At one stage there was a racoon2 fork but development seems to have stalled on that. If you run such a setup some ideas to kickstart my reading would be welcome. Thank you.
Re: IKEv2/IPsec VPN
In article <1505857797.1933676.680920.129e4...@webmail.messagingengine.com>, Gerard Lally wrote: >Some years ago I successfully set up netbsd-6 OpenVPN endpoints, with >20-30 remote Windows clients connecting. > >I'd now like to set up a netbsd-8 VPN, based on IKEv2/IPsec. The >documentation doesn't make it clear -- to me -- if such a setup is >possible. Ideally it would be nice if strongSwan was supported on NetBSD >but it seems this is not the case. So where to begin? Does racoon >support IKEv2? At one stage there was a racoon2 fork but development >seems to have stalled on that. > >If you run such a setup some ideas to kickstart my reading would be >welcome. Thank you. It would be interesting to download and use racoon2 and see if that works... christos
IKEv2/IPsec VPN
Some years ago I successfully set up netbsd-6 OpenVPN endpoints, with 20-30 remote Windows clients connecting. I'd now like to set up a netbsd-8 VPN, based on IKEv2/IPsec. The documentation doesn't make it clear -- to me -- if such a setup is possible. Ideally it would be nice if strongSwan was supported on NetBSD but it seems this is not the case. So where to begin? Does racoon support IKEv2? At one stage there was a racoon2 fork but development seems to have stalled on that. If you run such a setup some ideas to kickstart my reading would be welcome. Thank you.
IKEv2/IPsec VPN
Some years ago I successfully set up netbsd-6 OpenVPN endpoints, with 20-30 remote Windows clients connecting. I'd now like to set up a netbsd-8 VPN, based on IKEv2/IPsec. The documentation doesn't make it clear -- to me -- if such a setup is possible. Ideally it would be nice if strongSwan was supported on NetBSD but it seems this is not the case. So where to begin? Does racoon support IKEv2? At one stage there was a racoon2 fork but development seems to have stalled on that. If you run such a setup some ideas to kickstart my reading would be welcome. Thank you.
