Tuesday, 27 June 2017

How to Configure L3 Untagged Subinterfaces to Communicate within Different Zones in Palo Alto

Overview

This document provides steps on how to configure Layer 3 untagged subinterfaces.

Steps

  1. Go to Network > Interfaces.
  2. Select a physical interface.
  3. Enable Untagged Subinterface.
    The untagged L3 subinterfaces are designed to work without ip-address on the physical device.
    ss1.png
  4. Create Untagged subinterfaces and assign them a different virtual router and zone.
    The following screenshot shows three L3 subinterfaces configured eth1/6.10, eth1/6.11, and eth1/6.12:
    ss2.png
    • Subinterface Interface: Ethernet 1/6.10 is assigned a zone L3-Trust
    • Subinterface Interface: Ethernet 1/6.11 is assigned a zone L3-DMZ
    • Subinterface Interface: Ethernet 1/6.12 is assigned a zone L3-Trust
  5. Go to Policies > Security to view Security policies for communicating from L3-Trust to L3-DMZ.
    ss3.png
  6. All outgoing traffic from each tenant is source NAT'ed to the subinterface IP address.  Go to Policies > NAT to view the NAT policy for the host 10.10.10.10 behind the subinterface Ethernet 1/6.10 to communicate to host 11.11.11.11 behind subinterface Ethernet 1/6.11.
    ss4.png
  7. Go to Policies > Security to view the Security policies applied for communicating from L3-DMZ to L3-Trust.
    ss5.png
  8. Go to Policies > NAT to view the NAT policy for the host 11.11.11.11 behind the subinterface Ehternet 1/6.11 to communicate to host 10.10.10.10 behind subinterface Ethernet 1/6.10.
    ss6.png
With the above configuration, the host 10.10.10.10 (behind subinterface Ethernet 1/6.10) can ping host 11.11.11.11 (behind Etherent 1/6.11) and the other way around.

Friday, 16 June 2017

How to Integrate GNS3 With VMWare Workstation Easily

Intergration of GNS3 with VMWare

Objectives Of 15-Steps Visual Guide

The ultimate guide to understand the nuances of integrating GNS3 with VMWare WorkStation version 10/11/12. Two approaches of this integration has been elaborated & presented in this visual guide.
The idea is to provide the helping tool to candidates aspiring to practice and obtain their CCIE, CCNP, CCNA certifications.

topology

We will create and configure the above topology. For that we need, two routers (ISP-India, ISP-US), two hosts (LuminisIndia.com, Client), and two Virtual Networks: 
  1. LuminisIndia will use this network 200.200.200.0/24.
  2. Client will use this network 33.33.33.0/24. 
We will achieve the fully working topology as shown above, by following the steps in this Visual Guide created by: Meena, Sr. Manager IT and Consultant. So let's start.

Step 1

Start your VMware workstation software and open the Virtual Network Editor through Edit menu of VMware. Then click on Change Settings  first, so as to allow us creation of Virtual Networks.
Integration of GNS3 with VMWare 1

Step 2

Now we can add the Virtual Networks. Click on Add Network and select the VMnet (VMnet2) from the drop down list and click on OK. 
Integration of GNS3 with VMWare 2
You can see that a new Virtual Network has appeared VMnet2 in the Virtual Network Editor and it has a default subnet, e.g., 192.168.228.0 with subnet mask 255.255.255.0. But we will not use the given subnet, instead we will change it to 200.200.200.0/24.
Integration of GNS3 with VMWare 3
If we want to assign IP address automatically to our hosts (PCs or VMs or Servers), we can use the DHCP service which is the part of this Virtual Network. To set the specific range of IP for the host click on DHCP Settings and specify the range of IP.
Integration of GNS3 with VMWare 4

Step 3

We will follow  Step2 again and create the 2nd Virtual Network VMnet3, assign the subnet 33.33.33.0/24 and also change the DHCP Settings.
Integration of GNS3 with VMWare 5

