Copy a file using vb6 over a network through a firewall. 1

[tedsmith]

One customer of mine has a local network (not connected to the web) with a firewall around his main server.
He wants an automatic app to regularly copy files (reports) to the server.
This is no problem to me using simple vb6 routines if there was no firewall.
The single fixed port to each client is constantly open so I can't use that for transferring files.

The firewall is open to Microsoft Remote Desktop (RDP).
It is also open to only clients each with an individual fixed IP addresses with a fixed unique TCP port.
It is closed to all clients for file sharing or copying. Therefore the ordinary file copying methods in VB6 do not work.

Is it possible to use the VB6 copy routines (such as FileSystemObject) to use the same port as RDP which I believe is 3389 and how would I go about that. What if anything would I need running as a service in the server and would the RDP server app prevent this from being used by others?

I visualise something like a cut down version of RDP viewer in each client that automatically copies the filename in the command line then closes?

Alternately is there a way of simulating an automatic "cut down" version of a RDP client in vb6 using a Winsock ? Then I may not need anything extra in the server (it's RDP server has a password)
I see you can copy and paste files across the firewall once you have RDP running so I may be able on use the clipboard?

Bit tricky?

 

[mattKnight]

Change protocol and use a file tranfer one like FTP or SCP or soemthing liek that

Then talk to the network team and explain what you need from them - (for SCP you'll need TCP port 22 opened on the firewall)

Rolling your own protocol around RDP ports using VB is simply daft

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[strongm]

>Rolling your own protocol around RDP ports using VB is simply daft

Welcome to the world of ted ...

 

[tedsmith]

I really didn't want to "roll my own" if I could help it. It should be apparent from my previous posts that I am always seeking the most simple, basic way to do things as I find these usually are the most reliable particularly with a mix of OSs.

I was hoping to use existing ports that are already open on the firewall otherwise a fair bit of work is needed by the Network admins who are a Government organisation who subcontract it out to another private firm (at a cost)

So how do I use FTP at both ends from VB6 without using a Winsock anyway?
Would I simple install a third party FTP app and drive it from a Shell or is there a way of doing it in code?

Remember this has to be automatic any hour of the day 24/7 with no operator intervention.

Is there any particular port I would have to have open for FTP that would otherwise compromise security?

 

[strongm]

>Would I simple install a third party FTP

Nope. Not (always) necessary. As I'm sure we've said before.

Since XP, Windows has had an FTP server available; it just isn't installed by default.

So step 1 might be to get that component enabled/installed onto the server.

And since XP, Windows has had a (admittedly limited) built-in FTP client in the Shell, that can be called and controlled by automation hosts such as VB6.

We've previously illustrated this in this forum on a number of occasions, including 'secure' connection requiring a user name and password to connect[sup]1[/sup] (the quotes around 'secure' are because all communication is in plain text, so the level of security is debatable; the built-in client does not support SFTP or FTPS, which would both provide encryption)

In this scenario, all the networking team would need to do is open ports 20 & 21 (inbound and outbound), preferably just for the IP addresses you are communicating from. Although given that this network is not connected to the internet, opening the port(s) to all local addresses should pose a limited risk.

[sup]1[/sup]Careful here. TGML seems to have slightly mucked up the VB code in the latter part of the referenced thread.

 

[mattKnight]

the quotes around 'secure' are because all communication is in plain text, so the level of security is debatable

You are, as usual, quite correct! This is one of the reasons that I suggested SCP as an alternative.

It isn't quite as easy to implement from the code side i.e. a 3rd party component is needed (some kind of SCP server for the core server and a client for the client end) I'd suggest that the ease of firewall rules (just port TCP/22 inbound from the client) and the encrypted and authenticated nature of the protocol makes it a viable choice.



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[strongm]

>3rd party component is needed

I'm sure Ted'll be along shortly to explain how 3rd party apps are frowned upon in the environment he is working in; we've suggested this before!

 

[mattKnight]

>I'm sure Ted'll be along shortly to explain how 3rd party apps are frowned upon in the environment he is working in

Yet they're happy with unpatched XP machines, full read write access to the root of C and various other things. How unusual!

Is that the environment or by Ted himself?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[tedsmith]

Oooo! We are getting picky aren't we?
!
I don't think I ever requested advice on info on FTP in this context before - that I can remember anyway!

That environment described by Matt was the original environment I had to deal with and it was excli=usive to my system
Not any longer seeing it has been added to exponentially over the last 5 years.

The only reason they have now to tighten it up is because became it became seriously infected due to various operation staff on late night shifts watching "videos" from memory sticks to stop them going to sleep.

They are really serious now doing things like even disabling pinging between VLans and disabling USB ports with passwords.

There are now thousands of computers and devices like remote door openers, cameras fire systems all running on the main Fibre optic network and just now a special proxy server to the internet(I hate to think).

Trouble is it is now so big no one person knows what is all there and one department does one thing that often disrupts another! It is very difficult to get anything changes regarding firewall rules - I often just have to work around them.

SO YOU SHOULD BE ABLE TO SEE WHY I ASKED THE QUESTION THE WAY I DID.

Amazingly it still only take less than 1ms to ping from one end to the other!

 

[mattKnight]

>It is very difficult to get anything changes regarding firewall rules - I often just have to work around them.

My advice,

Fix the process regarding firewall rules. Don't spend hours coding

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[strongm]

>I don't think I ever requested advice on info on FTP in this context before - that I can remember anyway!

thread222-1480523

(thought I'd already posted this the other day, but it seems to have disappeared)

 

[tedsmith]

Sorry but how to implement FTP in my apps as such was not really my question as this might not be the solution to my problem anyway.
What I wanted to know was if there was a way of using the RDP port that is already opened on the firewall so I would not need to ask the administrators to change anything or install any more software in the server?

The problem using FTP on the RDP port I see is that this RDP port might not be normally available to say another set of winsocks or FTPs or whatever in my apps either end.

So if I could simulate the client end of RDP I could make use of the Microsoft RDP server at the other end without any mods in the server. Just the equivalent of cut and paste the file!

Just hoping . . .

 

[strongm]

Oh, for goodness sake, Ted. I was clearly responding here to your aside that you didn't think that you'd asked about FTP in this context before.

>The problem using FTP on the RDP port

No one has suggested this. At all. Well, apart from you ...

Still, what you can do is send data over virtual channels over RDP. You'd need to write some code for both ends of the conversation. Can this be done from VB6? Well, I've not done it myself, but it certainly looks pretty feasible. You'll have to do a little research ...

 

[dilettante]

These threads can be so amusing!

I think you can rule out RDP entirely. Even if you cobble something up using virtual channels... you need a client DLL on the client machine registered as an RDP client add-in and a server application at the server machine that you run within an RDP session after establishing one. I seriously doubt this supports unattended access without a lot of RDP finagling.


You'd be far better off simply having the server machine run a WebDAV server, either IIS or any 3rd party standalone WebDAV server. Then you need a port for HTTP (or preferably HTTPS) opened up between "client" machines and the server. If the server already runs IIS then just use existing ports.

The VB6 program can simply make use of the WebDAV Redirector in Windows, calling [tt]WNetUseConnection[/tt] (and [tt]WNetCancelConnection2[/tt]) to map and unmap a free drive letter to the WebDAV share. While mapped you can use VB6's Dir$(), DirListBox, FileListBox, Open, Close, FileCopy, Kill, etc. etc. (yes even the clunky FSO) with no problem.


Of course the "client" side of this has some limitations on the dead-and-smellier-by-the-day Windows XP because the Redirector was somewhat primitive.

 

[tedsmith]

Ho hum here we go again!

> Then you need a port for HTTP (or preferably HTTPS)
The whole point was I was looking to find a way of transferring files WITHPOUT having to sdd one extra port to the firewall.

I suspect, unless someone can come up with something else, I could add a module to all the clients to share the same single port for data and file transfer.
I can easily do this with the one winsock using techniques already well canvassed.

A cludgy alternative where I wouldn't have to modify the main client apps would be for a small extra app in each client to force close the main client app, use the same port to transfer the report file then reopen the client app!

 

[strongm]

>you need a client DLL on the client machine registered as an RDP client add-in

I'm not so sure. If you use the RDP ActiveX control or library that's already dealt with. And you can remote start the server application through your RDP session. The challenge, though, is getting the server end to do what you need; you can't use the RDP ActiveX control as the, as that is a client control, so you'd probably need to revert to the API.

Not sure it should require a whole bunch of finagling, since one of the whole points of virtual channels was to provide a secure, reliable communication channel between server and client (it is, after all, the mechanism that provides RDP's remote clipboard and remote drive capability)

 

[mattKnight]

Balls

I was wrong

A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD

More here

http://en.wikipedia.org/wiki/DHCP#DHCP_information

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.