ASA CHAPTER 6 (STATIC NAT/Dynamic Policy NAT)
8.Configure Static NAT and PAT as per given conditions .
Clear any Previous NAT rules if needed.
• Map the DMZ IP address 10.0.0.100 to the outside 136.X.122.100.
• Configure Static PAT such that telnet sessions to the outside interface are
redirected to R1.
9. Configure Dynamic Policy NAT
• Clear any previous NAT rules if needed.
• Telnet connections going outside should be PAT translated using the IP
address 136.X.122.100
• ICMP packets going outside should be PAT translated using the IP
address 136.X.122.101
• Use the access-lists TELNET and ICMP to distinguish two types of traffic.
• Everything else should be PAT translated using the outside interface IP.
A static NAT rule establish bi-directional mapping between local and global IP
addresses. Unlike a dynamic rule, which usually maps N local addresses to M
global address, where N > M, the number of global addresses equals the number
of local addresses within a static rule. Static translations are used for the
following purposes:
1) To allow accessing a server located on the inside using a fixed global (outside)
IP. The syntax would be:
static (<local-iface>,<global-iface>) <global-ip> <localip>
e.g.
static (inside,outside) 136.1.122.100 10.0.0.1
What this rules does, is establishes a bi-directional mapping between the
local-ipand the global-ip. Note that in the rule, local-ifaceis the
interface where local-ipresides, while global-ipshould either be on the
subnet shared by the global-ifaceor routed to the firewall appliance across
the global-iface. This rule also allows the inside server to initiate connections
to the outside and has its source IP translated to the global IP address. Now look
at the following “extreme” rule:
static (inside,outside) interface 10.0.0.1
What it does, is uses the global interface IP (in this case – outside) and maps it
to the local IP (10.0.0.1). Thus, all connections made to the outside IP of the ASA
are redirected to the internal server. Of course, they should be permitted with an
ACL prior to that. This will disable any services that ASA runs on the outside
interface, by the way.
2) To redirect a particular port at the global IP to the port at the inside IP (aka
Static PAT or port redirection). The syntax is:
static (<local-iface>,<global-iface>) {tcp|udp} <global-ip>
<port> <local-ip> <port>.
e.g.
static (inside,outside) tcp 136.1.122.100 80 10.0.0.1 8080
would redirect all connections going to 136.1.122.100 port 80 to the inside IP
10.0.0.1 port 8080. You would usually use this rule when you have little or just
one global IP address and would like to multiplex different services (e.g. FTP,
WWW, DNS) between different internal services. It is also possible to redirect
connections going to the ASA’s own interface:
static (inside,outside) tcp interface 80 10.0.0.1 80
static (inside,outside) tcp interface 21 10.0.0.2 21
This is a common construct when you only have a single global IP address
assigned to the outside interface of the firewall. Note that static PAT does not
allow the internal server to access the internal using the global IP address. You
must define a dynamic NAT rule in order to allow the internal server to initiate
connections on its own. For example:
static (inside,outside) tcp interface 80 10.0.0.1
nat (inside) 1 10.0.0.0 255.255.255.0
global (outside) 1 interface
This configuration allows any host on the inside to access the outside by having
their source addresses translated using the firewall’s outside IP. At the same
time, connections to the firewall’s outside interface port 80 are redirected to the
server with the IP 10.0.0.1
3) Reverse redirection. Sometimes, you may want to redirect a connection going
to an inside host to some outside destination. This is often called “routing
simplification”, as it might be used in situations where inside hosts lack routing
information, e.g. have no default gateway set, or have the default route pointing
toward some other router (not the firewall).
For example, imagine you have a DNS server on the outside with the IP address
136.1.122.200 but you want the inside hosts to use the IP 10.0.0.200 to access
the DNS server (e.g. the hosts have no default gateway set). The following
“reverse” construct (local and global interfaces are “swapped”) would achieve the
goal:
static (outside,inside) 10.0.0.200 136.1.122.200
The firewall will do Proxy-ARP for the IP address 10.0.0.200 on its inside
interface, provided that 10.0.0.0/XX is the inside’s interface subnet. In other
cases, this subnet should be explicitly routed to the firewall. Remember, that the
inside hosts most likely need their sources translated when accessing the outside
DNS. Thus, you may need to add a dynamic NAT rule as well:
nat (inside) 1 0 0
global (outside) 1 interface
to make the things work for you. Of course, it is possible to do reverse port
redirection, for example:
static (outside,inside) tcp 21 interface 136.1.122.20 2021
Would redirect all connections going to the firewall “inside” interface port 21 to
the outside host 136.1.122.20 port 2021. As usual, you may need an
accompanying dynamic NAT rule to complete the configuration.
4) Block translation. You can use the netmaskkeyword along with the static
statement. For example
static (inside,outside) 10.0.0.0 192.168.0.0 netmask
255.255.255.0
Will establish bi-direction mapping between the subnets 10.0.0.0/24 and
192.168.0.0/24 mapping 10.0.0.1 to 192.168.0.1 and so on.
If you havenat-controlenabled in the firewall, you might need “identity”
statements like:
static (inside,outside) 10.0.0.0 10.0.0.0 netmask
255.255.255.0
to permit anyone accessing the inside network 10.0.0.0/24 from the outside
(provided that the outside ACL permits it and network 10.0.0.0/24 is routed
across the firewall).
Note:When configuration static NAT/PAT, you must always add corresponding
outside ACL entries to permit access from the outside to the inside hosts. This
applies to any traffic that transits the firewall from lower to higher security zones.
Now a few words on “extra” parameters to the static statement.
1) The first parameter is tcp <max_conn> [<max_half_open>]which is
used as follows:
static (inside,outside) 192.168.1.100 10.0.0.100 tcp 500
100
or even without the keyword “tcp”
static (inside,outside) 192.168.1.100 10.0.0.100 500 100
This parameter is used to prevent DoS attacks against the corresponding IP
address. This is a legacy way to configure the anti-DoS settings and is now
superseded by MPF configurations. However, just FYI <max_conn>is the
maximum number of concurrent TCP connections established to the mapped IP
address. The other parameter <max_half_conn>specifies the maximum
number of allowed embryonic connections – TCP connections that have not yet
finished the 3-way TCP handshake. The goal is to prevent the resource
starvation in the protected server and protect it against SYN-flooding attack. The
default limit is set to zero for both parameters, which means unlimited number of
connections.
You may also specify the maximum number of UDP sessions per static NAT
entry, using the parameter udp <max_conn>.A UDP “session” is started once
the first UDP packet towards the host is detected, and timed out after the amount
of time specified using the command timeout udp. Of course, the preferred
way to set the maximum number of connections is using MPF.
2) The second parameter is norandomseq. By default, the firewall inspects any
TCP sessions and modifies TCP Initial Sequence Number (ISN) to a truly
random value. This is need to prevent TCP connection hijaaking when a hacker
might guess the ISN and inject seemingly correct packets into TCP flow. In some
cases you may need to disable this option. Most commonly this is needed if the
TCP session header is authenticated in some way, for example using the MD5
hash option. A good example is an authenticated BGP peering session. The
other scenario is that there exist another firewall, that already has done the ISN
randomization.
This option might be selectively enabled and disabled using the MPF as well, as
we will see in special labs.
And last but not least. Static NAT configuration takes precedence other any other
form of NAT configured. Therefore, it never collides with dynamically created
NAT entries.
--->
!
! Clear the old NAT rules if any
!
! DMZ host
!
static (dmz,outside) 136.1.122.100 10.0.0.100
!
! Telnet redirection
!
static (inside,outside) tcp interface 23 136.1.121.1 23
!
! Translate inside->outside for DNS requests
!
nat (inside) 1 0 0
global (outside) 1 interface
!
!
!
clear configure access-list OUTSIDE_IN
!
! Access-list/Group to permit inbound connections
!
access-list OUTSIDE_IN extended permit ip any host 136.1.122.100
access-list OUTSIDE_IN extended permit tcp any host 136.1.122.12 eq
telnet
!
access-group OUTSIDE_IN in interface outside
!
R3#telnet 136.1.121.100
Trying 136.1.121.100 ...
% Connection timed out; remote host not responding
R3#telnet 136.1.122.100
Trying 136.1.122.100 ... Open
Password required, but none set
[Connection to 136.1.122.100 closed by foreign host]
R3#telnet 136.1.122.12
Trying 136.1.122.12 ... Open
User Access Verification
Password:
ciscoasa# sh xlate
2 in use, 2 most used
Global 136.1.122.100 Local 10.0.0.100
PAT Global 136.1.122.12(23) Local 136.1.121.1(23)
9. Configure Dynamic Policy NAT
• Clear any previous NAT rules if needed.
• Telnet connections going outside should be PAT translated using the IP
address 136.X.122.100
• ICMP packets going outside should be PAT translated using the IP
address 136.X.122.101
• Use the access-lists TELNET and ICMP to distinguish two types of traffic.
• Everything else should be PAT translated using the outside interface IP.
-->
As we have seen before, NAT rules classify input traffic based on IP addresses
solely. It is possible to add some policy decision, by using extended access-lists
with the NAT rules. A NAT rules configure with an access-list will only translate
packets matching this access-list. This allows you to define NAT translation rules
based on destination IP addresses, protocols, port numbers and so on. The
following NAT rule:
access-list HTTP_ONLY permit tcp any any eq 80
nat (inside) 1 access-list HTTP_ONLY
global (outside) 1 interface
will only PAT-translate HTTP connections going outside. Policy NAT rules take
precedence over regular NAT rules (however, static NAT/PAT is still more
preferred) and therefore you may define a number of specific policy rules
followed by a “wildcard” translation that matches all other types of traffic. Note
that the command nat (inside) 0 access-list ACLis NOT a policy NAT
rule (it is the NAT exempt rule), and will be discussed separately.
Our scenario utilizes two policy-NAT entries, defined for ICMP and telnet traffic.
There is also a wildcard rule that translates everything else. Three PAT pools are
defined for all three NAT rules.
-->
!
! Clear the old NAT rules if any
!
! Access-List to classify traffic (the policy)
!
access-list ICMP extended permit icmp any any
access-list TELNET extended permit tcp any any eq telnet
!
nat (inside) 1 access-list ICMP
nat (inside) 2 access-list TELNET
nat (inside) 3 0 0
!
! Create 3 PAT pools for each NAT rule
!
global (outside) 1 136.1.122.100
global (outside) 2 136.1.122.101
global (outside) 3 interface
!
! Permit the returning ping responses
!
access-list OUTSIDE_IN extended permit icmp any any
access-group OUTSIDE_IN in interface outside
R1#ping 136.1.122.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/40 ms
R1#telnet 136.1.122.3
Trying 136.1.122.3 ... Open
Password required, but none set
[Connection to 136.1.122.3 closed by foreign host]
R1#
ciscoasa(config)# sh xlate
1 in use, 2 most used
PAT Global 136.1.122.100(1) Local 136.1.121.1 ICMP id 0
ciscoasa(config)# sh xlate
1 in use, 2 most used
PAT Global 136.1.122.101(1024) Local 136.1.121.1(32164)
8.Configure Static NAT and PAT as per given conditions .
Clear any Previous NAT rules if needed.
• Map the DMZ IP address 10.0.0.100 to the outside 136.X.122.100.
• Configure Static PAT such that telnet sessions to the outside interface are
redirected to R1.
9. Configure Dynamic Policy NAT
• Clear any previous NAT rules if needed.
• Telnet connections going outside should be PAT translated using the IP
address 136.X.122.100
• ICMP packets going outside should be PAT translated using the IP
address 136.X.122.101
• Use the access-lists TELNET and ICMP to distinguish two types of traffic.
• Everything else should be PAT translated using the outside interface IP.
A static NAT rule establish bi-directional mapping between local and global IP
addresses. Unlike a dynamic rule, which usually maps N local addresses to M
global address, where N > M, the number of global addresses equals the number
of local addresses within a static rule. Static translations are used for the
following purposes:
1) To allow accessing a server located on the inside using a fixed global (outside)
IP. The syntax would be:
static (<local-iface>,<global-iface>) <global-ip> <localip>
e.g.
static (inside,outside) 136.1.122.100 10.0.0.1
What this rules does, is establishes a bi-directional mapping between the
local-ipand the global-ip. Note that in the rule, local-ifaceis the
interface where local-ipresides, while global-ipshould either be on the
subnet shared by the global-ifaceor routed to the firewall appliance across
the global-iface. This rule also allows the inside server to initiate connections
to the outside and has its source IP translated to the global IP address. Now look
at the following “extreme” rule:
static (inside,outside) interface 10.0.0.1
What it does, is uses the global interface IP (in this case – outside) and maps it
to the local IP (10.0.0.1). Thus, all connections made to the outside IP of the ASA
are redirected to the internal server. Of course, they should be permitted with an
ACL prior to that. This will disable any services that ASA runs on the outside
interface, by the way.
2) To redirect a particular port at the global IP to the port at the inside IP (aka
Static PAT or port redirection). The syntax is:
static (<local-iface>,<global-iface>) {tcp|udp} <global-ip>
<port> <local-ip> <port>.
e.g.
static (inside,outside) tcp 136.1.122.100 80 10.0.0.1 8080
would redirect all connections going to 136.1.122.100 port 80 to the inside IP
10.0.0.1 port 8080. You would usually use this rule when you have little or just
one global IP address and would like to multiplex different services (e.g. FTP,
WWW, DNS) between different internal services. It is also possible to redirect
connections going to the ASA’s own interface:
static (inside,outside) tcp interface 80 10.0.0.1 80
static (inside,outside) tcp interface 21 10.0.0.2 21
This is a common construct when you only have a single global IP address
assigned to the outside interface of the firewall. Note that static PAT does not
allow the internal server to access the internal using the global IP address. You
must define a dynamic NAT rule in order to allow the internal server to initiate
connections on its own. For example:
static (inside,outside) tcp interface 80 10.0.0.1
nat (inside) 1 10.0.0.0 255.255.255.0
global (outside) 1 interface
This configuration allows any host on the inside to access the outside by having
their source addresses translated using the firewall’s outside IP. At the same
time, connections to the firewall’s outside interface port 80 are redirected to the
server with the IP 10.0.0.1
3) Reverse redirection. Sometimes, you may want to redirect a connection going
to an inside host to some outside destination. This is often called “routing
simplification”, as it might be used in situations where inside hosts lack routing
information, e.g. have no default gateway set, or have the default route pointing
toward some other router (not the firewall).
For example, imagine you have a DNS server on the outside with the IP address
136.1.122.200 but you want the inside hosts to use the IP 10.0.0.200 to access
the DNS server (e.g. the hosts have no default gateway set). The following
“reverse” construct (local and global interfaces are “swapped”) would achieve the
goal:
static (outside,inside) 10.0.0.200 136.1.122.200
The firewall will do Proxy-ARP for the IP address 10.0.0.200 on its inside
interface, provided that 10.0.0.0/XX is the inside’s interface subnet. In other
cases, this subnet should be explicitly routed to the firewall. Remember, that the
inside hosts most likely need their sources translated when accessing the outside
DNS. Thus, you may need to add a dynamic NAT rule as well:
nat (inside) 1 0 0
global (outside) 1 interface
to make the things work for you. Of course, it is possible to do reverse port
redirection, for example:
static (outside,inside) tcp 21 interface 136.1.122.20 2021
Would redirect all connections going to the firewall “inside” interface port 21 to
the outside host 136.1.122.20 port 2021. As usual, you may need an
accompanying dynamic NAT rule to complete the configuration.
4) Block translation. You can use the netmaskkeyword along with the static
statement. For example
static (inside,outside) 10.0.0.0 192.168.0.0 netmask
255.255.255.0
Will establish bi-direction mapping between the subnets 10.0.0.0/24 and
192.168.0.0/24 mapping 10.0.0.1 to 192.168.0.1 and so on.
If you havenat-controlenabled in the firewall, you might need “identity”
statements like:
static (inside,outside) 10.0.0.0 10.0.0.0 netmask
255.255.255.0
to permit anyone accessing the inside network 10.0.0.0/24 from the outside
(provided that the outside ACL permits it and network 10.0.0.0/24 is routed
across the firewall).
Note:When configuration static NAT/PAT, you must always add corresponding
outside ACL entries to permit access from the outside to the inside hosts. This
applies to any traffic that transits the firewall from lower to higher security zones.
Now a few words on “extra” parameters to the static statement.
1) The first parameter is tcp <max_conn> [<max_half_open>]which is
used as follows:
static (inside,outside) 192.168.1.100 10.0.0.100 tcp 500
100
or even without the keyword “tcp”
static (inside,outside) 192.168.1.100 10.0.0.100 500 100
This parameter is used to prevent DoS attacks against the corresponding IP
address. This is a legacy way to configure the anti-DoS settings and is now
superseded by MPF configurations. However, just FYI <max_conn>is the
maximum number of concurrent TCP connections established to the mapped IP
address. The other parameter <max_half_conn>specifies the maximum
number of allowed embryonic connections – TCP connections that have not yet
finished the 3-way TCP handshake. The goal is to prevent the resource
starvation in the protected server and protect it against SYN-flooding attack. The
default limit is set to zero for both parameters, which means unlimited number of
connections.
You may also specify the maximum number of UDP sessions per static NAT
entry, using the parameter udp <max_conn>.A UDP “session” is started once
the first UDP packet towards the host is detected, and timed out after the amount
of time specified using the command timeout udp. Of course, the preferred
way to set the maximum number of connections is using MPF.
2) The second parameter is norandomseq. By default, the firewall inspects any
TCP sessions and modifies TCP Initial Sequence Number (ISN) to a truly
random value. This is need to prevent TCP connection hijaaking when a hacker
might guess the ISN and inject seemingly correct packets into TCP flow. In some
cases you may need to disable this option. Most commonly this is needed if the
TCP session header is authenticated in some way, for example using the MD5
hash option. A good example is an authenticated BGP peering session. The
other scenario is that there exist another firewall, that already has done the ISN
randomization.
This option might be selectively enabled and disabled using the MPF as well, as
we will see in special labs.
And last but not least. Static NAT configuration takes precedence other any other
form of NAT configured. Therefore, it never collides with dynamically created
NAT entries.
--->
!
! Clear the old NAT rules if any
!
! DMZ host
!
static (dmz,outside) 136.1.122.100 10.0.0.100
!
! Telnet redirection
!
static (inside,outside) tcp interface 23 136.1.121.1 23
!
! Translate inside->outside for DNS requests
!
nat (inside) 1 0 0
global (outside) 1 interface
!
!
!
clear configure access-list OUTSIDE_IN
!
! Access-list/Group to permit inbound connections
!
access-list OUTSIDE_IN extended permit ip any host 136.1.122.100
access-list OUTSIDE_IN extended permit tcp any host 136.1.122.12 eq
telnet
!
access-group OUTSIDE_IN in interface outside
!
R3#telnet 136.1.121.100
Trying 136.1.121.100 ...
% Connection timed out; remote host not responding
R3#telnet 136.1.122.100
Trying 136.1.122.100 ... Open
Password required, but none set
[Connection to 136.1.122.100 closed by foreign host]
R3#telnet 136.1.122.12
Trying 136.1.122.12 ... Open
User Access Verification
Password:
ciscoasa# sh xlate
2 in use, 2 most used
Global 136.1.122.100 Local 10.0.0.100
PAT Global 136.1.122.12(23) Local 136.1.121.1(23)
9. Configure Dynamic Policy NAT
• Clear any previous NAT rules if needed.
• Telnet connections going outside should be PAT translated using the IP
address 136.X.122.100
• ICMP packets going outside should be PAT translated using the IP
address 136.X.122.101
• Use the access-lists TELNET and ICMP to distinguish two types of traffic.
• Everything else should be PAT translated using the outside interface IP.
-->
As we have seen before, NAT rules classify input traffic based on IP addresses
solely. It is possible to add some policy decision, by using extended access-lists
with the NAT rules. A NAT rules configure with an access-list will only translate
packets matching this access-list. This allows you to define NAT translation rules
based on destination IP addresses, protocols, port numbers and so on. The
following NAT rule:
access-list HTTP_ONLY permit tcp any any eq 80
nat (inside) 1 access-list HTTP_ONLY
global (outside) 1 interface
will only PAT-translate HTTP connections going outside. Policy NAT rules take
precedence over regular NAT rules (however, static NAT/PAT is still more
preferred) and therefore you may define a number of specific policy rules
followed by a “wildcard” translation that matches all other types of traffic. Note
that the command nat (inside) 0 access-list ACLis NOT a policy NAT
rule (it is the NAT exempt rule), and will be discussed separately.
Our scenario utilizes two policy-NAT entries, defined for ICMP and telnet traffic.
There is also a wildcard rule that translates everything else. Three PAT pools are
defined for all three NAT rules.
-->
!
! Clear the old NAT rules if any
!
! Access-List to classify traffic (the policy)
!
access-list ICMP extended permit icmp any any
access-list TELNET extended permit tcp any any eq telnet
!
nat (inside) 1 access-list ICMP
nat (inside) 2 access-list TELNET
nat (inside) 3 0 0
!
! Create 3 PAT pools for each NAT rule
!
global (outside) 1 136.1.122.100
global (outside) 2 136.1.122.101
global (outside) 3 interface
!
! Permit the returning ping responses
!
access-list OUTSIDE_IN extended permit icmp any any
access-group OUTSIDE_IN in interface outside
R1#ping 136.1.122.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 136.1.122.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/40 ms
R1#telnet 136.1.122.3
Trying 136.1.122.3 ... Open
Password required, but none set
[Connection to 136.1.122.3 closed by foreign host]
R1#
ciscoasa(config)# sh xlate
1 in use, 2 most used
PAT Global 136.1.122.100(1) Local 136.1.121.1 ICMP id 0
ciscoasa(config)# sh xlate
1 in use, 2 most used
PAT Global 136.1.122.101(1024) Local 136.1.121.1(32164)
No comments:
Post a Comment