cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1074
Views
4
Helpful
12
Replies

NAT Problem ... Tricky one...

b.petronio
Level 3
Level 3

Hi all,

Hope someone could spend some time reading this... :)

All Clients from interface Fast0/0.6, will try to open http sessions to a Server located in Client Central Site (10.10.210.167).

All this clients will come with ip address 192.168.134.1 (they are NATed overloaded inside that network).

Im trying to change the source address of this requested packets from 192.168.134.1 to 10.64.61.2, [ip address belonging to network in F0/0.3, which is known by Central Site (routable). 192.168.134.0/28 it isnt] .

Configured :

Fas0/0.6 - NAT Inside

Tunnel 1 - NAT Outside

ip nat inside source static 192.168.134.1 10.64.61.2

It should be as simple as i did it, but the fact is that the client only pings the server, and never openned http sessions.

With a logging permit ACL, i could see the packets incoming the interface, but then, it never appears in NAT translations table, neither on "debug ip nat".

For testing purposes only, i change the source of the packet in the NAT sentence from 192.169.134.1 to 192.169.134.14, wich is the ip address of the interface Fast0/0.6, and sudently, IT WORKS.......

telnet 10.10.210.167 80 /source-interface FastEthernet0/0.6

.... Open...

Something like this...

Any ideas ???

Here is the related configuration :

** ** **

interface FastEthernet0/0.3

description -- External Clients --

bandwidth 1024

encapsulation dot1Q 3

ip address 10.64.61.254 255.255.255.0

ip wccp 61 redirect in

interface FastEthernet0/0.6 (Interface from where request are comming)

description -- Other Networks --

bandwidth 1024

encapsulation dot1Q 6

ip address 192.168.134.14 255.255.255.240

ip accounting output-packets

ip wccp 61 redirect in

ip nat inside

ip virtual-reassembly

end

interface Tunnel1 (Interface to where the requests are going)

description -- Tunel Central Site --

bandwidth 1024

ip address 10.224.8.74 255.255.255.252

ip accounting output-packets

ip mtu 1500

ip wccp 62 redirect in

ip nat outside

ip virtual-reassembly

ip summary-address eigrp 2000 10.64.60.0 255.255.252.0 5

qos pre-classify

tunnel source Loopback0

tunnel destination 10.224.0.1

end

ip nat inside source static 192.168.134.1 10.64.61.2

Best Regards,

Bruno Petrónio

1 Accepted Solution

Accepted Solutions

Edison Ortiz
Hall of Fame
Hall of Fame

So, you can ping from the source but you are unable to http from the source - have you tried any other protocol like FTP or telnet?

How about removing the WCCP from the interface and see if it helps?

Also, on the tunnel, you may be facing MTU limitations which may be causing your HTTP problem.

View solution in original post

12 Replies 12

Edison Ortiz
Hall of Fame
Hall of Fame

So, you can ping from the source but you are unable to http from the source - have you tried any other protocol like FTP or telnet?

How about removing the WCCP from the interface and see if it helps?

Also, on the tunnel, you may be facing MTU limitations which may be causing your HTTP problem.

Edison,

Thanks for your reply.

We have other clients on Fast0/0.3 network that could achieve that webserver in http sessions so i think mtu its not the problem.(althought they arent Natted)

I didnt try any others protocols, but i will ask for it.

I'll try remove the wccp redirection, and will feedback here later.

Do u see any other way to make the requested ?

Best Regards,

Bruno Petrónio

To into account the routing path, you mentioned you see no active translations when the source tries http. Does the source know to use this path in the flow when trying to reach the destination?

If you provide a diagram from src to dst it can helps us better.

I dont think i understood your question ...

The source knows for ping ... why will not know for other protocol ?

I draw a simple scheme. Hope it help understanding the network paths.

Best Regards,

Bruno Petrónio

Can we see the 'show ip nat translation' during an ICMP request and during a HTTP request?

Can you try other protocols from the source to the destination and see if they also get translated?

I wonder if the WCCP setting has something to do with this as you are redirecting web traffic to a proxy server.

___

Edison.

It works with out the wccp redirect !

Just the wccp per-si, should it work, but thinking that the packet source should be tranlated from one interface w7 ip wccp redirect to another with it the same redirect...

Fas0/0.6 -> Fas0/0.3

Man... We all need an eagle eye...

Many thanks to both for your contribution,

Bruno Petrónio

WCCP has the same function as a PBR on an interface so that gets processed before the NAT takes place and the packet was being redirected without any translation towards the web content engine.

If you want the NAT to take place along with WCCP, you may consider placing the WCCP in the egress interface with the 'out' keyword.

HTH,

__

Edison.

bflseanny
Level 1
Level 1

From observing your network diagram and comparing it to your posted configuration, something seems to be missing.

You state in the diagram that the router with an interface with IP address 192.168.134.1 is performing NAT overload for the clients behind it (x.x.x.x/y). But you did not post this config.

Since one should never assume anything, have you actually configured NAT on that router? If not, the traffic will simply be routed from client A to the F0/0.6 interface. The source IP address will be that of Host A, not 192.168.134.1.

With that being the case, the traffic will not be NATd because you have a static NAT statement that only applies to 192.168.134.1. That's why it's not showing up in the the NAT translation.

Do you have rules on your firewall on the web server side that only allow certain networks to access the web server? If so, your traffic is not getting translated from the client A to 10.64.61.2. Then the firewall won't let that HTTP traffic through.

That's my observation. What are your thoughts?

Tks Sean,

"You state in the diagram that the router with an interface with IP address 192.168.134.1 is performing NAT overload for the clients behind it (x.x.x.x/y). But you did not post this config. "

This router is not managed by me. I only ask that all the traffic from that network to came with 1 ip address, 192.168.133.1 .

The configuration placed in here, is from the router below, which has the Fas0/0.6 with ip 192.168.134.14 .

My network in Central Site, (Firewall, WeServer) dont know the network 192.168.134.x, and thats why i need to translate that source packet to one known network . In this case, 10.64.61.2 .

The main issue here is, that the NAT is performed well with the icmp packets, they reach the Webserver, and i see logs in the fw too.

When they try to open a http session, it simple dont work, and i dont even see a NAT translation. But i know that its hitting my router cause i saw with a permit ACL.

Antoher data, is that is i change the source of the test, from 192.168.134.1 to my own sub-interface ip address, and the NAT sentence of course, i could do a telnet on port 80 with source 192.168.134.14 .

Tomorrow i hope to give you more information about NAT Table.

Thank you for your time.

Bruno Petrónio

Wow! This is a good one. I just had another thought:

Could this be a DNS issue?

Have you tried having the client on the 192.168.134.x network typing in http://ipaddress_of_server instead of the domain name in the URL?

Maybe something is messed up on their local DNS server. Are they using split-brain DNS?

When they can ping successfully, are they pinging using the IP address or the domain name of the web site?

Just a thought. This post is a good learning experience. I can't wait to find out the resolution!

Was there ever a resolution to this?

Sure it was.

I've rated the right hint. ;)

It was the wccp command.

I removed the command, and it works fine.

Best Regards,

Bruno Petrónio

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco