At 01:11 PM 7/17/2003 +0800, David Pitts wrote:
Just a bit more.
The connection is made from a client provided by the Tax Office.
Ah, a custom client for the secretive security system. That changes **everything**. Since they control both ends, they could be listening on any imaginable ports for pretty much anything they feel like. Getting this to work now becomes analogous with getting a game or a P2P application working, a process that usually involves some sort of port forwarding (DNAT'ing).
First thing to do is to see if running the client causes your workstation to start listening on some ports. Either find the equivalent of "netstat -l" for that workstation (I'm not a Windows expert, so if this is a WIndows host, get help from someone who is) or use a portacanner to check the workstation. That may give you enough information to tell you what ports need to be DNAT'd for this to work.
Next is to check your logs on Bering. As I said before, you may need to increase what you log to catch incoming packets that get dropped; offhand, I don't know if off-the-shelf Bering/Shorewall logs completely enough (or, for that matter, if you have modified its logging) to catch incoming packets to arbitrary ports.
However, on their website they say that to use the software you must have a browser capable of 128 bit SSL installed, so its possible they're using the browser protocol (HTTP?) and port.
More than possible; very likely. But this is not the tough part, since this will be outgoing traffic *to* port 443, which the firewall will NAT quite nicely. Are you certain that your system has a suitable browser installed?
I don't even know for sure that the thing will work through a NATted firewall at all.
Won't they even tell you that? Surely *that* information doesn't put their security model at risk.
NAT'ing firewalls are pretty common these days, common enough that only idiots set up systems that cannot work through them. Typically, the only protocols that have real problems with NAT'ing are ones that were in widespread use *before* NAT became common (e.g., ftp).
Since I haven't seen their client, I cannot say what it does. But reasoning by analogy to P2P applications I am familiar with, I can say it is *possible* to write an app that will not work through a NAT'ing firewall. The simplest way to do so is to have the app check the IP address of the host it runs on, and include that information as part of the transmitted *content*. At the server end, if the IP address in the content does not match the source IP address (as it won't if NAT'ing is involved), the server rejects the communication as spoofed.
(P2P clients that need to know their IP addresses typically incorporate workarounds for this problem, in the form of a way to let the user tell the app to report a different IP address from the one found on the host. This is sensible, since the authors of these apps want them to work in as many situations as possible.)
Does the lack of any relevant entries in my log (shorewall.log) mean that there is no relevant traffic being blocked? I do have some shorewall.log entries showing rejected connections. Should every rejected attempt to access any port be logged, unless there is a statement that specifically stops the logging?
What I need to know is whether the lack of logs means there is no blocking or I'm not logging the right thing.
I'm not a Shorewall user so cannot help with this part.
[old stuff deleted]
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
