Re: Not able to connect to Oracle database through VPN

On Feb 7, 11:20 am, Charles Hooper <hooperc2..._at_yahoo.com> wrote:
> On Feb 7, 8:52 am, Ravi <sainiravik..._at_gmail.com> wrote:
> > Port 1500 is open on firewall. Tnsnames entry
>
> > tv92.tcrix=
> >   (DESCRIPTION =
> >     (ADDRESS_LIST =
> >       (ADDRESS = (PROTOCOL = TCP)(HOST = 172.18.5.79)(PORT = 1500))
> >     )
> >     (CONNECT_DATA =
> >       (SERVER = DEDICATED)
> >       (SERVICE_NAME = tv92.tcrix)
> >       (INSTANCE_NAME = tv92a)
> >     )
> >   )
>
> > Please check trace file if anybody can figure out something, we are
> > facing this issue since last 3months.
>
> > *********TNSPING OUTPUT*************
> > C:\>tnsping tv92.tcrix
>
> > TNS Ping Utility for 32-bit Windows: Version 10.1.0.2.0 - Production
> > on 07-FEB-2
> > 008 19:10:51
>
> > Copyright (c) 1997, 2003, Oracle.  All rights reserved.
>
> > Used parameter files:
> > C:\oracle\product\10.1.0\Db_1\network\admin\sqlnet.ora
>
> What is the operating system of the server, and the client?
>
> Is your setup similar to this:
> (Server)-(VPN Server)-(Firewall)-(Internet)-(Firewall)-(Client)
>
> If the above is the case, the firewall on the server side will only
> see the encrypted VPN packets, which may be using UDP ports 500, 4500,
> or something else.
>
> If your setup looks like this:
> (Server)-(Firewall)-(VPN Server)-(Firewall)-(Internet)-(Firewall)-
> (Client)
>
> In the above, there is a firewall between the Oracle server and the
> VPN server, so then you will need to determine the ports that need to
> be open on that firewall to allow Oracle's packets to pass through the
> firewall for VPN connectivity.  You may also need to make certain that
> the client and server do not negotiate a different set of port numbers
> to use for communication.
>
> Have you tried using a packet capture utility on the client side?
>
> Charles Hooper
> IT Manager/Oracle DBA
> K&M Machine-Fabricating, Inc.

If your setup is like the first example, the VPN server will have a chance to encrypt all packets before they are seen by the firewall that protects your network from the Internet (the firewall will never see that TCP port 1500 is being used). In one type of VPN (IPSEC), when the packets are encrypted, the port numbers (TCP port 1500 on the database server side, and a somewhat random TCP port between [roughly] 1025 and 65535 on the server side) are translated, into UDP port 500 for both the server and client side or possibly UDP port 4500 if NAT (network address translation) exists on the client side of the Internet or the server side of the Internet. If the AH protocol is used for the VPN, it cannot survive passing through NAT, so the ESP protocol must be used instead. VPNs can be difficult to set up correctly (if that is the source of the problem), and require a good deal of network theory. The book "VPNs A Beginner's Guide" is a reasonably good source if it is a theory problem.

A packet capture program running on the client side, such as Wireshark (or Ethereal) can help determine where the problem is occuring. If you see the packets leaving the client, but responses are never returned, you can assume that there is something (possibly a firewall) between the client and the database server that is preventing either the request from the client from passing through the firewalls or the VPN, or the response from the server from passing back through the firewalls or the VPN. If you see the initial response coming back from the database server, and then the client jumps to a different set of ports when attempting to communicate with the server, but there is no response from the database server - that probably means that there is a firewall problem, likely on the client side.

You may need to use a packet trace on both the client and database server sides to determine where the communication is failing.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. Received on Fri Feb 08 2008 - 06:39:04 CST