08-18-2014 10:20 AM - edited 03-07-2019 08:25 PM
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?
Solved! Go to Solution.
08-19-2014 09:08 AM
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
08-18-2014 10:57 AM
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.
08-18-2014 11:01 AM
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...
08-18-2014 11:12 AM
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
08-18-2014 02:28 PM
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...
08-18-2014 03:10 PM
Can you ping the inside server from the ASA?
And show your whole config please.
08-19-2014 05:03 AM
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
08-19-2014 05:13 AM
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.
08-19-2014 08:22 AM
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.
08-19-2014 08:37 AM
ok, what output does the following command give:
packet-tracer input inside tcp 10.1.6.10 1234 10.1.5.100 80
08-19-2014 09:01 AM
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...
08-19-2014 09:08 AM
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
08-19-2014 09:26 AM
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?
08-19-2014 10:21 AM
> 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.
08-21-2014 01:35 AM
Thank you Karsten, now I've got it...
I've deliberately used different number of pings.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide