Re: racoon, IKEv1 and multiple ipsec clients behind NAT

["Mathew, Cherry G." <c%bow.st@localhost>]

On October 22, 2022 8:57:04 PM UTC, Gert Doering <gert%greenie.muc.de@localhost> wrote:
>Hi,
>
>On Sat, Oct 22, 2022 at 08:09:15PM +0000, Mathew, Cherry G. wrote:
>> >It does :-) - look into --dev tap, which will provide virtual ethernet
>> >interfaces.  These can then be bridge(4)ed together.
>> 
>> So I remember now why I had dropped OpenVPN 'dev tap' originally
>> - couldn't get TAP to work on NetBSD - the tap device claims "no
>> carrrier" - but attempting to open this corresponding Dev node
>> fails. Was there any special magic other than removing the "ifconfig"
>> line ?
>
>I haven't tried combining bridge(4), tap(4) and openvpn together in
>NetBSD, so I'm not sure if that causes new and interesting caveats.
>
>"Plain tap" is part of our openvpn CI suite on NetBSD - so that should
>work just fine.
>
>From what I just read in the manpage, it *should* work like this
>
> - create a bridge with "ifconfig create bridge0" (?)
> - create a tap interface with "ifconfig create tap0"
> - bridge them together with "brconfig"
>    brconfig bridge0 add tap0
>    brconfig bridge0 add ethernet0 << whatever the device iL

Just to clarify, this is for the local LAN to bridge to the remote one, yes ?

> - put the LAN IP config on "bridge0"

NetBSD abstracts (rightly, IMO) bridge devices as non L3 routing. So if that is what you meant then there's the extra steps of 'ifconfig vether0 create;brconfig bridge0 add vether0' followed by assigning vether0 an IP I'm guessing ?

> - run OpenVPN with "--dev tap0" (not "dev tap", which will create
>   the "next free one"), so it will use the already existing tap0
>
>

Aha! I need to test for this. Is there a way to do this within the rc.d service framework ? openvpn_args= such and such ?

>> >Normally you'd not use that for road warrier access type - you'd just
>> >designed a second IP segment for "this is VPN" and setup routing on
>> >all boxes involved to move packets back and forward how you need them.
>> 
>> I'm facing a separate problem - severe throughput loss (I get about 10% of either segment individually - what connects them is an npf(4) NAT.  Will MTU be a factor for this kind of traffic path ? What's a recommended size for non fragmenting transmission ? 1500octets ?

>
>You'll end up with fragmentation at some point, until you can manage to
>get your LAN MTU below WAN - tunneling overhead.  Sometimes, WAN with
>>1500 can be made to work, or you do mssfix to ensure TCP will use
>small-enough packets.
>

Ok thanks - I'll work upwards from about 500 in that case.

Many thanks!