Policy based routing or NAT/PAT

[Roger Base]

Hi Guys.

I cannot solve this by myself. So I wanna ask in this great forum.

My ASA firewall is connected to the VPN concentrator throug the ASA interface. I call the interface "DMZ". I have two insides interfaces and one interface to the internet on my ASA firewall. Right now I am routing all traffic going to 147.10.10.10 via my DMZ interface and to the VPN concentrator (with static route and with nat to the interface ip). Everything is nice until now.  But now I want to make some expections for some IP clients in my inside vlans. For instance I want to 10.5.5.5 and 10.6.6.6 to use my internet interface instead of my DMZ interface when the destionation is 147.10.10.10. Is this possible??

Thx.

HW information:

ASA 5520 7.0.(4)

VPN Concentrator

[Jouni Forss]

Hi,

You are running a very old software level on the ASA. Seems to me one of the oldest version you can run on an ASA.

That being said I am not really sure if any of the software levels of 8.2 (and below) effectively allow you to manipulate the egress interface of traffic. There are some ways but to my understanding they are limited.

The latest 8.4(x) software levels supported only on the original ASA5500 Series seem to handle pretty well with such "PBR like operation". Just lately I notice that the ASA5500-X Series had a lot of problems with this operation and it only seemed to work in 9.1(1) software.

So I would have to say that you could do this on the ASA but that would require a considerable software update which again would most likely require RAM upgrade for your ASA and also converting the current ASA configuration to the new format.

- Jouni

[Roger Base]

Let´s wait for other with more pratical experinces regarding this topic. Maybe it can be solved by easier methods..

[Jouni Forss]

Hi,

I do have plenty of practical expirience regarding this but this is mostly with the new NAT format. I just don't see a way you would be able to use the old software to match 2 different translations for the same destination NAT IP address when no single NAT configuration on the old software takes into consideration both the source and destination translation like in the new software.

Considering that ASA does not support PBR its going to be done with done with NAT if its going to be with something. The problem with your setup is the very old software. The NAT in the older software simply does not provide the same flexibility as the as the NAT in the newer software.

On the newer softwares it would not be hard to configure this at all and I have provided sample configurations for several people how to achieve this here on the forums.

I have not tried this with such an old software and software that uses the old NAT configuration format. All the configuration example I have seen so far for the old the software have all been for splitting different type (destination port/service) traffic to different interfaces on the ASA but I dont remember seeing a configuration that could handle selecting the correct destination translation based on the source address also.

The only way I could think of doing this in the old software would be that you would Static NAT the destination IP address to 2 different NAT IP address towards your LAN networks/interfaces. Then the hosts would connect to the correct NAT IP address depending on which egress interface they needed to go through but something tells me that this is really not an ideal setup (if its even possible). Or perhaps you could do a Static Identity PAT for the destination IP address and the service the users are connecting to. If connections through both links needed the same service you would have to NAT the service port also.

Again, this could be done on the newer software without any change to the actual destination address as the new NAT format provides us with a way to define both the source and destination translation in a single NAT configuration.

If you want to do it in an officially supported way you would handle this with actual PBR on a router but I would imagine this would require you to get new equipment and also modify your current network setup to accomodate it.

- Jouni

[Roger Base]

Hi Jouni,

Thx for your detailed description. I know the real PBR is not supported by ASA. The configuration looks like this right now.

I have static route telling this:

route Dmz 147.10.10.10 255.255.255.255 192.168.2.4 1 (2.4 is the VPN concentrator)

My default route is this:

route outside 0.0.0.0 0.0.0.0 192.168.100.4 1  (Internet gw)

NAT:

nat (inside) 1 10.5.5.0 255.255.255.0

global (Dmz) 1 interface

So this simple routes all traffic with destination 147.10.10.10 via Dmz interface and translate to the interface IP. So I have to find a way that can bypass this rule for specific hosts.

I will try to add this policy based NAT. But I dont think this will work because the NAT number order is higher than the exsisting one.  (Maybe I should change NAT order number with the existing one) Can this solve the problem? Will the firewall take next NAT rule if the first is not matched?

