+ Reply to Thread
Results 1 to 8 of 8

Thread: ASA troubles

  1. Senior Member Shanman's Avatar
    Join Date
    Jul 2011
    Location
    Michigan
    Posts
    223

    Certifications
    Network+, MCP (70-270), CCENT, CCNA, CCNA Security, CCNP R&S
    #1

    Default ASA troubles

    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
    Last edited by Shanman; 08-03-2012 at 03:01 PM.
    Reply With Quote Quote  

  2. SS -->
  3. Senior Member Shanman's Avatar
    Join Date
    Jul 2011
    Location
    Michigan
    Posts
    223

    Certifications
    Network+, MCP (70-270), CCENT, CCNA, CCNA Security, CCNP R&S
    #2
    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.
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    Apr 2011
    Location
    San Antonio, TX
    Posts
    1,727

    Certifications
    [Reserved]
    #3

    Default ASA order of operations

    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.
    Reply With Quote Quote  

  5. Senior Member Shanman's Avatar
    Join Date
    Jul 2011
    Location
    Michigan
    Posts
    223

    Certifications
    Network+, MCP (70-270), CCENT, CCNA, CCNA Security, CCNP R&S
    #4
    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.
    Reply With Quote Quote  

  6. Junior Member
    Join Date
    Feb 2010
    Posts
    6
    #5
    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
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    Apr 2011
    Location
    San Antonio, TX
    Posts
    1,727

    Certifications
    [Reserved]
    #6
    Quote Originally Posted by Shanman View Post
    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.
    Reply With Quote Quote  

  8. Lost in the box...
    Join Date
    Oct 2007
    Location
    OK
    Posts
    561

    Certifications
    CCIE R&S and DC, CCIP, CCNP, CCNA, CCENT, Network+, A+, MCDST, MCP, )
    #7
    you will need to do some policy-nat for this to work.
    Reply With Quote Quote  

  9. Senior Member Shanman's Avatar
    Join Date
    Jul 2011
    Location
    Michigan
    Posts
    223

    Certifications
    Network+, MCP (70-270), CCENT, CCNA, CCNA Security, CCNP R&S
    #8
    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.
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks