Regarding the solution to configure the server with its public IP
address as a secondary IP, the reason no-alias is required on the NAT
statement is as follows:
"When the inside global address is matched with the local interface,
NAT installs an IP alias and an ARP entry, in which case the router
will proxy-arp for these addresses. If this behavior is not wanted,
use the no-alias keyword."
So without the no-alias statement the router was responding to arp
requests for the public IP on its inside interface. So on my client
the first FTP request would work (because it would arp for and get the
proper server MAC), but then the router's arp reply would overwrite
the servers mac and subsequent packets would be sent to the router and
fail.
On Mon, Mar 1, 2010 at 7:11 AM, Gregory Gombas <ggombas_at_gmail.com> wrote:
> @Garry - I went through the INE blog, but didn't get a chance to try
> NVI. The difference between their scenario and mine, is in my scenario
> both source and destination are on the same interface.
>
> @Tolulope - I tried the scenario from the blog you mentioned, but
> could not get it to work. It seems I could get the source IP to NAT
> and was able to trick the router in sending it back to the inside
> interface, but the destination IP was not NAT'd to the proper inside
> address.
>
> @sp-ie m - You're solution worked! Its not pretty or elegant, but it works!
> One thing to note - for this to work, I needed to add the no-alias
> keyword to the NAT statement. Not sure why, but it made a difference.
> Thanks!
>
> On Sun, Feb 28, 2010 at 2:51 PM, sp-ie m <sp.ccie.me_at_gmail.com> wrote:
>> Simple solution.
>> Add the same hardcoded public IP as a secondary IP on the database server.
>> Add a route to this public IP pointing to the private IP of the database
>> server on the router.
>>
>> For Outside users, the router will de-NAT Public IP to private and pass it
>> onto the server. The fake-public-secondary-IP will not be visible to
>> internet users, its internal only to the local LAN.
>> For inside users to reach the fake-secondary public IP, use the default
>> gateway as the router. Inside users can use reach the database server either
>> on the secondary-fake-public-ip or the primary-private ip...
>> IF the users and DB server share the same subnet, the return traffic from DB
>> server will be directly sent to the users as the DB server will have a
>> connected route for the user's private IP. IF they are on different VLANs,
>> DB will route using default gateway as the router.
>>
>> On Sun, Feb 28, 2010 at 8:33 PM, Tolulope Ogunsina <togunsina_at_gmail.com>
>> wrote:
>>>
>>> Hi,
>>> I read something on this blog sometime ago which might be of help.
>>>
>>> http://ccie-in-3-months.blogspot.com/2008/12/nat-hairpinning-using-nat-pools-pbr.html
>>>
>>> HTH,
>>>
>>> On 2/28/10, Gregory Gombas <ggombas_at_gmail.com> wrote:
>>> > Here's a brain teaser for you current and aspiring CCIE's.
>>> >
>>> > I have a client which currently has a linksys router which they would
>>> > like to replace with a Cisco SR520W.
>>> >
>>> > They have a simple network with clients and servers on the same inside
>>> > network that get's NAT'd to a single public IP address on the outside
>>> > connection to the internet.
>>> >
>>> > They have a database server on the inside network that is accessible
>>> > from both the internet and inside users.
>>> > The client software has the public IP of the database hard-coded into
>>> > the application.
>>> >
>>> > Clients on the internet can access the database, but clients
>>> > internally can not. I am positive it is because the NAT fails when a
>>> > client on the inside tries to connect to the public IP of the server.
>>> >
>>> > I found this Cisco document that explains the situation perfectly. In
>>> > fact, it seems the PIX/ASA supports hairpinning using the alias
>>> > command:
>>> >
>>> > http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aee.shtml
>>> >
>>> > Question:
>>> > Is there a command on an IOS router that is similar to the PIX alias
>>> > command that would translate the destination address of the database
>>> > from the public IP to the internal IP?
>>> > If not, can this be done with some sort of NAT on a stick or policy
>>> > based routing?
>>> >
>>> > Please note: DNS doctoring, split DNS, or any manipulation of the DNS
>>> > entry would have no effect here because the public IP of the database
>>> > server is hard-coded into the client application.
>>> >
>>> > Thanks very much,
>>> > Gregory Gombas
>>> > CCIE# 19649
>>> >
>>> >
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Tolulope.
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Mon Mar 01 2010 - 09:51:36 ART
This archive was generated by hypermail 2.2.0 : Thu Apr 01 2010 - 07:26:34 ART