cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1447
Views
5
Helpful
15
Replies

Static NAT on an ASA running version 8.3 not working

Boyan Sotirov
Level 1
Level 1

I'm testing a fairly simple static NAT setup and I can't seem to get it working.

Here's the situation. I have two ASA5510 working in Active/Standby mode. It's all good, everytihng works there. This high availability cluster is connected on the inside interfaces to switches and on the outside interfaces to routers. All is working as far as IP connectivity is concerned. Here the IP setup:

interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 10.1.5.2 255.255.255.0
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 10.1.6.1 255.255.255.0
!
object network obj-10.1.6.10
 host 10.1.6.10

object network obj-10.1.6.10
 nat (inside,outside) static 149.13.0.21

So when I go on the routers, connected to the outside interfaces, and I send some traffic subject to the configured NAT - it fails:

BB2#ping 149.13.0.21

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 149.13.0.21, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

But on the ASA - the traffic is "matched" but not translated...

Rack1ASA2/NAT# show nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static obj-10.1.6.10 149.13.0.21
    translate_hits = 0, untranslate_hits = 5

So why the NAT rule does not perform any translations? Do the security levels on the ASA play any role in that?

When I initiate traffic from inside to the outside - it also fails, but there are no hits what so ever on the NAT rule.

Am I missing something?

 

1 Accepted Solution

Accepted Solutions

it shows that the ASA would use the right translation when the internal server communicates to the outside world. So lets simulate what would happen on the ASA when the traffic is coming from the outside:

packet-tracer input outside tcp 10.1.5.100 1234 149.13.0.21 80

View solution in original post

15 Replies 15

NAT is only one part of the communication. Did you allow the traffic in the Interface-ACLs? For the outside-ACL, remember that you need to configure the destination with the real IP (10.1.6.10) of the server.

Thank you for your fast response on this thread!

How do I do that? Do I need an ACL for both inside and outside interface?

Do I have to specifically allow traffic from the inside to the outside, and from the outside to the inside interface?

10.1.6.10 actually should be private (inside) address of the internal host. Maybe I've configured that wrong...

You always need an ACL to communicate from a lower to a higher security-level. So you need one for outside->inside.

Look at "sh run access-group" and you see which ACL is bound to the outside interface. There you need something like

access-list NAMEofACL ext permit icmp any object obj-10.1.6.10 echo

or

access-list NAMEofACL ext permit tcp any object obj-10.1.6.10 eq 80

 

If the above show-command also shows an ACL on the inside interface, then also an entry is needed there.

For testing with ping make sure that you have icmp-inspection enabled:

policy-map global_policy
 class inspection_default
  inspect icmp

 

As this is a test environment, I've started with an empty configuration. So ther's not ACL on any inteface.

Rack1ASA2/NAT# show running-config access-list
access-list OUTSIDE extended permit ip any object obj-10.1.6.10
access-list OUTSIDE extended permit ip any object obj-149-13-0-21

And I aplied it on the outside interface:

Rack1ASA2/NAT# show runn access-grou
access-group OUTSIDE in interface outside

But it still does not work...

Can you ping the inside server from the ASA?

And show your whole config please.

Here's the config:

ASA Version 8.3(2) <context>
!
hostname NAT
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 10.1.5.2 255.255.255.0
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 10.1.6.1 255.255.255.0
!
object network obj-10.1.6.10
 host 10.1.6.10
object network obj-149-13-0-21
 host 149.13.0.21
access-list OUTSIDE extended permit ip any object obj-10.1.6.10
access-list OUTSIDE extended permit ip any object obj-149-13-0-21
pager lines 24
mtu outside 1500
mtu inside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
!
object network obj-10.1.6.10
 nat (inside,outside) static 149.13.0.21
access-group OUTSIDE in interface outside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet timeout 5
ssh timeout 5
no threat-detection statistics tcp-intercept
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns migrated_dns_map_2
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect ip-options
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny  
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip  
  inspect xdmcp
  inspect dns migrated_dns_map_2
  inspect icmp
