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
<bsteph...@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
