ASA troubles

Shanman

I am still learning these ASAs and I am having a problem routing to a sub-interface. This is an added configuration I am doing and everything else is working fine. I have a default route for the main internet traffic but I need a few host routes to go out a specific subinterface (outside2) from my inside interface. I am nating. I suspect the xlate table is making the decision before the routing table does based on my reading. When I follow the packet the it picks the default route out. I would have thought it would pick the host route since it is more specific??? Can someone the knows ASAs help me understand this behavior and what changes I need to make to get the desired result. Thank you in advance.

interface Ethernet0/0
no nameif
security-level 0
no ip address
!
interface Ethernet0/0.1
description Public Facing interface
vlan 1
nameif outside
security-level 0
ip address xx.xx.xx.2 255.255.255.240
ospf cost 10
!
interface Ethernet0/0.2
shutdown
vlan 2
nameif outside2
security-level 0
ip address xx.xx.xx.18 255.255.255.248
ospf cost 10
!
interface Ethernet0/1
description Internal Facing Interface
nameif inside
security-level 100
ip address 172.19.0.2 255.255.255.248
ospf cost 10
!
static (inside,outside2) xx.xx.xx.xx device1 netmask 255.255.255.255
static (inside,outside2) xx.xx.xx.xx device2 netmask 255.255.255.255
static (inside,outside2) xx.xx.xx.xx device3 netmask 255.255.255.255
route outside 0.0.0.0 0.0.0.0 xx.xx.xx.1 1
route outside2 device1 255.255.255.255 xx.xx.xx.17 1
route outside2 device2 255.255.255.255 xx.xx.xx.17 1
route outside2 device3 255.255.255.255 xx.xx.xx.17 1
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 uauth 0:05:00 absolute

Shanman

In my config I have the outside2 shutdown. It was enabled during testing but I shut it down until I can figure this thing out. Just a heads up in case someone points that out.

instant000

I suspect the xlate table is making the decision before the routing table does based on my reading.

This is correct.

When I follow the packet the it picks the default route out. I would have thought it would pick the host route since it is more specific???

The first thing you need to learn about the ASA/PIX: It's NOT a router. The second thing you need to learn about the ASA/PIX: It's NOT a router. As such, performing routing functions comes SECONDARY to performing the FIREWALLING functions.

Can someone the knows ASAs help me understand this behavior and what changes I need to make to get the desired result

I'm not an ASA guru, but I've had to configure it a time or two

Anyway, based on your question (the configuration is practically unknown) the issue is that "ASA order of operations" is giving you some issue.

Just to confirm your fears, in the ASA, translation occurs prior to routing.

Please see this post:

https://learningnetwork.cisco.com/message/145140

There is an image in that post at the Cisco forums above. (Unfortunately, the one at the link for the original site that Mr. Barker references is dead, and gives 404.)

In my experience, the most RELIABLE way to know what an ASA is doing with a packet is to utilize the packet tracer.

Please reference this Cisco article:

Troubleshoot Connections through the PIX and ASA - Cisco Systems

The most relevant section to packet tracer is here:
Troubleshoot Connections through the PIX and ASA - Cisco Systems

Note: Web searches for packet tracer most often reveal comments about the Packet Tracer router/switch simulator application. Make sure to include "asa" in your search terms, to help narrow down the results.

Hope this helps.

Shanman

Yes this helps me to confirm what I didn't want to hear. lol Is there a way I can change the order of operations to make it go out the interface I want? If you need I can post more config for you.

neelk

If arriving packet is a part of a new connection

1- check access-list
2- route lookup
3- nat (xlate)
4- establish the session

if packet is apart of existing session

1-ip check verification
2-session lookup
3-tcp sequence number check
4-nat
5- layer 3 , 4 header adjustment

try nat
staic network 255.255.255.0
inform me the result interested

instant000

Shanman wrote: »

Yes this helps me to confirm what I didn't want to hear. lol Is there a way I can change the order of operations to make it go out the interface I want? If you need I can post more config for you.

My apologies, not on the forum for a few days.

I really don't have a clear idea of what's going on here, so this suggestion here may or may not work for your issue:

1. Backup your current configs
2. Do a "packet-tracer input inside" and see what the current result is
3. "clear xlate" and see if your problem goes away [note: this will affect current traffic flow]
4. removing one of the static translations, and see if the problem goes away (might as well "clear xlate" again here)
5. adjust from here onwards.
6. if things get out of wack, go back to original config

Not really sure what you're trying to accomplish here, so ... my help is limited

But, like the prior poster said, if there's an existing translation, it uses that one, regardless of what changes you've made in the connection since that time. So, if some changes are more recent (route changes, etc.) you might have to do a 'clear xlate" before those take effect.

jason_lunde

you will need to do some policy-nat for this to work.

Shanman

Thank you for the help. Looks like we are going to route at our ISP to the outside interface. This will eliminate all the extra configs and policy routing.