03-27-2008 12:23 AM
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
03-27-2008 07:44 AM
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"
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
03-28-2008 12:45 AM
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
03-29-2008 02:50 AM
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
03-31-2008 07:03 AM
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
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: