On 9/25/24 04:14, Stuart Henderson wrote:
> On 2024-09-25, Boyd Stephens <bstephens@netelysis.com> wrote:
>> The circumstances driving this inquiry is that our team has an IKEv2 vpn
>> connection where the tunnel between two sites is always successfully
>> established (at least this is the feedback from all of our ipsecctl -s
>> all inquiries) but traffic flow across the enc0 interface occurs very
>> intermittently and some times not at all. The remote end of the tunnel
>> is operating across a Cisco ASA 5550 appliance.
> ..
>> Again, at times traffic will flow across enc0 flawlessly but in those
>> circumstances after the ikelifetime(IKE SA expiration) expires the ipsec
>> link will be reestablish but traffic will cease to flow across enc0.
>
> That sounds like initial SAs are negotiated OK but there's an issue with
> child SAs. I've had that happen quite a lot with Windows ikev2 where it
> was unhappy about dh groups.
>
> iked.conf and (if available) the cisco config might give clues, as might
> logs (warnings logs on the cisco side probably most helpful, I find iked
> logs are usualy either not enough or excruciatingly noisy depending on
> verbosity).
>
Mr Stuart,
Thank you for the feedback. I do not have an additional piece of data.
It seems that the encrypted tunnel/IPSec will only reestablish itself
through a reboot of the entire system. The current data set that we
have been able to track is that flushing the SPD/SAD and/or shutting
down and restarting the iked daemon will not reestablish the encrypted
tunnel.
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.
Is my line of thinking in the right ballpark and was this similar to the
circumstances that you describe above?
Am looking into gaining access to the cisco config and the warning logs
on the cisco side of the link.
- Boyd Stephens
I85Cyber.org
No comments:
Post a Comment