Note: This is for Cisco ASA 5500, 5500-x, and Cisco Firepower devices running ASA Code.
If you have a spare/available public IP address you can statically map that IP address to one of your network hosts, (i.e. for a mail server, or a web server, that needs public access).
This is commonly referred to as a ‘Static NAT’, or a ‘One to One translation’. Where all traffic destined for public address A, is sent to private address X.
Note: This solution is for firewalls running versions above version 8.3. If you are unsure what version you are running use the following article.
In the following example I will statically NAT a public IP address of 81.81.81.82 to a private IP address behind the ASA of 172.16.254.1. Finally I will allow traffic to it, (in this example I will allow TCP Port 80 HTTP/WWW traffic as if this is a web server).
Create a Static NAT and allow web traffic via ASDM
3. Give the ‘object’ a name (I usually prefix them with obj-{name}) > It’s a Host > Type in it’s PRIVATE IP address > Tick the NAT section (press the drop-down if its hidden) > Static > Enter it’s PUBLICIP address > Advanced > Source = Inside > Destination > Outside > Protocol TCP. Note: You could set this to IP, but I’m going to allow HTTP with an ACL in a minute, so leave it on TCP > OK > OK > Apply.
4. Now navigate to Firewall > Access Rule > Add > Add Access Rule.
5. Interface = outside > Permit > Source = any > Destination = PRIVATEIP of the host > Service > Press the ‘more’ button > Locate TCP/HTTP > OK > OK > Apply.
6. Then save your work with a File > Save Running Configuration to Flash.
Create a Static NAT and allow web traffic via Command Line
2. Log In > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password:*******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: *******
PetesASA# conf t
PetesASA(config)
[/box]
3. First I’m going to allow the traffic to the host (Note: after version 8.3 we allow traffic to the private (per-translated IP address). This assumes you don’t have an inbound access list if you are unsure execute a “show run access-group” and if you have one applied substitute that name for the word ‘inbound’.
Warning before carrying out applying the ‘access-group’ command, see the following article;
I’ve had very little exposure to JUNOS and Juniper equipment, and later in the year I have to deploy some for a client in a failover cluster. So I had a good look round on the Internet, and found loads of good blog posts and KB articles like this one. The problem is they are all geared to setting up a cluster, they ASSUME you then know about security zones, how to add default routes, and setup NAT etc. So they don’t cover that. Yes you then can set up a cluster, but it has no IP addresses, and you cant pass any traffic though it! Hopefully this will redress the balance.
Solution
Before you start, you obviously need two physical firewalls running the same OS, and this whole procedure is carried out from command line, (I’m using the console cable).
Things that took me a while to grasp, that you need to know.
1. The SRX240 has 16 ports numbered ge-0/0/0 to ge-0/0/15, when you cluster them the ports on the secondary firewall (node1) are renumbered to ge-5/0/0 to ge-5/0/16.
2. As soon as you cluster the firewalls the first port (on both) is reserved for management. That’s ge-0/0/0 and ge-5/0/0 they are then refereed to as fxp0.
3. As soon as you cluster the firewalls the second port (on both) is reserved for the firewalls control plane. That’s ge-0/0/1 and ge-5/0/1 they are then refereed to as fxp1.
4. You need to dedicate another port on both firewalls for the firewalls data link this can be any port, but to keep things simple I’ll use the next free port on both firewalls (ge-0/0/2 and ge-5/0/2). These will then be referred to as fab0 and fab1 (respectively).
Thats the clustering side of things, what about the networks I’m going to connect to the firewall. Take a look at this diagram;
Both the firewalls have a connection to each network (which makes sense if they are going to fail over). I’ve got an ‘outside’ network that connects to the Internet. ‘Inside’ I’ve got two networks, (most people reading this will have one, but remember this is practice for a live client, and they have two data LANS).
As all the networks are connected in two places, where do you assign IP addresses? Well above you can see the outside connections are plugged into ge-0/0/4 and ge-5/0/4. You add both these physical interfaces to a Reth (Redundant Ethernet Interface), and you assign the IP to that. So I have three Reth interfaces, (Reth0 for outside, Reth1 for the first inside network, Reth2 for the second inside interface).
So only Reth interfaces have IP addresses? Well no, the two fxp0 interfaces on each physical firewall, also get an IP address (for out of band management), and it’s a different one for each firewall.
Step 1: SRX240 Setup a Chassis Cluster.
1. Before we start you need to delete the existing interfaces from the config (ALL of them), otherwise you will get some errors later on when you try and commit (save) the firewall config. Also remove the hostname, we will set that in a minute.
[box] delete interfaces ge-0/0/0
delete interfaces ge-0/0/1 —Repeat for the rest of the interfaces—
delete interfaces ge-0/0/14
delete interfaces ge-0/0/15
delete system host-name[/box]
2. Connect ge-0/0/0 to management network > Connect ge-5/0/0 to management network >
Connect ge-0/0/1 on Primary to ge-5/0/1 on Standby, (this can’t be changed and will be the fxp0 connection) > Connect ge-0/0/2 on Primary to ge-5/0/2 on Standby (this can be changed but will be the fab0 and fab1 connection).
3. Carry out the following procedure on BOTH firewalls. This sets the host names of the firewalls and the IP addresses of the management interfaces.
[box]set groups node0 system host-name FW-A
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.254.1/24
set groups node1 system host-name FW-B
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.254.2/24
set apply-groups “${node}”[/box]
4. On FW-A (the primary node0) turn on clustering.
6. Back on FW-A (the remainder of the config will be done on node0), set the configuration for the data link, notice I’m deleting the interface again, (I had a lot of bother with this so let’s play it safe). Then I’m saving the changes with a ‘commit’ command, because at this point if something is wrong it will tell you.
[box]delete interfaces ge-0/0/2
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
commit[/box]
Step 2 Create Redundancy Groups
1. Redundancy group 0 is created by default so set the priority for that one first.
[box]root@FW-A# set chassis cluster redundancy-group 0 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 0 node 1 priority 1[/box]
2. Create a new redundancy group that the Reth interfaces will use.
[box]root@FW-A# set chassis cluster redundancy-group 1 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 1 node 1 priority 1[/box]
Step 3 Define and Add Physical Interfaces to the Reth Interfaces
1. Define the number of Reth interfaces (two inside and one outside).
[box]root@FW-A# set chassis cluster reth-count 3[/box]
2. Allocate Reth0 to the physical interfaces (for outside).
{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/8 gigether-options redundant-parent reth1
root@FW-A# set ge-5/0/8 gigether-options redundant-parent reth1
root@FW-A# set reth1 redundant-ether-options redundancy-group 1
root@FW-A# set reth1 unit 0 family inet address 192.168.20.1/24 [/box]
6. Setup Reth2 (inside). Add the physical interfaces, and apply redundancy group 1 (again) then save the changes.
1. To get traffic out to the Internet. the cluster needs the IP of its ‘next-hop’, (usually the router supplied by your ISP).
Note: If you’re anything like me after you enter this you will try and ‘ping’ the router from the firewall, or ping an Internet. IP address, at this point that wont work, (you need to allocate interfaces to security zones first).
[box]root@FW-A# set routing-options static route 0.0.0.0/0 next-hop 123.123.123.1[/box]
Step 5 Add interfaces to Security Zones and Allow Traffic Out
Note: I’m simply allowing all traffic out.
1. Make sure the Security Zones ‘Trust’ and ‘Untrusted’ Exist
[box]root@FW-A# show security zones or
root@FW-A# run show security zones[/box]
2. Add the Reth0 Interface to the Untrusted zone.
[box]root@FW-A# set security zones security-zone untrust interfaces reth0.0 [/box]
3. Allow traffic.
[box]{primary:node0}[edit]
root@FW-A# set security zones security-zone untrust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone untrust host-inbound-traffic protocols all[/box]
4. You can check the changes before you commit them.
5. Then add Reth1 and Reth2 to the Trusted zone and repeat the process to allow all traffic.
[box]root@FW-A# set security zones security-zone trust interfaces reth1.0
root@FW-A# set security zones security-zone trust interfaces reth2.0
root@FW-A# set security zones security-zone trust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone trust host-inbound-traffic protocols all[/box]
6. Let’s check to see all that worked.
[box]
{primary:node0}[edit]
root@FW-A# show security policies from-zone trust to-zone untrust
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
{primary:node0}[edit]
root@FW-A# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
[/box]
Step 6 Allow Remote Management
1. We have two interfaces dedicated to out of band management, and we gave them an IP address earlier. Here I’m allowing remote administration via web to the J-Web console.
[box]root@FW-A# set system services web-management https interface fxp0.0[/box]
Step 7 Perform NAT on ‘Outgoing’ traffic.
1. Here we are doing what Juniper call ‘Source NAT‘ where we translate many addresses to one, (as in this case, but it can be a ‘pool’ of IP addresses). For the Cisco heads (like me) we are doing PAT.
Note: If you see Juniper mention ‘Destination NAT‘ they are usually talking about NATTING inbound traffic to one (or more) internal IP addresses.
[box] set security nat source rule-set TRUST-TO-UNTRUST from zone untrust
set security nat source rule-set TRUST-TO-UNTRUST to zone trust
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match source-address 192.168.0.0/16
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match destination-address 0.0.0.0/0
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE then source-nat interface [/box]
Related Articles, References, Credits, or External Links
Setting up ‘Static NAT’ is the process of taking one of your ‘spare’ public IP addresses, and permanently mapping that public IP to a private IP address on your network.
In the example above I want to give my web sever which has an internal IP address of 192.168.1.10/24, the public IP address of 1.1.1.5/24. So if someone out on the Internet wants to view my website, they can browse to http://1.1.1.5 (or a URL that I’ve pointed to 1.1.1.5 like http://www.mywebsite.com). Then that traffic will be NATTED, on the firewall for me.
Solution
1. Create a rule-set from the ‘untrust’ zone. Then add a rule to that rule-set, that has a destination of 1.1.1.5/32, and finally set it to NAT that traffic to 192.168.1.10/32.
[box]login: root
Password: *******
— JUNOS 12.1X44-D30.4 built 2014-01-11 03:56:31 UTC
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST from zone untrust
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST rule NAT-RULE-1 match destination-address 1.1.1.5/32
[edit]
root@FW-02# set security nat static rule-set UNTRUST-TO-TRUST rule NAT-RULE-1 then static-nat prefix 192.168.1.10/32
[/box]
2. Set the firewall to proxy-arp (advertise your pubic IP address with is MAC address), then add the web server to the global address book.
Note: ge-0/0/0.0 is the physical address you are advertising the new IP address from, on firewalls in a failover cluster you would use the Reth address i.e. reth0.0
[edit]
root@FW-02# set security address-book global address WEB-SERVER 192.168.1.10/32
[/box]
3. Allow traffic OUT from the web server. Here I’m letting out all ports, if you wanted just web traffic then use the keyword junos-http (TCP Port 80 (http)).
[box]
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match source-address WEB-SERVER
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match destination-address any
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT match application any
[edit]
root@FW-02# set security policies from-zone trust to-zone untrust policy WEB-SERVER-OUT then permit
[/box]
4. Then allow traffic IN to the web server, (here I’m locking it down to just http).
[box] [edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match source-address any
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match destination-address WEB-SERVER
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN match application junos-http
[edit]
root@FW-02# set security policies from-zone untrust to-zone trust policy WEB-SERVER-IN then permit
Juniper Allowing Traffic To Custom Ports And Applications
1. Although Juniper have a lot of built in ‘applications’ you can allow, what if you want to create your own? Below I’ll create a custom application for Remote Desktop Protocol (TCP port 3389).
[box] [edit]
root@FW-A# set applications application APP-RDP protocol tcp
[edit]
root@FW-A# set applications application APP-RDP destination-port 3389
[/box]
2. You could now use this application in your security policies e.g.
In the following example I’m using 192.168.1.100 as the internal IP address of the View Server and the public IP address of the firewall is 123.123.123.123.
Which solution you use, depends on weather you are allowing access via a dedicated public IP that you will assign to the VMware View server, or if you do not have a spare public IP, you will need to use port forwarding.
Option 1 – You have a public IP that you want to assign to the VMware View Server
As I’m using 123.123.123.123 on the outside of my ASA I’m going to use another public IP address for the VMware View server (123.123.123.124) and I will statically map that to its internal IP address. Then I allow the ports to that IP address, and finally apply the access-list (ACL) that I’ve used to the outside interface (where the VMware View traffic will be coming from).
Warning: The last command (starting access-group, applies the access-list ‘inbound’ in the inbound direction on the outside interface, you may already have an access-list applied to this interface (the ‘show run access-group’ command will tell you) If you do have another ACL simply substitute the name of yours for the work inbound in my example below).
Option 2 – You want to use Port Forwarding (And your ASA is pre version 8.3)
Below I’m creating a static PAT entry for all the ports required, then allowing the traffic with an access-list, and finally applying the access-list (ACL) that I’ve used to the outside interface (where the VMware View traffic will be coming from)
Warning: The last command (starting access-group, applies the access-list ‘inbound’ in the inbound direction on the outside interface, you may already have an access-list applied to this interface (the ‘show run access-group’ command will tell you) If you do have another ACL simply substitute the name of yours for the work inbound in my example below).
Note: If you port forward https on the outside interface, as I’m doing here, you will not be able to access the ASDM from outside – unless you put it on another port. The following two commands would change the ASDM to port 2345 for example:
Option 3 – You want to use Port Forwarding (And your ASA is version 8.3 or newer)
Below I’m creating a network object for all the ports required and statically NATTING the ports required to them, then I’m allowing the traffic to reach that network object, and finally applying the access-list (ACL) that I’ve used to the outside interface (where the VMware View traffic will be coming from)
Warning: The last command (starting access-group, applies the access-list ‘inbound’ in the inbound direction on the outside interface, you may already have an access-list applied to this interface (the ‘show run access-group’ command will tell you) If you do have another ACL simply substitute the name of yours for the work inbound in my example below).
Note: If you port forward https on the outside interface, as I’m doing here, you will not be able to access the ASDM from outside – unless you put it on another port: The following two commands would change the ASDM to port 2345 for example:
