NAT question

[kirvin1]

I'm using a 2821 router to NAT an internal server to and from the outside world. The server is running Infotreive's Ariel software on ports 419 and 422. The internal server's ip address is 10.5.0.52. It's external address is 24.x.x.11. So, when the internal server accesses the Internet it gets translated to an outside ip of 24.x.x.11. Also, when connections come in from the Internet to 24.x.x.11 those connections get translated to 10.5.0.52. All of this works correctly.

The problem comes in when an internal user tries to make a connection to 24.x.x.11 the connection fails. So, when a workstation with an address of 10.0.0.226 tries to connect to 24.x.x.11 the connection is dropped. Now, I know they should be using the internal address to access the server, but due to the way Ariel works it's not setup to work that way.

How do I setup NAt so that internal clients can access the server using it's outside nat static IP?

Is it possible to translate the destination address so that the internal clients get re-directed back to 10.5.0.52 when requesting a connection tn 24.x.x.11?

Here are some excerpts from my config that might help.

ip inspect name SDM_LOW cuseeme

ip inspect name SDM_LOW dns

ip inspect name SDM_LOW ftp

ip inspect name SDM_LOW h323

ip inspect name SDM_LOW https

ip inspect name SDM_LOW icmp

ip inspect name SDM_LOW imap

ip inspect name SDM_LOW pop3

ip inspect name SDM_LOW netshow

ip inspect name SDM_LOW rcmd

ip inspect name SDM_LOW realaudio

ip inspect name SDM_LOW rtsp

ip inspect name SDM_LOW esmtp

ip inspect name SDM_LOW sqlnet

ip inspect name SDM_LOW streamworks

ip inspect name SDM_LOW tftp

ip inspect name SDM_LOW tcp

ip inspect name SDM_LOW udp

ip inspect name SDM_LOW vdolive

interface GigabitEthernet0/1

description $ETH-WAN$$FW_OUTSIDE$

ip address 24.x.x.2 255.255.255.0

ip access-group 114 in

ip verify unicast reverse-path

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip inspect SDM_LOW out

ip virtual-reassembly

ip route-cache flow

duplex auto

speed auto

no mop enabled

interface GigabitEthernet0/0

description Connection to internal 10.x.x.x network

ip address 10.250.1.9 255.255.255.252

ip access-group 108 in

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

duplex auto

speed auto

no mop enabled

ip nat inside source list 120 interface GigabitEthernet0/1 overload

ip nat inside source static network 10.5.0.52 24.x.x.11 /32

ip nat outside source static network 24.x.x.11 10.5.0.52 /32

access-list 108 deny ip 10.250.1.4 0.0.0.3 any log

access-list 108 deny ip 24.x.x.0 0.0.0.255 any log

access-list 108 deny ip host 255.255.255.255 any log

access-list 108 deny ip 127.0.0.0 0.255.255.255 any log

access-list 108 deny tcp any any eq smtp log

access-list 108 permit ip any any

access-list 114 deny ip 10.250.1.4 0.0.0.3 any log

access-list 114 deny ip 10.250.1.8 0.0.0.3 any log

access-list 114 permit tcp any host 24.x.x.11 eq 419 log

access-list 114 permit tcp any host 24.x.x.11 eq 422 log

access-list 114 permit tcp any host 24.x.x.9 eq www log

access-list 114 permit icmp any host 24.x.x.2 echo-reply log

access-list 114 permit icmp any host 24.x.x.2 time-exceeded

access-list 114 permit icmp any host 24.x.x.2 unreachable

access-list 114 deny ip 10.0.0.0 0.255.255.255 any log

access-list 114 deny ip 172.16.0.0 0.15.255.255 any log

access-list 114 deny ip 192.168.0.0 0.0.255.255 any log

access-list 114 deny ip 127.0.0.0 0.255.255.255 any log

access-list 114 deny ip host 255.255.255.255 any log

access-list 114 deny ip host 0.0.0.0 any log

access-list 114 deny ip any any log

access-list 120 permit ip 10.0.0.0 0.31.255.255 any

access-list 120 deny ip any any log

[scottmac]

There is no way to "hairpin" back into the system.

