Changing ACLs and creating VPN configuration

nbs

I'm evaluating NCM for a requirement to manage ACLs and migrate VPN devices from one VPN head end FW to a new site, I believe that NCM can do this however I'm hitting a few roadblocks in my knowledge to prove this;

For example;

(IP addresses are bogus)

Our VPN head end firewall at the main office  is 94.23.231.89, our VPN head end firewall at the London site 34.201.33.101

Node details

Public IP address 82.34.231.99

VLAN 1 IP address 10.130.5.1

Node network variable has to be 10.130.5.0

NCM would need to connect via it's WAN address, 82.34.231.99, as the three ACLs and the VPN configuration it has to change will kill the VPN connection.

As it’s changing the VPN configuration it cannot use the node's VLAN1 IP address 10.130.5.1 as this WILL become unavailable, however it needs to know the VLAN1 IP address to create the Node network variable

To complicate matters, we use 3 different VPN devices for our estate, PIX 501, ASA 5505 and 881G routers (all cisco products), PIX 501 and ASA's refer to VLAN1 as “inside” whilst the 881G routers use VLAN1, so I suspect I will need at least two templates.

As I see it, NCM connects to the device using it's WAN IP address, enumerates the interfaces to find the interface with name/desc including VLAN1 / Inside, finds the right interface and creates the node network ( i.e setoctect(<node vlan1 ip address>, 4, 0) variable to use in building the ACLs.

Template then wipes the 3 ACLs and rebuilds them, and then adds the VPN config. It would be up to the analyst running the template to then change routing within our network (as I guess that a CCT cannot work on one node, then update our core route to change the routes).

What I am not sure on is the macro variables I need to look at, I've read the template on setting VLAN attributes via interface description but not sure how this translates to pulling the IP address of the right interface out.

Thanks in advance for any assistance

Nigel

nbs

No problem, sorry for the delay oddly enough things have been a bit hectic since the evaluation was succesful Thanks to Solarwinds Support for the help with this;

One gotcha is, for some reason the NCM scheduled tasks had not run, so the inventory task against the node had not pulled back the details about teh interfaces on the node and the script was failing as NCM had no record of the VLAN1 interface, the solution was to run an inventory manually and ensure the scheduled task setup to run over night was enabled.

To run an inventory manually, log onto the NCM web portal, goto 'Configs - Inventory', under inventory reports select "interfaces" and then click 'Update Inventory'

The following script requests an IP address from the user, then uses that to build a route statement to the script;

script BaseChangeTemplate(NCM.Nodes @ContextNode, string @ADSL_Router)

{

    string @newVlanIP = '' //changed

    foreach (@interfaceItem in @ContextNode.Interfaces)

    {

     if (@interfaceItem.InterfaceDescription contains 'VLAN1')

     {

         foreach(@ip in @interfaceItem.IpAddresses)

         {

             @newVlanIP = setoctet(@ip.IPAddress,4,0)

         }

      }

  }

if(@newVlanIP != '') // added it

{

    CLI

    {

      conf t

      no access-list 100

      access-list 100 deny   ip @newVlanIP 0.0.0.255 192.168.1.0 0.0.0.255

      access-list 100 permit ip @newVlanIP 0.0.0.255 any

      !

      no access-list 105

      access-list 105 permit ip @newVlanIP 0.0.0.255 192.168.1.0 0.0.0.255

      !

      no access-list 104

      access-list 104 permit ip @newVlanIP 0.0.0.255 host 8.8.8.8

      access-list 104 deny ip any any

      !

      ip route 9.9.9.9 255.255.255.255 @ADSL_Router

      !

      snmp-server  contact V0.6

      exit

    }

  }

}

If VLAN 1 IP address is 192.168.1.18 and the user inputted 82.82.82.82 as the router address the above script would generate;

      conf t

      no access-list 100

      access-list 100 deny   ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255

      access-list 100 permit ip 192.168.1.0 0.0.0.255 any

      !

      no access-list 105

      access-list 105 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255

      !

      no access-list 104

      access-list 104 permit ip 192.168.1.0 0.0.0.255 host 8.8.8.8

      access-list 104 deny ip any any

      !

      ip route 9.9.9.9 255.255.255.255 82.82.82.82

      !

      snmp-server  contact V0.6

      exit

I suspect the script would fail if an interface had more than one IP address however for the devices this script is used again't this is not an issue as that interface has no secondary IP addresses.