Tuesday, December 13, 2016

Python and NETCONF to manage HP Comware 7

Enterprise networking is evolving and much of it is heading toward automation. One thing I have been coming across regularly is the utilization of API and scripts to assist in building networks. One of the vendors, HP, in Comware 7 allows users to manage their platform utilizing NETCONF protocol.

There is a fair amount of documentation on HP NETCONF; but here is a basic example of how to read a hostname and then modify it utilizing Python and NETCONF

 

NETCONF servers needs to enable on the HP switch and can be done with the following command:

 

netconf ssh server enable 

 

port 830 is the default port it will communicate through.

 

Once this is enabled (and a user account), you can read and write to the device

 

The module used in Python 2.7 is called ncclient and can be installed via PIP install. Here is my output from the interactive shell:

 

 

from ncclient import manager

 

Define the XML path of the information you need to obtain

 

filterget = '<top xmlns="http://www.hp.com/netconf/data:1.0"><Device><Base><HostName></HostName></Base></Device></top>'

 

Build the connection to the device with the data

 

sodarocks = manager.connect(host='192.168.11.15',port=830,username='admin',password='admin',hostkey_verify=False,allow_agent=False,look_for_keys=False, device_params={'name':'hpcomware'})

 

>>> sodarocks.get(('subtree', filterget))

 

The return value will be string in XML format

 

<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns:config="http://www.hp.com/netconf/config:1.0" xmlns:data="http://www.hp.com/netconf/data:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:4486954e-2142-4896-a977-b66a294f4fec"><data><top xmlns="http://www.hp.com/netconf/data:1.0"><Device><Base><HostName>sodas5900</HostName></Base></Device></top></data></rpc-reply>

 

This return value can help you determine the path you need to modify to correct the XML string, in my case, I am looking to change the hostname

 

I will create a new filter with the modifications I want to the hostname:

 

filterchange = '<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><top xmlns="http://www.hp.com/netconf/config:1.0"><Device><Base><HostName>notsodas5900</HostName></Base></Device></top></config>'

 

Then execute the modification using the new filter and the type of operation performed:

 

sodarocks.edit_config(target='running', config=filterchange, default_operation='replace')

 

You should get an rpc ok

 

>>> sodarocks.edit_config(target='running', config=filterchange, default_operation='replace')

 

<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns:config="http://www.hp.com/netconf/config:1.0" xmlns:data="http://www.hp.com/netconf/data:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:03b4f996-d025-4aa7-be5e-782d0a4ffed3"><ok/></rpc-reply>

 

Some additional resources you can look at the is the API documentation that comes with each release of Comware from HP support site and the ncclient reference on github.

 

Wednesday, September 28, 2016

Setting up Windows Server 2008 R2 RADIUS authentication with Juniper SRX

Under Windows Network Policy Server (NPS)

Create a shared secret template, name it SRXpassword or something and make a password.

Create a new network policy and name it, leave the network access server unspecified

 

Click next and select the Windows Group and select the group(s) you want to access the device.

Click next and select access granted

For the type of encryption, click add, select MS-CHAPv2

Do not change anything under the constraint page and click next.

Remove everything from the Standard RADIUS attributes and select the vendor specific type. Click add and select vendor specific

Enter the Juniper vendor code 2636 and click yes it conforms

Put in the vendor-assigned attribute number 1 and select string as the attribute format and type in su

 

Click OK to close it and back to the menu select the encryption type. Uncheck everything except strongest encryption and click next and finished.

 

Create the new RADIUS client and populate the information of your firewall. Select the share secret template you create earlier.

 

On the Juniper SRX Firewall

 

Type in the following and fill in your server IP and password.

set system authentication-order [ password radius ]

set system radius-server 192.168.1.2 secret WhatEverPasswordYouMade

set system radius-options password-protocol mschap-v2

set system login user su class super-user

commit

 

Monday, September 5, 2016

Remotly Downloading Torrents

Lets say you only have ssh connections to your server, and you wanted to download torrents.


Things you will need:


Remote system:

putty or SecureCRT

sftp https://winscp.net/eng/docs/free_sftp_client_for_windows


Linux commands installed:

screen

transmission-cli


1. Download your torrent file.

2. Use sftp to send the file to your BitTorrent file folder.

3. Login to your system

4. Startup screen by typing

 $screen

  This will start a terminal run man screen for more information http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

5. start torrent client

$transmission-cli Example.of.Torrent.file.torrent -w /location/to/save/file

6. Detach from screen session to log off.

hold Ctrl+a  then hit the d key to detach.
This will output a session id <id>.fqdn

7. When you login later

$screen -ls
111111.hostname1
222222.hostname2

8. Connect to screen
$screen -r 111111

Linux job commands:
Ctrl+z will put the job(process) on pause
$bg
Will put the job in the background
$fg
will put the job in the foreground
Ctrl+c will quit the program.

10. After checking the status you can Ctrl+c to end the torrent or Ctrl+a d to detach from screen.

11. To start another screen just type in
$screen
Detach (Ctrl+a d)
$screen -ls
$screen -r <id#>

Please revise for transmission-remote if possible

Friday, September 2, 2016

Virtual firewalls in OpenStack not routing packets properly

So I ran into an issue after loading up a vSRX and virtual F5 Big IP in OpenStack. I setup the virtual appliances as the gateway for my other instances but their packets were not traversing across the other networks if they were routed by my vSRX or vBigIP.

To eliminate all other factors, I went ahead and enable ping on the all interfaces and moved them all into the trusted zone of the SRX. Then I attempted to pings the other interfaces of the firewall that were in the other subnets. They all failed, but the SRX showed that it received the packets and sent the replies. I experience the same thing on the virtual instance of Big IP. That lead me to believe it was failing on the virtual switch in Openstack.

 

It seems port security is enable by default and needs to be disabled in neutron. To do this, perform the following.

Delete any virtual objects that you have created that will need packets routed across your virtual firewall and remove any security groups you have applied to the instance.

Modify the file in /etc/neutron/plugins/ml2/ml2_conf.ini

Right below [ml2] – you will need to add extension_drivers = port_security

# An ordered list of extension driver entrypoints to be loaded from the

# neutron.ml2.extension_drivers namespace. For example: extension_drivers =

# port_security,qos (list value)

extension_drivers = port_security

After this is completed, restart neutron

systemctl restart neutron-server

 

Start creating the new tenant networks and attaching the interfaces to your virtual firewall and other instances. Find out what port ID they have been assigned, this will be easy to locate using the GUI

 

 

Once you get the port ID execute the following to turn off port security

neutron port-update  2bf6b77b-627e-4fd0-8cd9-69dc0b27d65e --port-security-enabled=False

 

You can check to see if it too with the following command

neutron port-show 1ee02bbe-4f87-4cb4-91e0-ced0ef691e1c

 

Once completed on all interfaces required, that should resolve the routing issue.

 

Disabling port security will prevent you from using security groups. Firewalls don't really need security groups enabled but if you want more restriction you can use allowed address pairs instead.

 

neutron port-update 'Port UUID' --allowed_address_pairs list=true type=dict ip_address='ip or CIDR'

 

Apply this on all ports that will be use to route traffic.

 

Thursday, August 18, 2016

Setup DHCP client for SRX interface and port forwarding

Almost 3 years since I posted anything. Decided to make a quick post today since my firewall died and I replaced it with a Juniper SRX 210. For home use, this firewall kind of sucks. DHCP client on the WAN (untrusted) connection does not work out of the box, I had to do a little tweaking to get it running. In addition to that, the remote access VPN is clunky and I was unable to get it running using 3rd party client software. There is no UPnP of course, which is expected from this type of firewall. But like I said, I am using this as a temporary replacement cause my home firewall died so I had to manually open all my port which was kind of a pain.

 

First of all, to get my DHCP working so the ONT can assign my firewall an IP I had to do a couple of things. The first was enable the interface for DHCP client, that was easily done from the GUI with a check box. Next I execute the following from the shell

 

vi /etc/rc.custom

·         save this file

·         execute the following

sysctl -w net.inet.ip.mcast_ttl=64

·         Modify the permission

chmod 777 /cf/etc/rc.custom

 

 

Then from the CLI we need to modify the security policy to accept DHCP for the interface that needs to obtain an IP address. In my case it was the ge-0/0/0.0

 

 

set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcp

 

 

·         Then execute the following command

request system services dhcp renew ge-0/0/0.0

 

My firewall did not receive and IP address till I power cycled the ONT.

 

Enabling each port through the firewall was a serious beating. When using multiple ports to forward to the same server. You will need to make a new address entry for that same IP for each new rule. You can use and modify the following to make it a quick copy and paste

 

·         define your addresses

set security zones security-zone trust address-book address sodapc 192.168.150.99/32

·         define your applications

set applications application qbtor protocol tcp

set applications application qbtor destination-port 9497

·         define your nat rules

set security nat destination pool dnat-192_168_150_99m32 address 192.168.150.99/32

set security nat destination pool dnat-192_168_150_99m32 address port 9497

·         adjust the nat rule for your public IP

set security nat destination rule-set dst-nat rule rule3 match destination-address 0.0.0.0/0

set security nat destination rule-set dst-nat rule rule3 match destination-port 9497

set security nat destination rule-set dst-nat rule rule3 then destination-nat pool dnat-192_168_150_99m32

·         create the policies to permit the traffic

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match source-address any

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match destination-address sodapc

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 match application qbtor

set security policies from-zone untrust to-zone trust policy untrust-to-trust3 then permit

 

I have a ton of service at home so I went on with this for quite a while. UPnP would have saved a lot of time.