You can put in a local DNS (local = your internal network only, and the first DNS given to the clients) with the internal IP address of your resource. That way internal clients will be directed by the DNS to the internal address.

Another option would be to add the internal resource's IP address to the client's hosts file (on XP it's located @ C:\WINDOWS\SYSTEM32\DRIVERS\ETC ... follow the example contained in hosts.sam and save the files as "hosts").

The hosts file is read before the request is sent to DNS, so the clients would find the system without the need of an additional DNS.

If you must access it through the external port, then you'll need some external resource to connect to so that you can connect from there back to the external IP address.

Maybe something like gotomypc.com would work for that, or a PC connected outside your firewall. You'll want to really lock it down though, or it's fodder for the Internet Attack gang.

Good Luck

Scott

[kirvin1]

I have an internal DNS that does just that. The problem is this Ariel program HAS to use the ip address, and it HAS to be the public 24.x.x.11 ip. Name resolution does not even take place.

[scottmac]

Maybe you can use the alias command? Are you using a PIX?

(this is the example form the PIX Command Reference):

alias (inside) 192.168.201.1 209.165.201.1 255.255.255.255

static (inside,outside) 209.165.201.1 192.168.201.1 netmask 255.255.255.255

access-list acl_out permit tcp host 192.168.201.1 host 209.165.201.1 eq ftp-data

access-group acl_out in interface outside

Good Luck

Scott

[kirvin1]

Thanks, for the help.

I'm using Cisco IOS firewall not PIX.

[sundar.palaniappan]

Hi,

Your router is dropping packets destined to the 24.x.x.11 address originated by users on the inside network as the packets arrive on the 'nat inside' interface. This is the normal behavior as the packets destined to a global NATted address cannot be coming in from an inside interface.

You can workaround this with a feature called NAT-on-a-stick. The way you do this is create a loopback interface, configure it as 'nat outside' interface and use PBR on your inside interface to cause this traffic flow to be switched to the loopback and the router would NAT the traffic originated by the inside users using the global address to the inside address local of the server. This works because PBR works prior to NATting and the router considers the packet arriving on a 'nat outisde' (loopback) interface.

I recommend you go through the following link and feel comfortable before you configure this.

Hope that helps!!

Regards,

Sundar

[sundar.palaniappan]

ooops, forgot to attach the link.

here it is.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml

[kirvin1]

Again, thanks for the help.

I configured NAT on a stick as the document suggested. It worked in that the internal connection's next-hop was altered to be the "nat outside" loopback address. Previously a working NAT translation from an external IP and the failed internal connection looked like this respectivly

Pro Inside global Inside local Outside local Outside global

tcp 24.x.x.11:419 10.5.0.52:419 24.x.167.138:3270 24.x.167.138:3270

tcp 24.x.x.2:3987 10.0.0.226:3987 24.x.x.11:419 24.x.x.11:419

the "Nat-on-a-stick" translation altered the internal connection slightly (10.250.3.1 is the lookpback address):

Pro Inside global Inside local Outside local Outside global

tcp 10.250.3.1:3987 10.0.0.226:3987 24.x.x.11:419 24.x.x.11:419

Alas, the connection was still dropped. At this point is looks to be an issue with the Ariel software itself and the way it handles NAT. It appears I will have to put this server outside the firewall; although I really hate doing that.

I think the problem is that I am trying to do 2 NAT translations with a single connection:

Tanslation #1: 10.0.0.226 NATed to 10.250.3.1 destination 24.x.x.11

Then

Translation #2: 10.250.3.1 destination 24.x.x.11 NATed to 10.5.0.52

I may be wrong but in the translation table I should see this:

Pro Inside global Inside local Outside local Outside global

tcp 10.250.3.1:3987 10.0.0.226:3987 24.x.x.11:419 24.x.x.11:419

tcp 24.x.x.11:419 10.5.0.52:419 10.250.3.1:3270 10.250.3.1:3270

But I don't see the 2nd translation taking place. Firewall logs don't show any dropped packets. I'm not going to put much more effort into getting NAT to work at this time, but If anyone has any suggestions I will try them out as the server's users would like it to work without drastically changing the server's setup.