The tunnel table is used to configure and monitor VPN
tunnels. There two cases here: site-to-site and remote
dial-in. For site-to-site VPN the entry in the tunnel table
must be configured. There are two types of tunnels: static
tunnels and dynamic tunnels. When dynamic tunnels are
configured and become operational, the ISAKMP protocol
creates an SA pair, one inbound and one outbound.
When static tunnels are configured, inbound and outbound
SAa need to be created through network management. In this
case key and peer SPI (security profile index) must be set.
Static SAs are like ATM PVCs. Dynamic SAs are like ATM SVCs.
All dial-in clients are organized into user groups. One or
more users (dial-in clients) may be in the group. All dial-in
users that are members of the same group get the same security
attributes. Actual users may be either configured internally
(in the ipsecRemoteClient table) or in the external database
such as X.500 directory or Radius, etc. The administrator has
an option of defining a Default group. Users that do not have
any User group membership are assigned into a Default group.
For remote dial-in VPNs, the tunnel entries are first
statically configured for every defined user group, for
example AcessPointEng, etc. Tunnels for individual users in
the group are created automatically when user of the group
initiates a connection. These automatically created remote
client tunnels are 'children' of a statically configured
'parent' user group tunnel. The name of automatically created
dial-in tunnel (which must be unique) is constructed as
follows: tunnelName.userName, for example
AccessPointEng.ebomarsi.
For site-to-site and dial-in-group tunnel VPNs the objects'
access is as specified. For dial-in 'children' tunnel VPNs which
are automatically created by the system, all objects are
read-only except for ipsecTunnelAdminStatus. This object has
write access and when set to down, it would result in tearing
down user dial-in session, i.e. all security associations for
this dial-in client will be deleted.
Parsed from file ipsec.mi2.txt
Company: None
Module: XEDIA-IPSEC-MIB
The tunnel table is used to configure and monitor VPN
tunnels. There two cases here: site-to-site and remote
dial-in. For site-to-site VPN the entry in the tunnel table
must be configured. There are two types of tunnels: static
tunnels and dynamic tunnels. When dynamic tunnels are
configured and become operational, the ISAKMP protocol
creates an SA pair, one inbound and one outbound.
When static tunnels are configured, inbound and outbound
SAa need to be created through network management. In this
case key and peer SPI (security profile index) must be set.
Static SAs are like ATM PVCs. Dynamic SAs are like ATM SVCs.
All dial-in clients are organized into user groups. One or
more users (dial-in clients) may be in the group. All dial-in
users that are members of the same group get the same security
attributes. Actual users may be either configured internally
(in the ipsecRemoteClient table) or in the external database
such as X.500 directory or Radius, etc. The administrator has
an option of defining a Default group. Users that do not have
any User group membership are assigned into a Default group.
For remote dial-in VPNs, the tunnel entries are first
statically configured for every defined user group, for
example XediaEngineering, etc. Tunnels for individual users in
the group are created automatically when user of the group
initiates a connection. These automatically created remote
client tunnels are 'children' of a statically configured
'parent' user group tunnel. The name of automatically created
dial-in tunnel (which must be unique) is constructed as
follows: tunnelName.userName, for example
XediaEngineering.schwartz.
For site-to-site and dial-in-group tunnel VPNs the objects'
access is as specified. For dial-in 'children' tunnel VPNs which
are automatically created by the system, all objects are
read-only except for ipsecTunnelAdminStatus. This object has
write access and when set to down, it would result in tearing
down user dial-in session, i.e. all security associations for
this dial-in client will be deleted.
Parsed from file XEDIA-IPSEC-MIB.mib
Module: XEDIA-IPSEC-MIB
Vendor: Lucent
Module: XEDIA-IPSEC-MIB (ipsec.mi2)
Type: TABLE
Access: not-accessible
Syntax: SEQUENCE OF
Automatically extracted from www.mibdepot.com
ipsecTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The tunnel table is used to configure and monitor VPN tunnels. There two cases here: site-to-site and remote dial-in. For site-to-site VPN the entry in the tunnel table must be configured. There are two types of tunnels: static tunnels and dynamic tunnels. When dynamic tunnels are configured and become operational, the ISAKMP protocol creates an SA pair, one inbound and one outbound. When static tunnels are configured, inbound and outbound SAa need to be created through network management. In this case key and peer SPI (security profile index) must be set. Static SAs are like ATM PVCs. Dynamic SAs are like ATM SVCs. All dial-in clients are organized into user groups. One or more users (dial-in clients) may be in the group. All dial-in users that are members of the same group get the same security attributes. Actual users may be either configured internally (in the ipsecRemoteClient table) or in the external database such as X.500 directory or Radius, etc. The administrator has an option of defining a Default group. Users that do not have any User group membership are assigned into a Default group. For remote dial-in VPNs, the tunnel entries are first statically configured for every defined user group, for example AcessPointEng, etc. Tunnels for individual users in the group are created automatically when user of the group initiates a connection. These automatically created remote client tunnels are 'children' of a statically configured 'parent' user group tunnel. The name of automatically created dial-in tunnel (which must be unique) is constructed as follows: tunnelName.userName, for example AccessPointEng.ebomarsi. For site-to-site and dial-in-group tunnel VPNs the objects' access is as specified. For dial-in 'children' tunnel VPNs which are automatically created by the system, all objects are read-only except for ipsecTunnelAdminStatus. This object has write access and when set to down, it would result in tearing down user dial-in session, i.e. all security associations for this dial-in client will be deleted." ::= { ipsecObjects 4 }
ipsecTunnelTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecTunnelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The tunnel table is used to configure and monitor VPN tunnels. There two cases here: site-to-site and remote dial-in. For site-to-site VPN the entry in the tunnel table must be configured. There are two types of tunnels: static tunnels and dynamic tunnels. When dynamic tunnels are configured and become operational, the ISAKMP protocol creates an SA pair, one inbound and one outbound. When static tunnels are configured, inbound and outbound SAa need to be created through network management. In this case key and peer SPI (security profile index) must be set. Static SAs are like ATM PVCs. Dynamic SAs are like ATM SVCs. All dial-in clients are organized into user groups. One or more users (dial-in clients) may be in the group. All dial-in users that are members of the same group get the same security attributes. Actual users may be either configured internally (in the ipsecRemoteClient table) or in the external database such as X.500 directory or Radius, etc. The administrator has an option of defining a Default group. Users that do not have any User group membership are assigned into a Default group. For remote dial-in VPNs, the tunnel entries are first statically configured for every defined user group, for example XediaEngineering, etc. Tunnels for individual users in the group are created automatically when user of the group initiates a connection. These automatically created remote client tunnels are 'children' of a statically configured 'parent' user group tunnel. The name of automatically created dial-in tunnel (which must be unique) is constructed as follows: tunnelName.userName, for example XediaEngineering.schwartz. For site-to-site and dial-in-group tunnel VPNs the objects' access is as specified. For dial-in 'children' tunnel VPNs which are automatically created by the system, all objects are read-only except for ipsecTunnelAdminStatus. This object has write access and when set to down, it would result in tearing down user dial-in session, i.e. all security associations for this dial-in client will be deleted." ::= { ipsecObjects 4 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.838.3.14.1.4.1 | ipsecTunnelEntry | 31 | 31 | Information about a tunnel. Tunnels are manually created using the ipsecTunnelRowStatus object. |
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.838.3.14.1.1 | ipsecSubsystemGroup | 2 | 4 | None |
| 1.3.6.1.4.1.838.3.14.1.2 | ipsecSecurityProfileTable | 1 | 13 | This table defines a set of security attributes that will be used to describe a security association (SA). There may be many SAs … |
| 1.3.6.1.4.1.838.3.14.1.3 | ipsecIfTable | 1 | 23 | ipsecIftable |
| 1.3.6.1.4.1.838.3.14.1.5 | ipsecSaTable | 1 | 12 | Tunnel Security Association (SA) table. Each entry in the table is a Security Association. SA's are associated with a single IPS… |
| 1.3.6.1.4.1.838.3.14.1.6 | ipsecTransportIfTable | 1 | 25 | ipsecTransportIftable |
| 1.3.6.1.4.1.838.3.14.1.7 | ipsecTransportTable | 1 | 30 | Information associated with an IPSec Transport. |
| 1.3.6.1.4.1.838.3.14.1.8 | ipsecTransportSaTable | 1 | 11 | Transport Security Association (SA) table. Each entry in the table is a Security Association. SA's are associated with a single … |