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.
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. 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 >>>>> >>>> >>> >>> >> > >
signature.asc
Description: OpenPGP digital signature
