cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4126
Views
0
Helpful
52
Replies

ASA 8.3 NAT Issue

Dan Jay
Beginner
Beginner

Dear all,

I'm at my wits end, perhaps someone can take a moment to look into this.

I want to NAT one ( ! ) single inside host on a different WAN/ ISP interface ( of which I have two ) .

The first one is a /29 - adressed static SDSL 2,3 MBit link, the 2nd one a 16MBit ADSL line with one static IP.  Both interfaces are DIFFERENT carriers ( Versatel = ifname outside and Ecotel =ifname ecotel  ).

( The SDSL line is used to NAT/PAT all other hosts except the one in question. )

( Inside Userland is 172.16.0.0/24 and 192.168.20.0/24. )

Both lines are firing on all cylinders, but I can't get any traffic through the ecotel ADSL interface from the client in question.

The SDSL line works as expected.

Routing is:

C    172.16.0.0 255.255.0.0 is directly connected, inside

S    192.168.20.0 255.255.255.0 [1/0] via 172.16.1.1, inside

C    213.138.48.24 255.255.255.252 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [1/0] via 213.138.48.1, outside ( -> Versatel )

I added a 2nd default route with metric 2 pointing to the 2nd ISP, resulting in:

out  0.0.0.0         0.0.0.0         via [pppOE ServerIP according to debug output] , ecotel

interface Ethernet0/2

description Uplink Ecotel

nameif ecotel

security-level 0

pppoe client vpdn group ecotel

ip address pppoe

object network SC

host 192.168.20.4

description SC

object network SC

nat (inside,ecotel) dynamic interface dns

The packet tracer routes a simulated packet from the SC Object via inside to outside....

Can someone shed some light on this ?

1 Accepted Solution

Accepted Solutions

Wow a light bulb just clicked on. John said it. If the ASA were to translate the source to the ecotel interface ip, it would not have a route to send the traffic to after doing so.

In my opinion, you cannot do what you want to do. You have to find a different way to split the load.

eg: route 0.0.0.0 128.0.0.0 outside

     route 128.0.0.0 128.0.0.0 ecotel

I don't even know if thats going to work.

View solution in original post

52 Replies 52

JohnTylerPearce
Rising star
Rising star

object network SC

nat (inside,ecotel) dynamic interface dns

What does the 'dns' part do? Sorry, my 8.3 ASA configurations is a little iffy, I'm still use to < 8.3

If you ping an outside ip address from host 192.168.20.4, and set a capture does it show anything?

Also, do you see any active translation for that specific nat when you try?

I know you're translating 192.168.20.4 to whatever the interface of ecotel is, I'm just not sure what the 'dns'

option does.

Hi,

the problem is that the ASA doesn't support multiple default routes unless you have one as a failover backup route and the primary is tracked with IP SLA.

So it can't work to my best knowledge.

Regards.

Alain

Don't forget to rate helpful posts.

John,

thanks for your feedback. The DNS option does some mangling on the DNS record once the xlate is written . Omitting it yields no other result. So - it shouldn't have any impact on what I'm trying to piece together.

Here we go:

[capt test int ecotel tra] -> buffered

Ping from 192.168.20.4 to 194.25.2.130 :

ICMP echo request from inside:192.168.20.4 to outside:194.25.2.130 ID=768 seq=17408 len=32

( The ASA records the requests as being sent )

( The ASA records them being sent via OUTSIDE which is the wrong interface )

( The Host itself does not receive echos, but see below: )

sho capt test:

1: 14:52:10.230777 PPPoE Session ID 5346 len 10 PPP LCP: Echo Request

2: 14:52:10.238085 PPPoE Session ID 5346 len 10 PPP LCP: Echo Reply

The host STILL does not receive echos, BUT the capture records them as being RECEIVED via the ecotel interface.

Looks like these just don't find their way back somewhere in the code.

Ehm, yes.....dazed and confused.

EDIT:

to Alain: Please look at the last example in https://supportforums.cisco.com/docs/DOC-15622.

This is roughly what I'm trying to achieve, why shouldn't this be possible ?

Cadet, very well may be right. What ASA model do you have and liscense?

Can you post the configuration if your multiple default route statements and or your complete routing table?

Just make sure to sanitize the configuration so the public doesn't see anything you don't want them too.

EDIT

-------

From doing some research, it appears that you can do multiple default routes..

Sorry it's early and I'm having a retard moment.

S*   0.0.0.0 0.0.0.0 [1/0] via 213.138.48.1, outside ( -> Versatel )

Can you post the other static default route?

It seems that traffic is not using the second default route, for internet traffic.

it is a 5510 /w base LIC.

I have of course read that ISP failover isn't in our license, but that's not what I want.

192.168.20.4 is a proxy server concentrating the WWW traffic which I want to bypass the SDSL line we've outgrown.

