Re: Unblocking items in firewall - Symantec AntiVirus Corporate Edition
rexdtripod_at_hotmail.com
Date: 12/22/04
- Next message: Lars M. Hansen: "Re: Saudi Arabia"
- Previous message: Charles Newman: "Re: What to do about college"
- In reply to: Arthur Hagen: "Re: Unblocking items in firewall - Symantec AntiVirus Corporate Edition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 21 Dec 2004 16:11:44 -0800
Arthur Hagen wrote:
> rexdtripod@hotmail.com wrote:
> > I sell a server based software product. I know nothing about the
> > Symantec AntiVirus Corporate Edition product but one of my
customers
> > has it installed on his network. Can the firewall component of
this
> > thing be blocking a JDBC connection attempt by my product across my
> > customer's network and not telling him so?
>
> Norton Antivirus Corporate Edition (NAV CE) is an antivirus product,
not a
> firewall. It will not block connection attempts.
>
> (The non-corporate version is a different kettle of fish, as it
proxies
> ports used for email and instant messaging. This should still not
affect
> the above situation.)
>
The user has Symantec Client FireWall Corp Edition 7.1 installed on all
of the client machines. Not being familiar with all of the Symantec
products I just assumed the antivirus and firewall were bundled. My
bad.
The user is far from me and I'm working with him by phone. He
indicates that he sees no way to view a list of items the firewall is
filtering. I've never heard of this in a firewall product. I have
asked him to try contacting the vendor. He's heard nothing yet. I
figured I'd work the groups angle too and one of us would get there.
> > The connection is being prevented and here are my troubleshooting
> > notes:
> >
> > 1. Is my JDBC connection code incorrect? No. My software product
> > has been in a few hundred shops now for a few years with no other
> > similar reports so the JDBC connection code is fine. I run the
same
> > network setup in my shop (Win 2k server and clients) and no
trouble.
>
> That something works in conditons X, Y and Z for a long time doesn't
mean it
> doesn't have a bug -- there may be trigger factors that haven't been
> encountered yet.
>
Anything is possible. Myself and another developer here (eminently
more skilled than myself) have reviewed the jdbc connection code.
Standard connect me to machine blah on port blah. Nothing special. We
are certain the problem is not there. Connects fine on this guy's
server machine, just not across his network.
> > 2. DNS issue on my customer's network? No. The user can
> > successfully ping the server machine in a DOS window using server
> > machine name. Network connectivity not the issue.
>
> A ping is (usually) ICMP traffic, which might be allowed through
firewalls
> and routers even when TCP or UDP traffic isn't. It's actually quite
common
> to be able to ping hosts you can't reach through TCP or UDP.
>
Noted. Did not know that. That level of network detail is the abyss
to me :)
> > 4. Network permissions problem? Nope. Full permissions granted
to
> > all clients on the user's network.
>
> What does permissions have to do with this? Are you using the
operating
> system's file sharing software as your transport, tunnelling JDBC
through
> it? If not, this is irrelevant.
>
Two things: I should have elaborated further here, and also I've looked
further at the situation in the interim and determined it's not a
failed jdbc connect attempt.
My client performs a file operation prior to the attempted jdbc
connection. My thought was that it may be failing at that stage
somehow due to an access issue. First part true but second part bogus.
The client app is indeed throwing while trying to open the file
containing machine name and not failing on its attempted jdbc connect
(sorry - my bad). It is not due, however, to access settings.
The client app and database app make their homes in the same directory
on the server. Nothing would work from across the network at all if
permission to the working directory was not granted. Wrong turn on my
part.
Here is what I hope is a clearer picture of the failure:
On database server start my server application queries the machine on
which it is running for it's name. It then drops a file containing
this name in its working directory. The client app is supposed to dig
the name out of this file and incorporate it into its connection url
(have to use machine name because can't assume static IP's).
The client app throws on the attempt to open the file containing
machine name (not exactly sure why just yet. Working on getting debug
logs. User is far from me. Working via phone.)
Really no reason not to be able to get at the file though. It's there
(user confirmed it's being dropped). As I mentioned, the database
server and GUI client apps share the same working directory on the
server so it's not a pathing issue. The GUI should always find the
file if it's there.
On the hundreds of other network configurations out there in which our
app is installed, the file is found and opened. On this guy's server
machine the file is found and opened. Across his network it is not.
I'm convinced it is a network or firewall issue.
> > 5. Server machine is the only one in the user's shop without the
> > Symantec AntiVirus Corporate Edition product. If I attempt the
JDBC
> > connection on that machine alone (both my client and server
components
> > running on the server machine), all works well.
>
> That's a direct connection.
>
Yes, it is. Understand, of course, I misspoke. It is the Symantec
client firewall product and not the antivirus product.
> > I think Symantec Antivirus CE won't allow my client app to
communicate
> > via JDBC across my user's network.
>
> This is almost certainly not the case.
>
> > Am I barking up the wrong tree here?
>
> Probably, yes. Do basic troubleshooting first, like trying a telnet
> connection to the port that the JDBC provider is set up to listen on.
If
> that fails and, as you say, pings work, it's most likely a firewall
issue.
>
I will have the user try this.
> Also, you need to distinguish between different types of "can not
> connect" -- is the connection *refused* or does it *time out*? And
what
> *details* do the debug logs tell you?
>
> Anyhow, since you're a sales guy, you probably should call in the
tech guys
> from your company who know how the product connects and the best way
to
> troubleshoot it.
>
Not the sales guy. I'm the developer. The sales guys are the ones
making money ;)
> Regards,
> --
> *Art
- Next message: Lars M. Hansen: "Re: Saudi Arabia"
- Previous message: Charles Newman: "Re: What to do about college"
- In reply to: Arthur Hagen: "Re: Unblocking items in firewall - Symantec AntiVirus Corporate Edition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
