Repository navigation
ASIM Meraki: should site-to-site VPN lifecycle events be normalized as NetworkSession? #15249
Description
I’d like to discuss whether site-to-site VPN lifecycle events within the current Meraki AuditEvent parser such as IPsec/ISAKMP association establishment, deletion, and negotiation failures might fit ASIM NetworkSession more closely than AuditEvent. Where appropriate, establishment and teardown could use EventSubType=Start and End.
There are some related precedents. The Cisco ASA NetworkSession parser handles connection start/end records, including connections terminated because a tunnel went down, using Invalid Tunnel. The AppGate SDP parser normalizes network-access events from its VPN daemon as NetworkSession even when the source labels them [AUDIT]. Conversely, GlobalProtect login/logout and authentication-related events are normalized under Authentication, illustrating that the appropriate schema depends on the operation being reported.
Before proposing changes, could maintainers clarify whether AuditEvent is intentional for these Meraki VPN lifecycle events, and what boundary is intended between AuditEvent, NetworkSession, and Authentication?
There are some other events sprinkled in the Meraki Parser that also cause me some confusion:
- Port changes from 100fdx to down ( this one is just link loss not necessarily someone turned it off )
- VRRP passive becomes active because packets weren’t received ( A standby becoming active after missing VRRP advertisements is expected failover behaviour its just a response to something and not n administrative action)
Are we expected to use AuditEvent for Operational state changes, If so, what mappings are recommended for the affected interface/resource and its old/new state, maybe the object field?
Activity
yummyblabla commentedon Oct 7, 2026
Hi Paul Wiper (@wiperpaul) .
From what you described, AuditEvent is indeed for operational state changes. For example, deleting an ISAKMP-SA should be a delete operation as described in Cisco Meraki parser and establishing an ISAKMP-SA is a create operation. I can see the argument for it being a NetworkSession event, but if the actual event is an administrator acting on this operational changes instead of accessing another device through ISAKMP-SA, then it would be an AuditEvent as opposed to NetworkSession. The distinction between AuditEvent and NetworkSession in this case is the presence of a destination device.
For example, if someone changes the port from 1000 to 22, then OldValue would be 1000, NewValue is 22, and Object is whatever Id that we can associate to the resource, PortId, FirewallId, etc.
yummyblabla commentedon Oct 7, 2026
As for boundary between NetworkSession and Authentication, the boundary does seem blurry, but I would say that if the log is explicit about the event being logging in/out, then it is Authentication. Otherwise, it should be NetworkSession.
wiperpaul commentedon Oct 10, 2026
Derrick Lee (@yummyblabla)
Thanks Derrick for feedback, like for your ASIM agent I have been messing around with classification/normalisation using agents and decision agents and these kind of distinctions are necessary.