I know that source-  / PBR isn't a job an ASA was designed to do; so why not NAT'ing a proxy to a different WAN line

when you can't separate the transport via PBR ?

I cannot paste the entire config here because of some certs in there etc., but here's what might be of interest:

ROUTING:

route outside 0.0.0.0 0.0.0.0 213.138.48.1 1

route ecotel 0.0.0.0 0.0.0.0 195.52.218.239 2

route inside 192.168.20.0 255.255.255.0 172.16.1.1 1

show asp route table:

in   255.255.255.255 255.255.255.255 identity

in   public_IP_SDSL   255.255.255.255 identity

in   172.16.1.111    255.255.255.255 identity

in   PUBLIC_IP_ADSL  255.255.255.255 identity

in   PUBLIC_IP_SDSL_CARRIER_GATEWAY 255.255.255.252 outside

in   192.168.20.0    255.255.255.0   inside

in   172.16.0.0      255.255.0.0     inside

in   0.0.0.0         0.0.0.0         outside

out  255.255.255.255 255.255.255.255 ecotel

out  224.0.0.0       240.0.0.0       ecotel

out  0.0.0.0         0.0.0.0         via PUBLIC_IP_ECOTEL_NEXT_HOP, ecotel

out  255.255.255.255 255.255.255.255 management

out  224.0.0.0       240.0.0.0       management

out  255.255.255.255 255.255.255.255 inside

out  192.168.20.0    255.255.255.0   via 172.16.1.1, inside

out  172.16.0.0      255.255.0.0     inside

out  224.0.0.0       240.0.0.0       inside

out  255.255.255.255 255.255.255.255 outside

out  PUBLIC_IP_SDSL_CARRIER_SOME_OF_THEIR_IP 255.255.255.252 outside

out  224.0.0.0       240.0.0.0       outside

out  0.0.0.0         0.0.0.0         via SDSL_CARRIER_NEXT_HOP , outside

out  0.0.0.0         0.0.0.0         via 0.0.0.0, identity

out  ::              ::              via 0.0.0.0, identity

Well, I've had a similar issue on an ASA at work. Several of our machines needed to access an outside connected, but

the default route goes out another way, in which this will not work. I can't do PBR on the ASA, so I had to add a static route, but since PBR can't be used that route is for everyone if you know what I mean.

When you ping an outside ocnnected it's going out outside because that static default route has priority.

route outside 0.0.0.0 0.0.0.0 213.138.48.1 1

route ecotel 0.0.0.0 0.0.0.0 195.52.218.239 2

From this configuration, I would think anything matched the default route would go out of interface outside and not interface ecotel. The default route for the outside interface has a better metric than the one for ecotel.

The routing table is pasted above.

The ecotel provider is interesting. They gave us a fixed IP but the protocol won't come up until I set it to negotiate ( which yields the IP they gave us ).

Once I did that, it came up and I omitted the setroute because I didn't want to mess with the main link, that is, having a new dafault WAN route screwing my setup.

Moreover, the guys refused to give me their next hop/gateway ID; I was asking them and they told me ( no joke ) it is 192....  So I looked at the interface config and it tells me that the line's remote is [NNNN] which I used as the routing target for the ADSL. ( Should I REALLY be using a different IP for that, I mean is NNNN not the required gate ?)

I agree with you that the outside metric is better ( 1 ), but how else would I tell the ASA to use another interface except from NAT which I thought would force this route because of  NAT ( srcif, dstif ) ?

Well a 192.0.0.0 is a perfectly routable address. I think what you're talking about is 192.168.0.0 255.255.0.0. The reason they gave you a fixed IP, is it's probably using DHCP, but has a reservation for the mac address of that interface, unless they gave a dhcp pool with just 1 ip address, which is possible.

I think it's the latter because they didn't know the MAC unless I switched on my modem here which wasn't supplied by them.

Well, perhaps someone else has an idea on what must be done to get it up and running.

I got an idea.....

S    192.168.20.0 255.255.255.0 [1/0] via 172.16.1.1, inside

According to that static route statement, the 192.168.20.0/24 networks is reachable via the inside interface on 172.16.1.1.

Where is the vlan interface for the 192.168.20.0/24 network? You could in theory, create a PBR on the switch with this vlan interface (if you can via IOS), for anything with a source of 192.168.20.4 and have a next hop of whatever the ecotel next hop is.

Correct me If I'm wrong guys.....

John,

this would bypass the ecotel interface again, because the ASA's default route still points to the SDSL Line....if I'm right,.

I still gaze at https://supportforums.cisco.com/docs/DOC-15622 - this would be pretty ideal if I could manage to shrink the source down to ONE certain IP but I cannot figure how to do that in 8.3.

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: