[strongSwan] Interested in ipsec with source routing and/or vrf

[Noel Kuntze]

Hello Ben,

Don't do that. It is more complex than what you need to do.
You probably /can/ bind XFRM states and policies to devices, but that's not supported
out of the box. You can restrict outgoing policies by the interface, but that's it regarding what is supported.
With 5.8.0 and newer kernels, you can use XFRM interfaces that make dealing with special routing or something
much easier than using VTIs or VRFs. Using XFRM interfaces is natively supported.

Regardless, for your task, you don't need it.

Kind regards

Noel Kuntze

Am 25.05.19 um 01:55 schrieb Ben Greear:
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190525/cb842b61/attachment-0001.sig>