Integration of GNS3 with VMWare 6
We can see here are the two new Virtual Networks.
Integration of GNS3 with VMWare 7

Step 4

Open Network and Sharing Center from your Windows 7/8/10, etc and you will find the two new VMware Network Adapters. Go to VMware Network Adapter VMnet3.  Here you can see that DHCP has assigned the IP 33.33.33.1/24  to VMware Network Adapter VMnet3.
Integration of GNS3 with VMWare 8
But we will assign the IP address 33.33.33.1 as a Default gateway, which will, in effect, become the IP address of ISP-US Router. Now we have choice of assigning any IP address from the range of 33.33.33.2 - 33.33.33.254 , to VMware Network Adapter VMnet3. Here we are choosing 33.33.33.33/24 for the sake of convenience. 
Integration of GNS3 with VMWare 9
Now, we will change the name of VMWareNetwork Adapter VMnet3 to Client. 
Integration of GNS3 with VMWare 10

Step 5

In this step, we will see the status of VMware Network Adapter VMnet2. 
Integration of GNS3 with VMWare 11
We can see that the IP address assigned by the DHCP is 200.200.200.1/24.   But we will assign the IP address 200.200.200.1 as a Default gateway, which will, in effect, become the IP address of ISP-India Router. Now we have choice of assigning any IP address from the range of 200.200.200.2 - 200.200.200.254 , to VMware Network Adapter VMnet2. Here we are choosing 200.200.200.200/24 for the sake of convenience.
Integration of GNS3 with VMWare 12
Then change the name of VMware Network Adapter VMnet2 to LuminisIndia.
Integration of GNS3 with VMWare 13

 Step 6

Start your GNS3 and create the topology of the network which we will use. Drag the two routers and two hosts. Then change the name of these to : R1 (ISP-India), R2(ISP-US), Host1 (LuminisIndia.com), Host2 (Client).
Integration of GNS3 with VMWare 14
Add the notes for network addresses and IP addresses which we will use in this topology.
Integration of GNS3 with VMWare 15

Step 7

Link the VMware Network Adapters with the Hosts, e.g. Host LuminisIndia.com with LuminisIndia (VMware Network Adapter VMnet2), Host Client with Client (VMware Network Adapter VMnet3).
Integration of GNS3 with VMWare 16
Sometimes the newly created VMware Network Adapters doesn't appear in the list. You must save your project of GNS3 and reload it. Then all the Network Apaters will appear. Be careful In this process, because wrong association will create more confusion in the desired results.   
Integration of GNS3 with VMWare 17

Integration of GNS3 with VMWare 18

Integration of GNS3 with VMWare 19

Step 8

Now connect the devices and also make a note of the interface number you are going to use in your topology. I always use paper to draw the full topology, means: devices, interfaces no., network addresses, IP addresses, etc. This helps me in configuration and trobleshooting.  Then start (power on) all the devices.
Integration of GNS3 with VMWare 20
Now ensure that your Client and LuminisIndia (VMware Network Adapters) must be enabled and keep the rest of Network Adapters Disabled. This step will help you in verification process.
Integration of GNS3 with VMWare 21

Step 9

In this step, we will configure the Routers. On router ISP-India, you can see that IP Address on Interface Ethernet 0/0 is 200.200.200.1/24, which is connected with the Host LuminisIndia.com and this IP is the Default Gateway, on VMware Network Adapter LuminisIndia.  Assign the IP Address 12.1.1.1/30 to the Interface Serial 1/1.  Your intereface no. can be different.  For routing, use Routing Protocol EIGRP and advertise the networks 12.0.0.0 and 200.200.200.0.
Integration of GNS3 with VMWare 22
Also configure the ISP-US router as per the configuration given in the below image.
Integration of GNS3 with VMWare 23

Step 10

