NAT and coming from the inside

[eljakimit]

Hi there,

I am trying to do something that worked out of the box on our old Netopia equipment, but does not seem to work on the SR520:

SR520 has two sides

ADSL (outside)
VLAN75 (inside)

On the inside is one webserver: 192.168.75.3

On the inside are several clients

The SR520 does NAT on port 80 to direct that traffic to the 192.168.75.3

For discussion, let's say the outside IP address is 1.2.3.4

Now, this all works great if we come from the outside; both http://1.2.3.4/ and http://domainname/

work without a hitch.

But, if a client tries to connect from the inside to http://1.2.3.4/ or http://domainname/ nothing happens.

The traffic disappears somewhere.

We were expecting this to also work (just as it did on other firewall/NAT equipment)

Is there anybody with an answer to this question?

Eljakim

[addis]

This is a potentially tricky scenario.

IP transactions are processed differently depending upon whether the packet is going inside to outside or outside to inside.

Inside to outside translation occurs after routing.

Outside to inside translation occurs before routing.

There is a chance that a routing problem exist before a translation occurs.

You may try:

(1) show ip route   ---   Make sure the routing tables seem correct

(2) show ip nat translations  ---  Attempt to connect and see what translation debugs show up

This is an issue with NAT, and not the SR520 specifically.

[eljakimit]

The contents of the routing table:

SR520#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C    192.168.75.0/24 is directly connected, Vlan75
S    192.168.10.0/24 [1/0] via 192.168.75.9
     195.190.249.0/32 is subnetted, 1 subnets
C       195.190.249.28 is directly connected, Dialer0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.1.10.0 [1/0] via 192.168.75.9
S       10.1.1.0 [1/0] via 192.168.75.9
     OUR_IP_NET/32 is subnetted, 1 subnets
C       OUR_IP_ADDRESS is directly connected, Dialer0
S*   0.0.0.0/0 is directly connected, Dialer0

[eljakimit]

And the contents of the nat translation table.

This is while doing two things:

1) making a connection from an outside server to our IP address on :22

2) making a connection from an inside machine to our IP address on :22

The inside machine is 192.168.75.14

The :22 NAT mapping goes to 192.168.75.3

I have removed our IP addresses from the list, and only the :22 lines are shown.

Is this a firewall issue somehow? Is the firewall blocking the connection from inside to inside?

Eljakim

SR520#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp OUR_IP:22  192.168.75.3:22    192.168.75.14:2162 192.168.75.14:2162
tcp OUR_IP:22  192.168.75.3:22    OUTSIDE_SERVER:44049 OUTSIDE_SERVER:44049
tcp OUR_IP:22  192.168.75.3:22    ---                ---

[Darryl Tyson]

Eljakim,

On the Domain name issue, sounds like you are after a DNS rewrite.  I think this is supported on NAT commands not PAT Commands.  You would have to use

ip nat inside source static ip 192.168.75.3 interface Dialer0 (or similar)

instead of:

ip nat inside source static tcp 192.168.75.3 80 interface Dialer0 80

ip nat inside source static tcp 192.168.75.3 22 interface Dialer0 22

this I am sure will have other repercussions.

Cheers

Darryl.

[eljakimit]

Hi Darryl,

it's not a domain name rewrite that I want to do! And I definitely don't want all traffic

to go to 192.168.75.3.

I just don't want my users to have to remember to change their settings based on

whether they're inside or outside the office.

I have a feeling that this is a firewall rule issue somehow, and that it's related

to my other issue, https://www.myciscocommunity.com/thread/1773.

Maybe it'll be resolved once I figure out how to resolve the other issue.

Eljakim

[Moderator]

Hi Eljakim,

Did you open a case from TAC as suggested on your other thread? If solving your other issue does not help this one as well, please let us know.

Thank you,

Cisco Moderation Team

[eljakimit]

Hi moderator,

unfortunately I have not been able to open a TAC case yet.  See Incident: 090311-001943 which has been open for a week now. It appears as though the web-team is unable to help with the Cisco website in making my way through it. I am still hoping for answers...

Once I have a TAC I'll let you know here. Once there is a solution, I'll also post the solution.

Eljakim

[weeksgroove]

So it sounds like this can be resolved faily quickly with some modification to your INternal DNS Server.

First, All of your clients MUST point to an internal DNS server for primary Name Resolution. If not, you need to do this.

Second.  Create a new Foreward Lookup Zone on your Internal DNS server for

Add an A record for host.domain.name and point it to 192.168.75.3.

This should fix your issue as your internal Clients will no longer try to go out to the internet and back in just to reach the server that's sittin in hte closet down the hall.  You should really never try to loop traffic like that.  It will only cause issues.

HTH

- Groove

[it]

Or if you don't have an internal DNS server or have only a few machines that need this modify the hosts file on the individual PCs

[eljakimit]

I think I'll just open a TAC.

The issue is:

a) we run no internal DNS (and don't want to go for tricks where the IP address that is returned for a domain name is different when inside the firewall compared to outside)

b) we have many different consultants running in and out of our office, so modifying the hosts file also won't work

It used to work on other platforms, so I guess it is possible.

(And yes, if I sound skeptical: last time we asked something 'hard' we received an extensive explanation

in the TAC as to why what we wanted was impossible, and that was just the way TCP/IP worked... It

turned out that it was something that worked immediately after we upgrade the SR520 firmware)

Anyway, thanks for all your reponses! Once I know how to do this I'll post a solution.

Eljakim