nat (inside) 100 access-list policy-based-nat1

nat (inside1) 100 access-list policy-based-nat1

global (outside) 100 80.80.80.80

access-list policy-based-nat1 extended permit ip host 10.5.5.5 host 147.10.10.10

access-list policy-based-nat1 extended permit ip host 10.6.6.6 host 147.10.10.10

access-list policy-based-nat1 extended permit ip host 10.5.5.5 host 147.10.10.10

The another way is do STATIC NAT. Static NAT will be hit before typical NAT. But if the route is pointing to the wrong interface the static NAT rule will never be hit.

[Jouni Forss]

Hi,

With the old NAT ordering Dynamic Policy PAT/NAT comes before normal Dynamic PAT/NAT in the ordering so in that sense the ID number used for the "nat" and "global" commads don't matter.

The problem is more with the fact that the ASA will check its routing table for the destination address and will always try to forward it towards the DMZ as it has the specific static route. So even if you have the Dynamic Policy PAT configuration I don't think it will ever be matched since the ASA already decides the egress interface according to the routing table.

To "fool" the ASA to forward certain destination addresses traffic towards an interface which doesnt hold the specific "route" for that destination address you would essentially have to configure a "static" command which does NAT for the IP address 147.10.10.10 towards the users interface.

The problem with this setup arises from the fact that you would need 2 different "static" commands for the destination address towards 2 different interfaces but you can't have overlapping configuration (or if its possible ASA will simply always follow the "static" command that was entered first into the configuration)

I would have to boot one of my home ASAs with the 8.2 softaware to simulate/confirm this as all the ASAs where I can freely test configurations are already running new software.

What I would personally test is for example this situation

• Destination address 147.10.10.10
• Destination service that needs to be accessed through "dmz" and "outside" is TCP/80
• Source hosts are behind "inside" interface
• We would have users that want to connect through "outside" use a destination port TCP/81

static (dmz,inside) tcp 147.10.10.10 80 147.10.10.10 80 netmask 255.255.255.255

static (outside,inside) tcp 147.10.10.10 81 147.10.10.10 80 netmask 255.255.255.255

To my understanding with the above setup we would be able to forward traffic from "inside" to both "dmz" and "outside" but the downside would be that we would have to use different destination port depending through which interface we want to connect to the host 147.10.10.10.

But as I said, I would really have to boot up an ASA with the older software to check this setup that I could confirm that the source translation is also correct done and the traffic correctly matches these configurations. Would also need to check the possiblity of configuring this as Policy PAT/NAT as I can't remember without testing would that be a possible solution.

If I were to compare this to the new softwares NAT configuration format we could actually overcome this limitation with the old NAT easily since we could define the source address in the translation also and therefore the destination address translation could overlap without problems.

Just to give you an example of the new configuration format you would be configuring this

• LAN = 10.10.10.0/24
• Host that need to use "outside" interface
  • 10.10.10.10
  • 10.10.10.20
• Destination IP = 147.10.10.10
• Translation uses the destination interface as their NAT/PAT IP address

Normal connections through DMZ

object network LAN

subnet 10.10.10.0 255.255.255.0

nat (inside,dmz) after-auto source dynamic LAN interface

Connection through OUTSIDE

object-group network SOURCE-HOSTS

network-object host 10.10.10.10

network-object host 10.10.10.20

object network HOST-147.10.10.10

host 147.10.10.10

nat (inside,outside) after-auto 1 source dynamic SOURCE-HOSTS interface destination static HOST-147.10.10.10 HOST-147.10.10.10

Though I have to say that the position/format of the above command might be different depending on the rest of the setup.

- Jouni

[Roger Base]

Hi Jouni,

What if I upgrade the ASA to 8.4 or higher and use your example. How will this solve this senaerio? I will still have static route in version .8.4.

object-group network SOURCE-HOSTS

network-object host 10.10.10.10

network-object host 10.10.10.20

object network HOST-147.10.10.10

host 147.10.10.10