After completing the configuration, next part is the testing or verification. First, try to ping the directly connected devices, if you face any problem troubleshoot it. Then open two command prompts and try to ping both the hosts and routers as well, as I did in the below image. If you get the successful reply, that means you have configured everything properly.
Integration of GNS3 with VMWare 24

Are you sure that everything is working in the same way we are expecting?


Featured NAT PAT Configuration
Step 11
Let's take the another approch for verification of our configuration. On the Router ISP-US, SHUTDOWN the interface Ethernet0/0 which is connected with the Client.  Try to ping 33.33.33.33 from router and also check the Interface Status, by following the commands of below image.
Integration of GNS3 with VMWare 25
Try to ping the IP 33.33.33.1 from the command prompt. Now ping 12.1.1.2 which the IP on ISP-US, and then use the tracert command. You can see that the traffic is going through ISP-India to ISP-US. You can also see the results in below image.  
Integration of GNS3 with VMWare 27
In the above results you would have observed that from ISP-US router you cann't ping the host Client and from the command prompt you cann't ping the 33.33.33.1. It means that the interface is down, which is not allowing the ping. 
Now run the NO SHUTDOWN command of the interface Ethernet 0/0, this will UP the interface and will allow the traffic to pass through the interface. 
Integration of GNS3 with VMWare 28
The same testing we will do with LuminisIndia, but using a different approach. Now disable the VMware Network Adapter LuminisIndia. 
Integration of GNS3 with VMWare 29
 You can follow the testing commands given in the below image. I think with this apporach things will be more clear.
Integration of GNS3 with VMWare 30
NOTE: With the above steps, you can do your Cisco Labs and you also need not to create the Virtual Machines. 
But if you need more services and/or you need the Virtual Machines, then follow the further steps of this visual guide.

Featuerd ARP Working

Step 12

Start the New Virtual Machine Wizard from the File Menu.
Integration of GNS3 with VMWare 31
Follow the instructions in the wizard and create the Virtual Machine (VM).
Integration of GNS3 with VMWare 32

Step 13

Now Edit the VM,  select the Operating System image which you want to install on this VM. Associate the VMnet to it, and then Power on the VM. I have given the name LuminisIndia to this VM and VMnet2 (200.200.200.0/24) Virtual Network to this VM.
Integration of GNS3 with VMWare 33

Step 14

Install the Operating System on the VM, you can see the below image.
Integration of GNS3 with VMWare 34
Now we will check the status of the Network Adapter of this newly installed VM. You can see that it received the IP Address automatically from the DHCP Local server of this VMnet.
Integration of GNS3 with VMWare 35
Now, change the IP address and Default gateway as per the image given below and also turn off your windows Firewall or Antivirus. 
Integration of GNS3 with VMWare 36

Step 15

Follow the testing as per below image.
Integration of GNS3 with VMWare 37
And if you need the another VM, you can follow the above steps. 
I hope this will help you understand the Integration of the GNS3 with VMware Workstation. 

Palo Alto - NAT

