On 5/24/19 4:48 PM, Noel Kuntze wrote:
Hello Ben,
Any IPsec related virtual interface doesn't have any binding to any physical
interface.
You need to steer the packets using routing rules and routing tables in either
case
(whether you use virtual interfaces or not). The task only gets harder with
virtual interfaces.
When I search for strongswan and vrf, there are tantalizing hints that it can
be made to work
with recent kernels and strongswan but I don't know the details of how to set
it up or what
the limitations are.
A while back, David Ahern (VRF fellow) had this to say:
"Looking at the 'ip xfrm' based scripts, you need to add 'sel dev ${VRF}'
to the state. eg.,
VRF="sel dev blue"
ip xfrm state add src ${REMIP} dst ${MYIP} \
proto esp spi 0x02122b77 reqid 0 mode tunnel \
replay-window 4 replay-oseq 0x4 \
auth-trunc 'hmac(md5)' 0xd94fcfea65fddf21dc6e0d24a0253508 96 \
enc 'cbc(des3_ede)' 0xfc46c20f8048be9725930ff3fb07ac2a91f0347dffeacf62 \
${VRF}
"
I don't know what this is really in reference to, but evidently you can bind
the ipsec stuff to a vrf, is how I read this.
You already realized you need source based routing.
For your scenario to work, you need to disable the automatic route installation
of strongSwan.
Then you can just use normal routing rules and tables to steer the traffic over
the right link.
That sounds reasonable, but I think there is more to it than that. I could be
wrong, that
is why I'm asking for help.
Thanks,
Ben
Kind regards
Noel
Am 25.05.19 um 01:43 schrieb Ben Greear:
On 5/24/19 4:29 PM, Noel Kuntze wrote:
Hello Ben,
Why do you insist on using interfaces? You don't need any.
One thing we do is virtual wifi stations, so we want to be able to run a vpn
over each
virtual wifi station, for instance.
It can matter to the device under test whether the vpn comes from one wifi peer
or
another, so we really do need one vpn per interface.
Thanks,
Ben
Kind regards
Noel
Am 25.05.19 um 01:02 schrieb Ben Greear:
On 5/24/19 3:56 PM, Noel Kuntze wrote:
Hello Ben,
The purpose is to load test a VPN server
with a small number of physical client machines.
If the VPN server supports several CHILD_SAs and arbitrary subnets on the
remote side, you can just run several CHILD_SAs and negotiate, for example,
a CHILD_SA per client machine IP. So you'd have tunnels like ...
0.0.0.0/0 == 192.168.35.10
0.0.0.0/0 == 192.168.35.11
0.0.0.0/0 == 192.168.35.12
That will enable the usage of RSS and RPS on both ends of the tunnels, so the
IPsec SAs
can be load balanced over several CPU cores. Keep in mind though that your wire
speed
is likely not high enough to saturate a modern computer or anything even
remotely properly configured.
You can only get them to their knees by the sheer number of simultaneously
actively used IPsec SAs
by virtue of making the policy lookup more expensive and making sure that the
informations for the
used IPsec SAs don't fit into the CPU caches.
Kind regards
Noel Kuntze
Hello,
I am not so concerned with performance at this point, just functionality.
So, in the 'real' world, if I have two laptops in the same office connect
through VPN,
there will be some tunnel set up between each of them. From the perspective of
the
VPN server, I want to duplicate that but by having two interfaces on one
machine take
the place of the two laptops.
Thanks,
Ben
Am 24.05.19 um 21:46 schrieb Ben Greear:
Hello,
I'd like to be able to set up multiple (virtual) network interfaces on a single
Linux machine and have them connect to a VPN server. The VPN server should see
each connection as a unique instance. The purpose is to load test a VPN server
with a small number of physical client machines.
I know how to set up source-based routing tables and VRFs, and other general
networking things...
But, I do not know much at all about ipsec and VPNs, so I'd be happy to pay
for someone to help me out with this part of things.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
