If you have a host that you want to be able to access from the outside of the firewall e.g. a webserver then this is the process you want to carry out. I didn’t find this process particularly intuitive and it highlighted why I don’t like GUI management interfaces, (in 6.4 the menu names have changed, this rendering a million blog pages inaccurate!)
I’m setting this up in EVE-NG on the work bench and this is what I’m trying to achieve;
So to access my web server from ‘outside‘ the firewall I need to give it a NATTED ‘public‘ address on 192.168.100.0/24. Here the server is on the LAN if yours is in a DMZ then substitute the DMZ interface for the inside one I’m using.
Solution
First task is to create a ‘Virtual IP‘, this will be the ‘public IP‘ that the web server will use. From the management interface > Policy and Objects > Virtual IPs > Create New > Virtual IP
‘Give it a sensible name, and add a comment if you wish > Set the interface to the public facing port > Type, set to ‘Static NAT‘ > External IP, (although it says range just type in the single public IP) > Internal IP = Enter the LAN IP > OK.
Firewall Policy > Create New.
Note: If your firewall is older then 6.4 the tab is called ‘IPv4 Policy‘
Give the entry a name > Incoming interface = the public interface > Outgoing Interface = the inside/LAN interface > Source = ALL > Destination = SET TO YOUR VIRTUAL IP > Schedule = Always > Service = ALL (though you can of course select http and or https in production) > DISABLE NAT. (Trust me I know that makes no sense) > OK.
Just to prove this is not all ‘Smoke and Mirrors‘ here’s my topology running in EVE-NG, and my external host (Named: Public-Client) Browsing to 192.168.100.110, and the Fortigate translates that to 192.168.1.123
Related Articles, References, Credits, or External Links
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;
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.