nat (inside,outside) after-auto 1 source dynamic SOURCE-HOSTS interface destination static HOST-147.10.10.10 HOST-147.10.10.10

NEWS: I Just tested this commands in version 8.4. It seems that the traffic still goes throug dmz interface and not the outside interface for host .10.10.10.10 or 20. So this dosent work.

[Roger Base]

Any other suggestions??

[Jouni Forss]

Hi,

The idea with the 8.4 software is that even though the routing table information remains the same we will use NAT to first divert the traffic from the normal egress interface to the "outside" and then it will actually follow the default route for the information about the correct next-hop address.

The new NAT configuration formats configuration mentioned above should match the "destination" translation which would result in the traffic from the specified hosts being forwarded to "outside" while the others would follow the normal default route (as they would not match the special NAT configuration)

To know what the problem is in your situation I would need to know the exact software version used. Notice that this doesnt work with the first few maintanance release versions of 8.4(x) (where x is maintanance realease number). I have most commonly used 8.4(5) to test out NAT even though its not the latest 8.4 series software but with it has worked.

Your problem might also naturally be that the NAT configurations for some reason are in the wrong order and because of this the correct NAT was not matched. So I would have to see the complete configuration used to test also.

- Jouni

[Roger Base]

Hi Jouni,

I tested this with version 8.4(2).

My test config looks like this. I used another interface names but same setup. So my outside2 is actually the dmz with VPN and my Outside is the internet gw. I specified the following hosts 10.10.10.10 and 20. These should go throug the outside interface and not the outside2 as other clients. Check my packet-trace output. If the config was right the first packet trace test should go throug outside and not the outside2.

ASA84(config)# show run

: Saved

:

ASA Version 8.4(2)

!!

interface GigabitEthernet0

nameif inside

security-level 100

ip address 10.10.10.1 255.255.255.0

!

interface GigabitEthernet1

nameif outside

security-level 0

ip address 11.10.10.1 255.255.255.0

!

interface GigabitEthernet2

nameif outside2

security-level 0

ip address 12.10.10.1 255.255.255.0

!

interface GigabitEthernet3

shutdown

no nameif

no security-level

no ip address

!

interface GigabitEthernet4

shutdown

no nameif

no security-level

no ip address

!

ftp mode passive

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

object network HOST-147.10.10.10

host 147.10.10.10

object network obj-147.10.10.10

host 147.10.10.10

object network LAN

subnet 10.10.10.0 255.255.255.0

object-group network SOURCE-HOSTS

network-object host 10.10.10.10

network-object host 10.10.10.20

pager lines 24

mtu inside 1500

mtu outside 1500

mtu outside2 1500

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

!

nat (inside,outside) after-auto source dynamic SOURCE-HOSTS interface destination static HOST-147.10.10.10 HOST-147.10.10.10

nat (inside,outside2) after-auto source dynamic LAN interface

route outside 0.0.0.0 0.0.0.0 192.168.1.1 1

route outside2 147.10.10.10 255.255.255.255 192.168.1.1 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 sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

!

ASA84(config)#

--------------------------

The output of my packet traces,.

ASA84(config)#  packet-tracer input inside tcp 10.10.10.10 2222 147.10.10.10 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 outside2

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside2) after-auto source dynamic LAN interface

Additional Information:

Dynamic translate 10.10.10.10/2222 to 12.10.10.1/14131

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 20, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside2

output-status: up

output-line-status: up

Action: allow

ASA84(config)#  packet-tracer input inside tcp 10.10.10.4 2222 147.10.10.10 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 outside2

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside2) after-auto source dynamic LAN interface

Additional Information:

Dynamic translate 10.10.10.4/2222 to 12.10.10.1/41440

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 21, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside2

output-status: up

output-line-status: up

Action: allow

ASA84(config)#

This is the result if I remove the default route to the 147.10.10.10

ASA84(config)#  packet-tracer input inside tcp 10.10.10.10 2222 147.10.10.10 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) after-auto source dynamic SOURCE-HOSTS interface destination static HOST-147.10.10.10 HOST-147.10.10.10

Additional Information:

Dynamic translate 10.10.10.10/2222 to 11.10.10.1/26631

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 26, 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

[Jouni Forss]

Hi,

If you have a test firewall available as it seems I would suggest booting it to 8.4(5) and do the same tests.

I don't think this works in the 8.4(2) software at all.

The strange thing with this type of NAT configurations is that they seem to behave differently even though the documentation would seem to suggest that this should apply to all softwares 8.4(2) and above yet it does not seem to act that way.

Here are some quotes from the Configuration Guide

 Determining the Egress Interface 
 When the ASA receives traffic for a mapped  address, the ASA unstranslates the destination address according to the  NAT rule, and then it sends the packet on to the real address. The ASA  determines the egress interface for the packet in the following ways: 
 •Routed mode—The ASA determines the egress interface in one of the following ways: 
 –You  configure the interface in the NAT rule—The ASA uses the NAT rule to  determine the egress interface. However, you have the option to always  use a route lookup instead. In certain scenarios, a route lookup  override is required; for example, see the "NAT and VPN Management Access" section. 
 –You do not configure the interface in the NAT rule—The ASA uses a route lookup to determine the egress interface. 

So considering the above its my understanding that when the "destination" IP address of a connection coming to the ASA is a mapped IP address in the ASA NAT configuration and the "destination" interface is specified in the NAT command (instead of using "any") then the ASA will UN-NAT/Untranslate the "destination" IP address and choose the egress interface according to the NAT configuration. In some softwares this works like a charm while in other it simply does not work and the ASA always performs a route-lookup which essentially prevents this from working.

- Jouni

[Roger Base]

Hi again. Just tested on 8.4(7)3 and the result is the same. Check the result (inside_test is inside, outside1_test is internet gw, outside2_test is the VPN gw) Both packet trace gave the same result. The traffic is going out on interface outside2_test wich is the VPN GW even if I source from 10.10.10.11 wich should go throug outside1_test. So it dosent work on 8.4(7)3 either.

If I remove the first NAT statment nat (inside_test,outside2_test) after-auto source dynamic LAN interface and try to run the packet trace again. The second NAT statement dosent seem to be matched. Check TEST3. Something is telling me that there are something wrong with this statement "nat (inside_test,outside1_test) after-auto 1 source dynamic SOURCE-HOSTS interface destination static HOST-147.10.10.10 HOST-147.10.10.10"

TEST1:

(config)# packet-tracer input inside_test tcp 10.10.10.11 5555 147.10.$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 outside2_test

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group permit in interface inside_test

access-list permit extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside_test,outside2_test) after-auto source dynamic LAN interface

Additional Information:

Dynamic translate 10.10.10.11/5555 to 12.10.10.10/5555

Phase: 5

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside_test,outside2_test) after-auto source dynamic LAN interface

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 334, packet dispatched to next module

Result:

input-interface: inside_test

input-status: up

input-line-status: up

output-interface: outside2_test

output-status: up

output-line-status: up

Action: allow

TEST2:

(config)# packet-tracer input inside_test tcp 10.10.10.44 5555 147.10.$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 outside2_test

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group permit in interface inside_test

access-list permit extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside_test,outside2_test) after-auto source dynamic LAN interface

Additional Information:

Dynamic translate 10.10.10.44/5555 to 12.10.10.10/5555

Phase: 5

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside_test,outside2_test) after-auto source dynamic LAN interface

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 341, packet dispatched to next module

Result:

input-interface: inside_test

input-status: up

input-line-status: up

output-interface: outside2_test

output-status: up

output-line-status: up

Action: allow

TEST3:

packet-tracer input inside_test tcp 10.10.10.11 5555 147.10.$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 outside2_test

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group permit in interface inside_test

access-list permit extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 374, packet dispatched to next module

Result:

input-interface: inside_test

input-status: up

input-line-status: up

output-interface: outside2_test

output-status: up

output-line-status: up

Action: allow

[Jouni Forss]

Hi,

