cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
518
Views
8
Helpful
4
Replies

Mpls NAT on PE strange behaviour

csco10387876
Level 1
Level 1

Hi,

I have somthing really strange on a 7301 PE router.

1 interface is in a vrf (gre tunnel)

1 interface to the mpls core

Routes are well exchanged.

I have ip nat inside on the vrf interface and ip nat outside on the mpls interface.

Customer range is natted with 1 ip address with overload

here is the strange thing :

When the customer want to surf to a site hosted at the other end of the mpls vpn, no problem, but if he want to connect via ftp, it doesn't work.

What I see is the following, the PE doesn't do the nat translation for port tcp/21 but well for all other port.

I see traffic at the other end of the vpn with private ip adresses as source that should be natted and are indeed natted for any other port using same source destination address.

Now for the funny part, if I do a show ip nat translation vrf xxx, I see the translation (very frustating), but it is not logged in the debug ip nat.

In summary, if the customer does :

telnet x.x.x.x 80 -> nat ok

telnet x.x.x.x 21 -> nat nok

I can post some of the debug/show ip nat and config if needed.

Thanks for your help.

Luc

4 Replies 4

mheusing
Cisco Employee
Cisco Employee

Hi Luc,

Though not totally sure in your case, the usual problem with FTP and NAT is that the original FTP specification did not work with NAT enabled. The reason is, that with active FTP the server responds to a file request with packets sourced from TCP port 20 (ftp-data), for which no NAT entry exists. This has been improved by using passive FTP. There are settings f.e. in the MS Internet explorer to choose passive FTP.

If that is set correctly in the FTP client and the server "understands" passive FTP - all servers I know of do - it should work.

What is strange about your case is, that you observe that "telnet x.x.x.x 21" would not work. Does this mean no TCP handshake? Can you trace the TCP setup from a client machine (f.e. with wireshark)?

What do you mean with "I see traffic at the other end of the vpn with private ip addresses as source that should be natted ..."?

In any case, according to "Integrating NAT with MPLS VPNs"

http://www.cisco.com/en/US/docs/ios/12_4/ip_addr/configuration/guide/ntbmplsv_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1048881

there is no "ip nat outside" required. Instead a NAT virtual interface NVI0 is created doing the translation. Have a look at "NAT Virtual Interface" for further details.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html

Can you follow the configuration guide above and provide some more outputs like "show ip nat translation vrf xxx"?

Hope this helps! Please use the rating system.

Regards, Martin

Hi Martin,

"What is strange about your case is, that you observe that "telnet x.x.x.x 21" would not work. Does this mean no TCP handshake? Can you trace the TCP setup from a client machine (f.e. with wireshark)?"

Yes I used wireshar on the output point of the vpn, and there is no handshake as the source of the packet is not an official ip but it stays the private ip address.

"What do you mean with "I see traffic at the other end of the vpn with private ip addresses as source that should be natted ..."? "

well, I have wireshark running on the output segment of the vpn capturing traffic with the dest ip as filter, there if a try telnet 80 and telnet 21, I see both source ip, port 80 is natted with the official ip, port 21 not..

I will look at the NVI, but there is not specifications about how you create the equivalent of ip nat outside rules. if you have any samples for outside nat rules with the nvi it would help.

Thanks,

Luc

Hi,

An idea: traffic will only follow the default route, if no more specific route exists. Seeing unnatted traffic in the VPN could mean

a more specific route exists and thus it is not natted, as it does not go through the nat outside interface.

Regards, Martin

Hi Martin,

Thanks for your help.

I move the nat to the CE router as the answer from cisco was :

CSCsi42222

SUMMARY:

The NAT tunnel configuration is just for the outer IP header.

We don't support address translation on the inner IP header. IP NAT is called

before handing the packet over to tunnel code for de-capsulation. When

de-capsulated packet is injected back into the switching path, we can not send

it to NAT anymore.

The idea of NAT is pass-through, and NAT takes care of the outer IP header

translation. For the tunnel case, the packets are kind of initiating from the

box with one more additional IP header. NAT translation will apply to outer IP

header (The last interface) and it does not care what the inner IP header is.

In some tunnel case, the inner IP header may be encrypted.

==============================

Action Plan:

Redesign the network.

Thanks for your help

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: