Posts from ‘Networking’

Palo Alto 4020

Palo Alto 4020

Just under a year ago my employer started off a network refresh program on one of our internal core networks, we’re a type of ISP and this network was our main management core, so all the fairly important traffic goes over here like billing stats, element management traffic  (Telnet, SSH and RDP), alarms (Syslog, Corba, SNMP), plus the management traffic from NMS systems communicating with their respective network elements for user service provisioning.

As we’re a service provider the management core is actually very dynamic, because we’re constantly upgrading the network capacity, hardware and features while also normally decommissioning the legacy equipment. As someone working on these projects you often find yourself troubleshooting the core management connectivity more than customer services, good for the customers, but a pain when you real troubleshooting equipment isn’t targeted for this network and is invested in the revenue generating networks.

The original design

The topology was fairly simple about a year ago, each site generally had a multiple of two switches (Cisco Layer 2) to provide local element access into the network with resiliency, then two core firewalls  also operating in layer 2 mode, finally there were two Core MPLS routers which connected all sites together via a VPRN/VRF Layer 3 routed service, and these were the Layer 3 gateway for all the element’s/VLAN’s at that site.

Our future plan

As goes with most network upgrades we all sat down and decided over a cup (or two) of coffee what we wanted to get out of this network refresh, management set aside a decent budget for the work, but there wasn’t going to be any drastic changes or upgrades.

Access – The access layer is fairly simple and that’s the way we wanted it to stay, the older switches got replaced to make all the site’s capable of gigabit access, and all the configuration went through an intensive cleanup exercise to get rid of redundant configuration, plus a tighten up of access security and a general sanity check (such as ensuring all the switches are running the same version of spanning tree! no names to be mentioned).

Firewalls – When looking at firewalls there was a general decision to push these up the OSI stack to layer 3, mainly because the MPLS core configuration was getting quite busy with sub interfaces, with this change we also wanted some kind of routing protocol into the core to keep everything fairly dynamic, please no more static routes!

Vendor selection started off tricky but there was a clear winner in the end; historically we were always using Cisco PIX/ASA’s however this time we looked at Palo Alto mainly for the added security features, a lot of the elements on this network run proprietary operating systems where you can’t install any third party software, so having a firewall that could perform anti virus and spot threats on the network (like brute force detection) was very desirable, and when the costing/performance turned out to be  within ~4% of the Cisco alternative we couldn’t really say no.

Core  – As already mentioned the main change here was removing all of the access interfaces from the configuration, and setting up a routing adjacency (OSPF) with the firewall which was now hosting all of the local gateway addresses for each VLAN. There we’re no changes to the hardware/vendor at this layer as there were no real requirements.

The unexpected benefit

Example Log Search

Example Log Search

The original plan was fairly simple, to keep the network in support by means of hardware upgrades and cleanup the design slightly by moving routing down one step to the firewalls, at the vendor selection phase we also realised that our security could be greatly improved by going with the Palo Alto firewalls.

However the biggest advantage by far has been the logs that these firewalls create and push back to their management server (Panorama).

By design the firewall will create a start and end log for every session that passes through the firewall, with this you get all of the basic information like IP addresses, timestamps, ports. However you also get more information like URL logging, accurate application identification, packet and byte counts for both Rx and Tx. Plus unlike pushing your logs to a syslog server the management server has really good reporting and searching functionality built in.

The network engineers have fallen in-love with these firewalls purely because of the logs; for example say you have a server (  at Site A that’s having problems communicating with a server ( at Site B, in our design we know this traffic flow will pass a minimum of two firewalls (one at the edge of each site). So you simply log onto the firewall management server and search for related sessions “ip.addr in and ip.addr”, then as quick as a google search (we’ll may be a few seconds slower) you get a detailed list of all the traffic flows between them two addresses.

In the above example it was fairly simple to see that traffic made it all the way through our core network to the other side, then back into the MPLS core however it never hit the next firewall in the path (proven by a lack of Rx traffic on that first firewall), a quick look at the MPLS core found some old static routes that needed to be fixed, and 3 minuets later we’re back in action, no need for pings, trace routes, packet captures etc…!

Security that works

Panorama Log Collection

Panorama Log Collection

As mentioned a big initial driver for using these Palo Alto firewalls was the extra security, fortunately when we turned them on we didn’t find a raft of security threats already in the network, in-fact the only threats we really see are people (from the internet and normally in China) trying to breach our DMZ where one of these firewall pair’s sits.

We did once get a SSH brute force alarm from the internal network which the firewalls instantly managed to filter out, however a quick search found that it was from one of our employee laptops (VPN Client), a phone call found out that he was playing around with a python script that logged into one of our core routers to process the configuration for a up and coming network migration, however the wrong credentials in the script and some not so great coding (causing a login loop) triggered a brute force alarm on the firewalls.

It changed us!

We’re finding network engineers are actually preferring to put in firewalls now instead of “simple routers” because of the extra visibility that you can leverage from the network logs, and the security capabilities are blowing our customers minds when you can track security breaches down in a matter of seconds.

As always, comments are welcomed and appreciated!


Quite a few netgear devices come with a hidden page that you can browse to, this will then enable Telnet access on the device. However it looks like on the DGND3700 this page has actually been removed from the code base. Fortunately there is still a way to enable Telnet access to this router.

1. What you will need:
  • Download: Telnet Enable Netgear
  • Windows Machine, download the file here
  • PC on the same LAN as your router
  • Administrator rights on your local machine
2. Setup
  1. Now you have downloaded the file from step one, extract it, and place the enclosed .exe on your desktop.
  2. Open up a command line window
    1. Hold the windows and ‘r’ key
    2. Type in the window ‘cmd’
    3. Press enter
  3. In your command window enter the below command, and look for the physical address (MAC Address) for your router (normally
    1. arp -a

Screen Shot 2012-12-24 at 18.05.08

3. Enable telnet

Run the below command to enable telnet, don’t forget to change the IP and Physical address to match your setup.

telnetEnable.exe A021B78B0DC4 Gearguy Geardog
  1. telnetEnable.exe – is the script name
  2. – your router IP address, as you use to manage via the web interface
  3. A021B78B0DC4 – Your physical address, from step 2
  4. Gearguy – The default user, case sensitive!
  5. Geardog – The default password, case sensitive!
3. Login

You can telnet from your current window, by using the below command:


Or if you plan on doing a lot of work on the router I would suggest downloading a client like PuTTY

If your propmeted for a username or password use the ones mentioned in step 3.

Happy Hacking!

Screen Shot 2012-12-24 at 18.20.08


DGND3700I have already done a post about getting telnet access on to your DGND3700 netgear router, however you can also play around with some settings via hidden web pages. Below is an extract of all the web pages on the device for you to play around with, some you will have seen before like the normal setup pages, others are unique and only there normally for Netgear staff/developers/support.

Probably the most common one that people would want to tweek is WiFi_HiddenPage.htm

To view the pages, login to your device as normal, for example via

Then just append the file name you want to view,

Click the more button to see the full list; and just to note I am fairly sure this would probably affect your warranty status, only play around if you don’t mind having a bricked and unsupported router!

Continue reading “DGND3700 Hidden Pages” »


Traditionally Cisco based NAT on routers and firewalls was done in a fairly singular direction by defining two interfaces one as “inside” and the other as “outside”. As the names would suggest your “inside” would generally be your LAN with the private IP addressing and the “outside” would be your normally public ISP facing interface.

A typical configuration of this is below, where we have a single router with a LAN and WAN interface and outbound NAT towards the internet.

interface s0/1
  description link-to-isp-internet
  ip address
  ip nat outside

interface f0/0
  description link-to-corporate-lan
  ip address
  ip nat inside

Cleaner Method

Basically we can now enable NAT on an interface without specifying an explicit direction (inside/outside), this is really helpful if you want to perform PAT (outbound NAT for your clients) but also destination NAT (port forwarding) on the same inbound/outbound interface, plus it makes your whole NAT setup far more scalable for future changes.

The below command will define the IP addresses that we want to allocate for our NAT pool, the prefix length is the subnet mask for the IP range, plus we can also use the command to generate a ‘static’ type route into our routing table, this is useful if you need to ensure the NAT pool is reachable from the rest of your network via dynamic routing protocols.

ip nat pool PUBLIC_NAT_POOL prefix-length 24 add-route

The next step is to define an access list, this will be used to specify the pre NAT (think inside) addresses that will match the NAT rule.

access-list 1 permit

Now we need to join that access list up with the NAT pool and create a port address translation kind of setup

ip nat source list 1 pool PUBLIC_NAT_POOL overload

Finally we need to enable NAT on both interfaces, note we don’t define an inside/outside just enable as the access list and routing will take care of the direction.

interface s0/1
  ip nat enable
interface f0/0
  ip nat enable

Port Forwarding Example

It then makes it really simple to do something like port forwarding in the future, in the example below we forward HTTP requests to the interface IP address on s0/1 to port 8080 on our backend server.

ip nat source static tcp 80 interface s0/1 80

The syntax for that is fairly simple, as below:

ip nat source static [tcp/udp] [inside ip] [inside port] interface [outside interface] [outside port]

Asterisk is a great voice over IP server that can be used to replace or compliment a traditional PBX, out of the box it has a great number of features.

However with most things VoIP/SIP based you can almost be sure you will need to do some debugging at some point. Certainly for SIP issues the best place to look would be in traces of the realtime SIP packets that are passing through the Asterisk box.

Debug the RAW Asterisk SIP Packets

The first sage is to enter the asterisk command line mode

asterisk -r

Next you need to enable the SIP debug, normally it’s a good idea to enable it for a specific SIP peer that your having problems with

sip set debug on
sip set debug peer {name}

Now make your inbound or outbound call and follow the packet flow to get an idea of where the issue may be…

Show current SIP registration status

If your using a SIP service that requires registration you may also want to check the current registration status, this can be done using the below command

sip show registry

Reload SIP configuration, and re-register clients

If you have been making /etc/asterisk/sip.conf changes on the fly you will probably want to reload the file and reset your registrations, the following command will accomplish that:

sip reload

Our Sponsors