Think I need to do some more reading.

It seems to me that if I configure the "nat" with the "after-auto" paramater which moves it to Section 3 of the NAT rules (the lowest priority) then it seems that the ASA completely ignores the configuration as you saw also. Though I have previously always done this without the "after-auto" and havent tested it with that before this time.

If I were to remove the "after-auto" and use the "nat" command without I get the desired result. Then the destination IP address of the packet is matched to the "nat" configuration and forwarded accordingly

Here is a sample configuration from my own firewall. Again interfaces are used for different purposes that dont quite describe the situation.

interface Vlan1

description LAN

nameif LAN

security-level 100

ip address 10.0.10.2 255.255.254.0

!

interface Vlan10

description WAN

no forward interface Vlan20

nameif WAN

security-level 0

ip address x.x.x.x 255.255.255.248

!

interface Vlan20

description WLAN

nameif WLAN

security-level 100

ip address 10.0.255.1 255.255.255.0

route WAN 0.0.0.0 0.0.0.0 y.y.y.y 1

route LAN 10.0.0.0 255.255.255.0 10.0.10.1 1

route WLAN 147.10.10.10 255.255.255.255 10.0.255.100 1

object network DEST

host 147.10.10.10

object network SOURCE

host 10.0.0.100

nat (LAN,WAN) source dynamic SOURCE interface destination static DEST DEST

So as you can see I have 3 interfaces on the ASA and I have configured a static route for the destination IP address 147.10.10.10 through my interface WLAN. I have created "object" for the appropriate IP addresses and created the "nat" configuration.

Now if I test from a source address of 10.0.0.200 the packet should not match any NAT configuration and also should be forwarded through WLAN interface.

ASA(config)# packet-tracer input LAN tcp 10.0.0.200 12345 147.10.10.10 80

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   147.10.10.10    255.255.255.255 WLAN

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group LAN-IN in interface LAN

access-list LAN-IN extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 676109, packet dispatched to next module

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WLAN

output-status: up

output-line-status: up

Action: allow

Now when I source the traffic from the source IP address 10.0.0.100 for which we have the special configuration it seems to work just fine. It doesnt seem to work if the same NAT configuration is done at Section 3 by adding the "after-auto" parameter.

ASA(config)# packet-tracer input LAN tcp 10.0.0.100 12345 147.10.10.10 80

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (LAN,WAN) source dynamic SOURCE interface destination static DEST DEST

Additional Information:

NAT divert to egress interface WAN

Untranslate 147.10.10.10/80 to 147.10.10.10/80

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group LAN-IN in interface LAN

access-list LAN-IN extended permit ip any any

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (LAN,WAN) source dynamic SOURCE interface destination static DEST DEST

Additional Information:

Dynamic translate 10.0.0.100/12345 to x.x.x.x/12345

Phase: 5

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group WAN-OUT out interface WAN control-plane

access-list WAN-OUT extended permit ip host 10.0.0.100 any log

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (LAN,WAN) source dynamic SOURCE interface destination static DEST DEST

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 676120, packet dispatched to next module

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: allow

As you can see the packet will now match our special rule and get forwarded through completely different interface than the routing table would tell us.

In the newer ASA platform this didnt seem to work (as they dont support the 8.4 series software) but worked again on 9.1(1). When I have more time I will be testing the configurations further on the newer platforms on different software levels.

So in your test setup I would remove the special configuration and add it without the "after-auto" parameter.

- Jouni

[Roger Base]

I just try to copy paste from your config into my ASA. But still same result. Dosent work on my ASA versions. There must be a workarround for this.....

[Jouni Forss]

Hi,

Have you tried with the same software version that I was using and which I suggested earlier? The software 8.4(5)

Naturally as you can see the operation doesnt seem to be that good since on some softwares it just doesnt seem to work.

Again, a Cisco Router should easily be able to use PBR to select which traffic needs to go where and it would be something commonly used. The NAT configuration I have used to simulate this has worked fine for me but seems there quite a lot of problems if the behaviour is so drastically different depending on software.

- Jouni