On 10/2/24 12:11, Boyd Stephens wrote:
> On 9/28/24 04:10, Janne Johansson wrote:
>> Den fre 27 sep. 2024 kl 20:05 skrev Boyd Stephens
>> <bstephens@netelysis.com>:
>>>
>>> I desired to destroy and recreate enc0 but if memory serves me correctly
>>> the enc0 interface always exists and cannot be destroyed using ifconfig.
>>> I have inferred from this(and possibly incorrectly) that the only way
>>> to destroy and reestablish enc0 is through a reboot.
>>
>> Sorry that this is not helping you solve your particular issue, but I
>> noticed this part above.
>> You make it sound like (not trying to put words in your mouth, only
>> how I perceived it) as if enc0 relates to an ipsec tunnel as for
>> instance a tun or tap device relates to say an OpenVPN tunnel. It does
>> not.
>>
>> The enc0 interface exists so that when traffic gets decapsulated on
>> the way in, it has to "come" from somewhere. The actual physical
>> interface on where the AH/ESP packet arrived on is not interesting
>> (anymore) after decryption, so if you want to filter with pf or
>> tcpdump, you need an interface to refer to for the cleartext traffic.
>> Same goes for outwards traffic of course, it gets fed "into" enc0 and
>> after encryption it will exit via some other interface.
>>
>> Now, if you only run a simple setup with one ipsec flow/sa, it might
>> feel like it is "the same" as openvpn/tun with one tunnel and one
>> special-interface but if you set up more than one ipsec, you still see
>> all encapsulated traffic pass via enc0, whereas on openvpn tunnels you
>> would set up one tun/tap for each tunnel.
>>
>> So what this means is that the enc0 is rather a special meta-device
>> for all cleartext ipsec traffic and you should really not need to
>> think about destroying and re-creating it in the same sense as if it
>> was openvpn+tun0 or wireguard + wg0 or something like that. At least
>> not for clearing configs.
>>
>> Perhaps I have misunderstood your "mistake" here and then my message
>> might at least help someone else understand enc0 slightly better, and
>> regardless of if this helps you understand it better or not I hope
>> your problem gets solved without needing reboots to "clear" the
>> interface, since that should really not be necessary.
>>
>
> Janne,
>
> Thank you for your response.
>
> I cannot say that what you shared was the line of thinking that
> possessed me in my previous correspondence but I AM SURELY GLAD that you
> possibly THOUGHT that my analysis path was in this particular space.
>
> Your feedback and input is full of a number of technical jewels that I
> genuinely found, and I am sure others will find, helpful.
>
> The content especially resonates with our small team due to the fact
> that one of our largest customer's wan deployment heavily leans on the
> openvpn platform thus we have a tad-bit of a familiarity with that
> particular technology's inner workings.
>
> Concerning the original issue, earlier in the day I believe that we may
> have turned a corner in finding a resolution. Once our team is able to
> test out the validity of the solution I will look to post the details of
> our findings to this thread.
>
> Thanks again for sharing your insight.
>
> ------
> Bro Boyd
> I85Cyber.org
>
>
Looking further into this issue and after observing a couple weeks of
data it seems that what is happening within our current VPN setup is
that the IKEv2 connection successfully establishes itself but things
begin to malfunction around the time that the childsa lifetime expires.
After more searching of the openbsd-misc mailing list I found the
content of the particular thread here
- https://marc.info/?l=openbsd-misc&m=161170661504257&w
somewhat helpful.
At the present time the configuration settings are representative of PFS
being disabled.
Under the iked.conf man page it states
"The group option will only be used to enable Perfect Forward Secrecy
(PFS) for additional Child SAs exchanges that are not part of the
initial key exchange."
Am I reading this incorrectly when I interpret this to say that the
existence of no group value for the childsa in the iked.conf file
"disables" PFS?
A comment that is mentioned in the openbsd-misc thread has me somewhat
intrigued, if it is true. Within the third post of the thread Mr
Spruell states
"I recall now having seen this and not understood it at the time:
'For IKEv2 the keys for the first CHILD_SA, created implicitly with
the IKE_SA, will always be derived from the IKE_SA's key material. So
any DH group set here only applies when the CHILD_SA is later rekeyed
or created with a CREATE_CHILD_SA exchange on an existing IKE_SA. A
proposal mismatch may, therefore, not immediately be detected when the
SA is established, but may later cause rekeying to fail.'"
He does not reference the source of this quote are these statements
true. I am curious to ascertain whether these statements are true?
------
Boyd Stephens
I85Cyber.org
No comments:
Post a Comment