Configuration for IPSec Loop-Back Test

[Christian Mauderer]

Hello,

I'm working on a port for IPSec and ipsec-tools (racoon, setkey,
libipsec) to an embedded operating system (RTEMS). RTEMS uses the
FreeBSD network stack via a compatibility layer (rtems-libbsd).

I can already create a IPSec connection on some real hardware with some
real peer. To prevent regression in a future version, I would like to
add a test that would check that the port still works. That test would
have to run on a system _without_ a real hardware peer. Therefore I
would like to create some IPSec loop back connection. In that case
racoon would have to talk to itself because I currently only support one
instance.

Do you have any hints how I could create such a network?

My current thought would be something along a virtual network device
(maybe tun?) that can be connected to some other virtual network device
via for example a bridge device. Maybe I could then try to configure two
gif-devices that would use this tunnel. racoon would have to listen on
both devices (maybe on different ports).

Currently I have trouble setting this up. Are there any simpler ideas
for an IPSec loop back connection that would use most of the stack layers?

Thanks in advance for every answer.

With kind regards

Christian Mauderer

[Alan Somers]

On Wed, Aug 1, 2018 at 7:15 AM, Christian Mauderer <

Post by Christian Mauderer
Hello,
I'm working on a port for IPSec and ipsec-tools (racoon, setkey,
libipsec) to an embedded operating system (RTEMS). RTEMS uses the
FreeBSD network stack via a compatibility layer (rtems-libbsd).
I can already create a IPSec connection on some real hardware with some
real peer. To prevent regression in a future version, I would like to
add a test that would check that the port still works. That test would
have to run on a system _without_ a real hardware peer. Therefore I
would like to create some IPSec loop back connection. In that case
racoon would have to talk to itself because I currently only support one
instance.
Do you have any hints how I could create such a network?
My current thought would be something along a virtual network device
(maybe tun?) that can be connected to some other virtual network device
via for example a bridge device. Maybe I could then try to configure two
gif-devices that would use this tunnel. racoon would have to listen on
both devices (maybe on different ports).
Currently I have trouble setting this up. Are there any simpler ideas
for an IPSec loop back connection that would use most of the stack layers?
Thanks in advance for every answer.
With kind regards
Christian Mauderer

Does RTEMS support multiple FIBs? In FreeBSD I've done this kind of thing
using multiple FIBs with tap(4) devices (though tun(4) might work for your
use case). In the FreeBSD source tree, see tests/sys/netinet/fibs_test.sh.

-Alan

[Bjoern A. Zeeb]

Post by Alan Somers
On Wed, Aug 1, 2018 at 7:15 AM, Christian Mauderer <

Post by Christian Mauderer
Hello,
I'm working on a port for IPSec and ipsec-tools (racoon, setkey,
libipsec) to an embedded operating system (RTEMS). RTEMS uses the
FreeBSD network stack via a compatibility layer (rtems-libbsd).
I can already create a IPSec connection on some real hardware with some
real peer. To prevent regression in a future version, I would like to
add a test that would check that the port still works. That test would
have to run on a system _without_ a real hardware peer. Therefore I
would like to create some IPSec loop back connection. In that case
racoon would have to talk to itself because I currently only support one
instance.
Do you have any hints how I could create such a network?
My current thought would be something along a virtual network device
(maybe tun?) that can be connected to some other virtual network device
via for example a bridge device. Maybe I could then try to configure two
gif-devices that would use this tunnel. racoon would have to listen on
both devices (maybe on different ports).
Currently I have trouble setting this up. Are there any simpler ideas
for an IPSec loop back connection that would use most of the stack layers?
Thanks in advance for every answer.
With kind regards
Christian Mauderer

Does RTEMS support multiple FIBs? In FreeBSD I've done this kind of thing
using multiple FIBs with tap(4) devices (though tun(4) might work for your
use case). In the FreeBSD source tree, see
tests/sys/netinet/fibs_test.sh.

And, on FreeBSD, I have used VIMAGE ( which I doubt you have ) though
with two vnets in two jails talking to each other or three of them with
a middle node forwarding or five of them with two clients, two security
gateways, and a forwarding node.

/bz

[Christian Mauderer]

Post by Alan Somers
On Wed, Aug 1, 2018 at 7:15 AM, Christian Mauderer <

Post by Christian Mauderer
Hello,
I'm working on a port for IPSec and ipsec-tools (racoon, setkey,
libipsec) to an embedded operating system (RTEMS). RTEMS uses the
FreeBSD network stack via a compatibility layer (rtems-libbsd).
I can already create a IPSec connection on some real hardware with some
real peer. To prevent regression in a future version, I would like to
add a test that would check that the port still works. That test would
have to run on a system _without_ a real hardware peer. Therefore I
would like to create some IPSec loop back connection. In that case
racoon would have to talk to itself because I currently only support one
instance.
Do you have any hints how I could create such a network?
My current thought would be something along a virtual network device
(maybe tun?) that can be connected to some other virtual network device
via for example a bridge device. Maybe I could then try to configure two
gif-devices that would use this tunnel. racoon would have to listen on
both devices (maybe on different ports).
Currently I have trouble setting this up. Are there any simpler ideas
for an IPSec loop back connection that would use most of the stack layers?
Thanks in advance for every answer.
With kind regards
Christian Mauderer

Does RTEMS support multiple FIBs?  In FreeBSD I've done this kind of
thing
using multiple FIBs with tap(4) devices (though tun(4) might work for your
use case).  In the FreeBSD source tree, see
tests/sys/netinet/fibs_test.sh.

And, on FreeBSD,  I have used VIMAGE ( which I doubt you have ) though
with two vnets in two jails talking to each other or three of them with
a middle node forwarding or five of them with two clients, two security
gateways, and a forwarding node.
/bz

Thanks a lot for the answers. I had a look at both suggestions:

- FIBs are currently not really implemented. Theoretically it should be
possible to add them. But it would be quite some effort and it would add
some code that is only used for the tests but would be always active.

- Regarding VIMAGE / vnets: You are right: That part is not imported.

Most likely I'll fall back to writing an example instead of an automated
test. So we can still at least make sure that everything is
compile-clean and it is possible to sometimes run the test manually.

Best regards

Christian Mauderer