GRE and IPsec

GRE and IPsec provide tunnel behaviour for overlay and VPN labs. netverdict models tunnel reachability, GRE encapsulation, IPsec/IKEv2 configuration, SA selection, and ESP-style protected forwarding at the behaviour level.

Support level

Area	Level	Notes
GRE tunnels	Supported	Tunnel source/destination and encapsulated IPv4 forwarding.
IPsec tunnel mode	Behaviour model	Protected traffic selectors and SA-based forwarding.
IKEv2 config	Behaviour model	Profiles, proposals, policies, keyrings, and PSK-style authentication.
ESP forwarding	Supported	ESP packet path is represented.
Crypto negotiation	Not modelled	No byte-level IKE exchange or real encryption.

Standards coverage

Standard	Coverage	Notes
RFC 2784	Behaviour model	GRE encapsulation over IPv4.
RFC 4303	Behaviour model	ESP-protected forwarding semantics.
RFC 7296	Behaviour model	IKEv2 configuration concepts, not packet negotiation.

Feature matrix

Feature	Status	Notes
Tunnel interface	Supported	Logical interface participates in routing.
Tunnel source/destination	Supported	Underlay reachability required.
GRE encapsulation	Supported	Packet path through tunnel.
Crypto ACL / selector	Supported	Defines interesting traffic.
IKEv2 proposal/policy	Config model	Stored and used by solver where relevant.
IPsec profile/transform	Supported	Associates protection with tunnel or crypto map.
PSK identity	Behaviour model	Matching peer config required in supported scenarios.
NAT-T	Not modelled	Out of scope today.

Vendor command matrix

Command	IOS-style	Junos-style	VyOS-style	Notes
`interface Tunnel0`	Supported	Partial	Partial	Tunnel interface.
`tunnel source GigabitEthernet0/0`	Supported	Partial	Partial	GRE source.
`tunnel destination 203.0.113.2`	Supported	Partial	Partial	GRE peer.
`tunnel mode gre ip`	Supported	Partial	Partial	GRE mode.
`crypto ikev2 proposal`	Supported	n/a	Partial	IKEv2 config surface.
`crypto ipsec profile`	Supported	n/a	Partial	Tunnel protection.
`show crypto ikev2 sa`	Supported	n/a	Partial	Modelled SA view.

Behaviour notes

The VPN solver answers: do the peers agree enough to form a protected path, and does selected traffic use that path? It deliberately avoids pretending to be a real cryptographic endpoint.

Examples

Canonical example

configure terminal
interface Tunnel0
 ip address 10.255.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel mode gre ip
 tunnel protection ipsec profile SITE-VPN
end
show interface Tunnel0
show crypto ikev2 sa

Vendor styles

IOS-style

interface Tunnel0
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel mode gre ip
 tunnel protection ipsec profile SITE-VPN

Junos-style

set interfaces gr-0/0/0 unit 0 tunnel source 203.0.113.1
set interfaces gr-0/0/0 unit 0 tunnel destination 203.0.113.2
set security ike gateway PEER address 203.0.113.2
set security ipsec vpn SITE bind-interface st0.0

VyOS-style

set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 source-address 203.0.113.1
set interfaces tunnel tun0 remote 203.0.113.2
set vpn ipsec site-to-site peer 203.0.113.2 authentication mode pre-shared-secret

Known limits

Real encryption, IKE packet negotiation, NAT-T, certificate validation, DPD timing, rekey races, and platform-specific crypto map order are not modelled.