policy-map type inspect dns migrated_dns_map_1
 parameters
  message-length maximum client auto
  message-length maximum 512
!
service-policy global_policy global
Cryptochecksum:5a93a8ae2dd29b4ca5a8a4acc26f52d8
: end

I just realise that you have a private IP on your outside interface. That means that there is another device in front of your ASA that has to do the translation for the public address-space. There you have to configure NAT.

Or, if it is just a DSL-router, you should reconfigure that device to "bridge"-mode. Then you have the public IP on the ASA what would make all less complex. 

Karsten,

It's actually a test environment ;) But it's the way it should be.

To explain a little bit. I'm testing a scenario where I have two WAN routers, behind them two ASAs in an Active/Standby configuration, behind the ASAs - there's the local LAN.

The idea is, that the WAN routers will advertise the privat prefix over BGP to two different providers. The link between the WAN routers and ASAs will use HSRP, so that the active ASA will send over the outbound traffic to the Active HSRP router.

The idea is to have the ASA doing the NAT from the public prefix to the private one. I would like to have a redundanc and stateful NAT and I want my NAT to be independent of the WAN routers. So the link between the ASA and the WAN routers above is just an internal connection. That's where the complexity comes from... But I can't seem to get the ASA cluster doing the NAT, that's the issue here.

ok, what output does the following command give:

packet-tracer input inside tcp 10.1.6.10 1234 10.1.5.100 80

That's quite a handy command :)

Rack1ASA2/NAT# packet-tracer input inside tcp 10.1.6.10 1234 $

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10.1.5.0        255.255.255.0   outside

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4      
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
object network obj-10.1.6.10
 nat (inside,outside) static 149.13.0.21
Additional Information:
Static translate 10.1.6.10/1234 to 149.13.0.21/1234

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7      
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 17721, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

But it seems to me that in this direction - the traffic is send through the ASA, at least according to the packet-tracer...

it shows that the ASA would use the right translation when the internal server communicates to the outside world. So lets simulate what would happen on the ASA when the traffic is coming from the outside:

packet-tracer input outside tcp 10.1.5.100 1234 149.13.0.21 80

There you go...

Rack1ASA2/NAT# packet-tracer input outside tcp 10.1.5.100 123$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network obj-10.1.6.10
 nat (inside,outside) static 149.13.0.21
Additional Information:
NAT divert to egress interface inside
Untranslate 149.13.0.21/80 to 10.1.6.10/80

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE in interface outside
access-list OUTSIDE extended permit ip any object obj-10.1.6.10
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:       
Additional Information:

Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network obj-10.1.6.10
 nat (inside,outside) static 149.13.0.21
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 17973, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

 

And I found where the problem was. I fill like an idiot! The host where the translated IP address was configured - 10.1.6.10 was lacking a default gateway. It's actually a switch, and I have configured an SVI on it, just to test connectivity.

Now the translation works!

Only one thing bothers me a bit. When I ping from outside -> inside... the show nat outputs shows no translated matches:

1. Befor the ping, I have cleared the counters:

Rack1ASA2/NAT# show nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static obj-10.1.6.10 149.13.0.21
    translate_hits = 0, untranslate_hits = 0

2. Ping from outside (network 10.1.5.0/24) to inside:

BB1#ping 149.13.0.21 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 149.13.0.21, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

Rack1ASA2/NAT# show nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static obj-10.1.6.10 149.13.0.21
    translate_hits = 0, untranslate_hits = 100

3. Ping from inside to outside, with the NAT counters left as they are from 2.

Rack1ASA2-StatefulNAT-Test/NAT# show nat

Auto NAT Policies (Section 2)
1 (inside) to (outside) source static obj-10.1.6.10 149.13.0.21
    translate_hits = 5, untranslate_hits = 100

Is this something to worry about?

 

> And I found where the problem was. I fill like an idiot!

the failures that make you feel that are often the hardest to find ...

> Is this something to worry about?

The ping from inside to outside were only five pings? Then the output is perfectly fine. untranslate_hits match inboound, translate-hits match outbound.

 Thank you Karsten, now I've got it...

I've deliberately used different number of pings.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: