Re: Oracle listener redirect configure help

From: TeamGracie <BrianSudol_at_gmail.com>
Date: Wed, 3 Dec 2008 07:52:58 -0800 (PST)
Message-ID: <480ca022-d319-492e-a1a1-e06a17fca643@h5g2000yqh.googlegroups.com>


Hi, thanks for your response..

The reason I want to put a DNS name in the field without having the server resolve it, is because when the redirect packet hits my host, I want my host to resolve the DNS name, instead of having to use the IP listed in the hostfield (because of problems with routing).

Let me explain further:

Host A initiates a connection to ODB on destination address 192.168.1.50. The hosts packet traverses the network, and reaches a router doing nat.

That router doing nat translates 192.168.1.50 into the servers real IP 10.1.1.50.

The server sees the connection, makes the tcp 3 way handshake (passing the syn ack packet back towards the router with its real ip 10.1.1.50.... the packet hits the router, nat translation takes place and converts the real ip to 192.168.1.50 again, which is the routable ip address in this case back to our host.

The servers listener also sends its redirect packet to the host(to open up the data channel). The redirect packet contains the listeners real IP address (because the server is resolving the DNS name) as its hostfield data.

The packet is able to reach the host, and then the host processes the information in the redirect packet. Now, the host knows that it has to open up a data channel to the server on whatever the specified port is (in our example15121). The problem is, the host also reads the hostfield ip and responds on that IP (10.1.1.50) instead of the natted (and routable) 192.168.1.50 address.

Unfortunately, sqlnet fixup protocol does not make the deep packet inspection ip translation on IOS routers, however it does build the dynamic ACL for the new data channel, but that does not help this routing problem.... the root of the problem is that the host is trying to communicate on the ip address listed in the hostfield, instead of communicating on its resolved server dns name. That hostfield ip address, in this case is not routable.

A few ways to solve this I would 'think' is to be able to populate a secondary listener redirect packet hostfield with either a DNS name (which can be resolved by the host correctly) or with an IP address that the listener does not have to know about.

Has anyone else solved this problem on the oracle server side, as opposed to buying firewall equipment that deep packet inspects and changes the real IP to the NAT IP?

Also , I have tried this on my own creating secondary listeners and using the DNS name, however I was not able to get the DNS name to pass as the field in the redirect packet... the server resolves the IP address before the packet goes out. Hence, I am here to ask the experts of the community.

Thank you for any knowledge you can hit me with folks,

-BWS On Dec 2, 3:44 pm, ddf <orat..._at_msn.com> wrote:
> Comments embedded.
> On Dec 2, 3:03 pm, TeamGracie <BrianSu..._at_gmail.com> wrote:
>
> > Hello Folks,
>
> > I have a question about the Oracle listener configuration.  When a
> > listener is configured, and a DNS name is used to populate the
> > Hostfield, is it possible to put a DNS name in the hostfield, that is
> > not replaced by its resolved IP address before it leaves the server?
>
> Why would you want to do that?  Unresolved DNS names would cause the
> listener to fail as no valid adderss would exist upon which to listen
> for connections.
>
> > For instance-
> > I would like the redirect packet to contain the fields:  protocol=TCP
> > hostfield: somednsname.com port=15121
> > When the packet leaves the server and hits its host, I would like the
> > hostfield to still read the dns name, instead of the resolved IP
> > address.
>
> > Is this possible?
>
> Why?
>
> > Also, would it be possible to set up a listener to include an IP
> > address in the hostfield that is not a valid routed IP addy?  So, if I
> > wanted the redirect packet to contain an IP address that was not known
> > by the server, could I do this?
>
> No, the listener would have no valid address upon which to listen.
> Your users would likely receive a "TNS-12541: no listener" error.
>
> > Thanks for the valued info guys / gals.
>
> > -BWS
>
> Of course you could test this on your own and post the results, as
> none of us has a listener configuration to be tampered with.
>
> David Fitzjarrell
Received on Wed Dec 03 2008 - 09:52:58 CST

Original text of this message