This section describes Network Address Translation (NAT) and how to configure NAT rules and features.
Purpose of NAT
NAT was introduced to solve the problem of an organization not having enough public, globally-routable IPv4 addresses assigned to it by the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry. NAT translates private, non-routable IPv4 addresses to one or more globally-routable IPv4 addresses, thereby conserving an organization’s routable IP addresses.
Since its origination, the use of NAT has expanded. For example, NAT is used as a way to not disclose the real IP addresses of hosts that need access to public addresses. It is also used to manage traffic by performing port forwarding. The NAT64 option translates between IPv6 and IPv4 addresses, providing connectivity between networks using disparate IP addressing schemes, and therefore a migration path to IPv6 addressing. PAN-OS supports all of these uses.
If you use private IP addresses within your internal networks, you must use NAT to translate the private addresses to public addresses that can be routed on external networks. In PAN-OS, you create NAT policy rules that instruct the firewall which packet addresses need translation and what the translated addresses are.
NAT Rules and Security Policies
You configure a NAT rule to match a packet’s source zone and destination zone, at a minimum. In addition to zones, you can configure matching criteria based on the packet’s destination interface, source and destination address, and service. You can configure multiple NAT rules. The firewall evaluates the rules in order from the top down. Once a packet matches the criteria of a single NAT rule, the packet is not subjected to additional NAT rules. Therefore, your list of NAT rules should be in order from most specific to least specific so that packets are subjected to the most specific rule you created for them.
It is important to understand the firewall’s flow logic when it applies NAT rules and security policies so that you can determine what rules you need, based on the zones you have defined.
Upon ingress, the firewall inspects the packet and does a route lookup to determine the egress interface and zone. Then the firewall determines if the packet matches one of the NAT rules that have been defined, based on source and/or destination zone. It then evaluates and applies any security policies that match the packet based on the original (pre-NAT) source and destination addresses, but the post-NAT zones. Finally, upon egress, for a matching NAT rule, the firewall translates the source and/or destination address and port numbers.
Keep in mind that the translation of the IP address and port do not occur until the packet leaves the firewall. The NAT rules and security policies apply to the original IP address (the pre-NAT address). A NAT rule is configured based on the zone associated with a pre-NAT IP address.
Security policies differ from NAT rules because security policies examine post-NAT zones to determine whether the packet is allowed or not. Because the very nature of NAT is to modify source or destination IP addresses, which can result in modifying the packet’s outgoing interface and zone, security policies are enforced on the post-NAT zone.
Address Pools Identified as Address Objects
When configuring a NAT IP address pool, it is typical to identify it as address object. It can be a host IP address, IP address range, or IP subnet. Because both NAT rules and security policies use address objects, it is a best practice to distinguish between them by naming an address object used for NAT with a prefix, such as “NAT-name.”
Source NAT and Destination NAT
The firewall supports both source address and/or port translation and destination address and/or port translation.
Source NAT
Source NAT is typically used by internal users to access the Internet; the source address is translated and thereby kept private. There are three types of source NAT:
Dynamic IP and Port (DIPP) —Allows multiple hosts to have their source IP addresses translated to the same public IP address with different port numbers. The dynamic translation is to the next available address in the NAT address pool, which you configure as a Translated Address pool be to an IP address, range of addresses, a subnet, or a combination of these.
As an alternative to the next address in the NAT address pool, DIPP allows you to specify the address of the Interfaceitself. The advantage of specifying the interface in the NAT rule is that the NAT rule will be automatically updated to use any address subsequently acquired by the interface.
DIPP has a default NAT oversubscription rate, which is the number of times that the same translated IP address and port pair can be used concurrently. For more information, see Dynamic IP and Port NAT Oversubscription and Modify the Oversubscription Rate for DIPP NAT.
Dynamic IP —Allows the 1-to-1, dynamic translation of a source IP address only (no port number) to the next available address in the NAT address pool. By default, if the source address pool is larger than the NAT address pool and eventually all of the NAT addresses are allocated, new connections that need address translation are dropped. The default behavior can be changed by clicking Advanced (Dynamic IP/Port Fallback), which causes DIPP addresses to be used when necessary. In either event, as sessions terminate and the addresses in the pool become available, they can be allocated to translate new connections.Static IP —Allows the 1-to-1, static translation of a source IP address, but leaves the source port unchanged. A common scenario for a static IP translation is an internal server that must be available to the Internet.
Destination NAT
Destination NAT is performed on incoming packets, when the firewall translates a public destination address to a private address. Destination NAT does not use address pools or ranges. It is a 1-to-1, static translation with the option to perform port forwarding or port translation.
Static IP —Allows the 1-to-1, static translation of a destination IP address and optionally the port number.
One common use of destination NAT is to configure several NAT rules that map a single public destination address to several private destination addresses assigned to servers or services. For example:
Port Forwarding —Can translate a public destination address and port number to a private destination address, but keeps the same port number.Port Translation —Can translate a public destination address and port number to a private destination address and a different port number, thus keeping the real port number private. It is configured by entering a Translated Port on the Translated Packet tab in the NAT policy rule.
NAT Rule Capacities
The number of NAT rules allowed is based on the firewall platform. Individual rule limits are set for static, Dynamic IP (DIP), and Dynamic IP and Port (DIPP) NAT. The sum of the number of rules used for these NAT types cannot exceed the total NAT rule capacity. For DIPP, the rule limit is based on the device’s oversubscription setting (8, 4, 2, or 1) and the assumption of one translated IP address per rule. To see platform- specific NAT rule limits and translated IP address limits, use the Compare Firewalls tool.
Consider the following when working with NAT rules:
If you run out of pool resources, you cannot create more NAT rules, even if the platform’s maximum rule count has not been reached.If you consolidate NAT rules, the logging and reporting will also be consolidated. The statistics are provided per the rule, not per all of the addresses within the rule. If you need granular logging and reporting, do not combine the rules.
Dynamic IP and Port NAT Oversubscription
Dynamic IP and Port (DIPP) NAT allows you to use each translated IP address and port pair multiple times (8, 4, or 2 times) in concurrent sessions. This reusability of an IP address and port (known as oversubscription) provides scalability for customers who have too few public IP addresses. The design is based on the assumption that hosts are connecting to different destinations, therefore sessions can be uniquely identified and collisions are unlikely. The oversubscription rate in effect multiplies the original size of the address/port pool to 8, 4, or 2 times the size. For example, the default limit of 64K concurrent sessions allowed, when multiplied by an oversubscription rate of 8, results in 512K concurrent sessions allowed.
The oversubscription rates that are allowed vary based on the platform. The oversubscription rate is global; it applies to the device. This oversubscription rate is set by default and consumes memory, even if you have enough public IP addresses available to make oversubscription unnecessary. You can reduce the rate from the default setting to a lower setting or even 1 (which means no oversubscription). By configuring a reduced rate, you decrease the number of source device translations possible, but increase the DIP and DIPP NAT rule capacities. To change the default rate, see Modify the Oversubscription Rate for DIPP NAT.
If you select Platform Default, your explicit configuration of oversubscription is turned off and the default oversubscription rate for the platform applies, as shown in the table below. The Platform Default setting allows for an upgrade or downgrade of a software release.
The following table lists the default (highest) oversubscription rate for each platform.
PlatformDefault Oversubscription Rate
PA-2002
PA-5002
PA-20202
PA-20502
PA-30202
PA-30502
PA-30602
PA-40204
PA-40508
PA-40608
PA-50204
PA-50508
PA-50608
PA-70508
VM-1001
VM-2001
VM-3002
VM-1000-HV2
The firewall supports a maximum of 256 translated IP addresses per NAT rule, and each platform supports a maximum number of translated IP addresses (for all NAT rules combined). If oversubscription causes the maximum translated addresses per rule (256) to be exceeded, the firewall will automatically reduce the oversubscription ratio in an effort to have the commit succeed. However, if your NAT rules result in translations that exceed the maximum translated addresses for the platform, the commit will fail.
Dataplane NAT Memory Statistics
The show running global-ippool command displays statistics related to NAT memory consumption for a pool. The Size column displays the number of bytes of memory that the resource pool is using. The Ratio column displays the oversubscription ratio (for DIPP pools only). The lines of pool and memory statistics are explained in the following sample output:
For NAT pool statistics for a virtual system, the show running ippool command has columns indicating the memory size used per NAT rule and the oversubscription ratio used (for DIPP rules). The following is sample output for the command.
A field in the output of the show running nat-rule-ippool rule command shows the memory (bytes) used per NAT rule. The following is sample output for the command, with the memory usage for the rule encircled.

PAN-OS Supported ciphers

Following is a list of supported ciphers for PAN-OS 7.1 and later: SSLv3 Ciphers Supported (No change from PAN-OS 7.0) Non-FIPS mod...