Eric wrote:
> Hi,
>
> I have user's that telecommute, logging in from their home to our
> headquarters via SSH.
>
> When they connect to the office, they are
> first brought to a FBSD server that is used as a gateway that
> they log into first.
>
> They need access to files that are stored on a Linux file server. These
> are MS Word and Excel files. In the local office there is a Samba share
> in which they have a mapped drive under their Windows workstation.
>
> Is there a way to have Samba share these files to certain remote user's
> through the FBSD gateway for them to have access on their home Windows
> system?
>
> I appreciate any ideas on ways to accomplish sharing these files to
> remote user's securely.
>
> Thanks
> Eric

Yup, think tunnel (for instance:
http://www.rzg.mpg.de/networking/tunnelling.html)

Peter
--
http://www.boosten.org

Mail: peter at boosten dot org

On Wed, 14 Mar 2007 12:09:20 -0400
Eric wrote:

> I appreciate any ideas on ways to accomplish sharing these files to
> remote user's securely.

I think you need to look into ways of providing a VPN service,
probably openvpn will do the job.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

On Thu, 15 Mar 2007 05:05:04 +0000 (UTC)
nobody@nowhere.invalid (Peter Boosten) wrote:

> Eric wrote:
> > Hi,
....
> > They need access to files that are stored on a Linux file server. These
> > are MS Word and Excel files. In the local office there is a Samba share
> > in which they have a mapped drive under their Windows workstation.
....
> Yup, think tunnel (for instance:
> http://www.rzg.mpg.de/networking/tunnelling.html)

I don't think tunnelling will help here (it was my first thought)
given that the remote user is using a Windows box to connect from and I
don't think Windows will support finding a network resource through a port
listening on the same box. If the users also have a BSD/Linux/Solaris/*nix
box at home then tunnelling would be a snap but with only a Windows box I
think it's a non-starter - OTOH if there is a way I'd love to add it to my
box of tricks

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Steve O'Hara-Smith wrote:
> On Wed, 14 Mar 2007 12:09:20 -0400
> Eric wrote:
>
>> I appreciate any ideas on ways to accomplish sharing these files to
>> remote user's securely.
>
> I think you need to look into ways of providing a VPN service,
> probably openvpn will do the job.
>



So far the VPN is what I have gathered also. I'll look into the openvpn.

If this doesn't work then i may just put a small Fbsd box at the user's
home

Thanks
Eric

Begin <20070315091135.805822a0.steveo@eircom.net>
On 2007-03-15, Steve O'Hara-Smith wrote:
> I don't think tunnelling will help here (it was my first thought)
> given that the remote user is using a Windows box to connect from and
> I don't think Windows will support finding a network resource through
> a port listening on the same box.

Well, VPN comes down to tunneling in one form or another, whichever way
you look at it. As to ``finding resources'', would setting up an nmbd
and feeding your clients its address as a WINS[1] server fit the bill?


> If the users also have a BSD/Linux/Solaris/*nix box at home then
> tunnelling would be a snap but with only a Windows box I think it's a
> non-starter - OTOH if there is a way I'd love to add it to my box of
> tricks

VPN solutions often come with their own 3rd party applications because
either there is no defaullt or it is rather poor. After tweaking and
applying of service packs it seems to work in the usual cranky and
incompatible with everyone else fashion. Plus I remember the XP one had
serious performance trouble when the interface used was wireless.

If I had to I'd investigate 3rd party clients for ease of installation
and fine grained control, preferrably from the VPN server using plain
text DHCP supplied configurations. I can't say I was very charmed with
overseas people putting their pr0n down and up the corporate uplink
because they forgot to shut off the VPN link.


[1] Like CIFS, an ugly and deceitful ETLA.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Eric wrote:

> I appreciate any ideas on ways to accomplish sharing these files to
> remote user's securely.

How about them to copy their files using WinSCP or any other SCP
M$-WinSlow software?

--
Saludos,
Ángel

On Thu, 15 Mar 2007 13:57:51 -0400
Eric wrote:

> Steve O'Hara-Smith wrote:
> > On Wed, 14 Mar 2007 12:09:20 -0400
> > Eric wrote:
> >
> >> I appreciate any ideas on ways to accomplish sharing these files to
> >> remote user's securely.
> >
> > I think you need to look into ways of providing a VPN service,
> > probably openvpn will do the job.
> >
>
> So far the VPN is what I have gathered also. I'll look into the openvpn.
>
> If this doesn't work then i may just put a small Fbsd box at the user's
> home

If you do that then you can just use ssh port forwarding of course
and life is easy

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

On 15 Mar 2007 18:23:24 GMT
jpd wrote:

> Begin <20070315091135.805822a0.steveo@eircom.net>
> On 2007-03-15, Steve O'Hara-Smith wrote:
> > I don't think tunnelling will help here (it was my first thought)
> > given that the remote user is using a Windows box to connect from and
> > I don't think Windows will support finding a network resource through
> > a port listening on the same box.
>
> Well, VPN comes down to tunneling in one form or another, whichever way

Well yes but not simple port forwarding style tunneling. Although I
have seen VPN done with PPP over ssh tunnels before now.

> you look at it. As to ``finding resources'', would setting up an nmbd
> and feeding your clients its address as a WINS[1] server fit the bill?

Where would you run the nmbd ? I'm assuming that the home user has
nothing but a single Windows box and that everything but the ssh gateway in
the office is locked out.

> VPN solutions often come with their own 3rd party applications because
> either there is no defaullt or it is rather poor. After tweaking and
> applying of service packs it seems to work in the usual cranky and
> incompatible with everyone else fashion. Plus I remember the XP one had
> serious performance trouble when the interface used was wireless.

Hmm I've had only one problem with the Cisco VPN package that's
installed on my work supplied laptop running XP it just sets up something
Windows sees as a network interface and sets the routing up so that just
about everything goes through it. The problem was that the work network and
my home LAN both use the same bit of RFC1918 space so when the VPN is up
the laptop can't see my home LAN, which messes up synergy so I don't use it
often.

> If I had to I'd investigate 3rd party clients for ease of installation
> and fine grained control, preferrably from the VPN server using plain
> text DHCP supplied configurations. I can't say I was very charmed with
> overseas people putting their pr0n down and up the corporate uplink
> because they forgot to shut off the VPN link.

Always an issue with VPNs that.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Begin <20070315214817.f8a4ae3d.steveo@eircom.net>
On 2007-03-15, Steve O'Hara-Smith wrote:
> On 15 Mar 2007 18:23:24 GMT
> jpd wrote:
>> Well, VPN comes down to tunneling in one form or another, whichever way
>
> Well yes but not simple port forwarding style tunneling. Although I
> have seen VPN done with PPP over ssh tunnels before now.

You can, much like you can tunnel ``through'' ICMP or DNS traffic, but
it's better to use UDP or a specific tunnel protocol as the transport.
I've seen an example of using netgraph to cobble such a thing together.
Or IPsec, if you don't mind its particular headaches.


> Where would you run the nmbd ? I'm assuming that the home user has
> nothing but a single Windows box and that everything but the ssh gateway in
> the office is locked out.

Inside your network. Once the client can reach the nmbd it can ask
questions like, well, all the blather it'd usually shout around on the
local segment. I'd run one to cut the broadcasting a bit anyway.

Mind that VPN clients are going to find very little of the VPNed
net through broadcasting, so you're stuck with handing out various
configuration parameters some other way, like the VPN client software.


> The problem was that the work network and my home LAN both use the
> same bit of RFC1918 space so when the VPN is up the laptop can't see
> my home LAN, which messes up synergy so I don't use it often.

One reason why I intensely dislike those cheap crap router boxes that
hard-code using 192.168.1.0/24. I've heard some poor boob call it
``industry standard addresses''. That's what you get for shoving IT
services with the building maintenance. It forced me to use double-NAT
for the occasion. Only to find the cabling was at least one of overlong,
not to spec, or split-paired, as after we put a 10Mbit hub in the middle
it behaved a lot better. That 2Mbit ADSL was faster and probably less
expensive than the ISDN they were really lots more keen on letting us
use. Not to mention me then needing to find a ISDN dialup service on,
uhm, a couple of hours notice.

At home, I use a /25 in a much less used bit of the private ranges.
It's still royal overkill for the hardware I actually have operational.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 16 Mar 2007 05:02:45 GMT
jpd wrote:

> Begin <20070315214817.f8a4ae3d.steveo@eircom.net>
> On 2007-03-15, Steve O'Hara-Smith wrote:
> > On 15 Mar 2007 18:23:24 GMT
> > jpd wrote:
> >> Well, VPN comes down to tunneling in one form or another, whichever way
> >
> > Well yes but not simple port forwarding style tunneling.
> > Although I have seen VPN done with PPP over ssh tunnels before now.
>
> You can, much like you can tunnel ``through'' ICMP or DNS traffic, but
> it's better to use UDP or a specific tunnel protocol as the transport.
> I've seen an example of using netgraph to cobble such a thing together.
> Or IPsec, if you don't mind its particular headaches.

Oh sure - but if the only way through the corporate firewall is
ssh, then ssh is what you use.

> > Where would you run the nmbd ? I'm assuming that the home user
> > has nothing but a single Windows box and that everything but the ssh
> > gateway in the office is locked out.
>
> Inside your network. Once the client can reach the nmbd it can ask
> questions like, well, all the blather it'd usually shout around on the
> local segment. I'd run one to cut the broadcasting a bit anyway.

That requires another box on the home LAN yes ?

> > The problem was that the work network and my home LAN both use the
> > same bit of RFC1918 space so when the VPN is up the laptop can't see
> > my home LAN, which messes up synergy so I don't use it often.
>
> One reason why I intensely dislike those cheap crap router boxes that
> hard-code using 192.168.1.0/24. I've heard some poor boob call it
> ``industry standard addresses''. That's what you get for shoving IT
> services with the building maintenance. It forced me to use double-NAT

A common reason but not in this case, the problem is that the
internal network is very large and has grown partly by acquisitions and so
it occupies a lot of the RFC1918 space and the VPN sets up routes for a lot
(perhaps all) of the RFC1918 space.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Steve O'Hara-Smith wrote:
> On Thu, 15 Mar 2007 05:05:04 +0000 (UTC)
> nobody@nowhere.invalid (Peter Boosten) wrote:
>
>> Eric wrote:
>> > Hi,
> ...
>> > They need access to files that are stored on a Linux file server. These
>> > are MS Word and Excel files. In the local office there is a Samba share
>> > in which they have a mapped drive under their Windows workstation.
> ...
>> Yup, think tunnel (for instance:
>> http://www.rzg.mpg.de/networking/tunnelling.html)
>
> I don't think tunnelling will help here (it was my first thought)
> given that the remote user is using a Windows box to connect from and I
> don't think Windows will support finding a network resource through a port
> listening on the same box. If the users also have a BSD/Linux/Solaris/*nix
> box at home then tunnelling would be a snap but with only a Windows box I
> think it's a non-starter - OTOH if there is a way I'd love to add it to my
> box of tricks
>

It works for sure: I use putty on my Windows workstaion at work to connect to
my home network via ssh. In putty I configured a local portforwarding that
listens on port 3391. This port forward connects to a windows box in my
home network on port 3389, to facilitate a RDP connection (remote desktop).

Works perfect, I tunnel everything through my ssh. The nice thingy about
putty is that it can be tunneled over http (and thus over our proxy).

Peter

--
http://www.boosten.org

Mail: peter at boosten dot org

Steve O'Hara-Smith wrote:
> On Thu, 15 Mar 2007 13:57:51 -0400
> Eric wrote:
>
>> Steve O'Hara-Smith wrote:
>>> On Wed, 14 Mar 2007 12:09:20 -0400
>>> Eric wrote:
>>>
>>>> I appreciate any ideas on ways to accomplish sharing these files to
>>>> remote user's securely.
>>> I think you need to look into ways of providing a VPN service,
>>> probably openvpn will do the job.
>>>
>> So far the VPN is what I have gathered also. I'll look into the openvpn.
>>
>> If this doesn't work then i may just put a small Fbsd box at the user's
>> home
>
> If you do that then you can just use ssh port forwarding of course
> and life is easy
>

Looks like I have a lot to look into. I use putty myself and ssh into
the office.

So the VPN with ssh port forwarding is going to give me the capability
to see, open and save files that are on a server behind the office
gateway, leaving them store there?

The goal of course is to avoid SFTP'ing the files to the home computer
and then back again.

There's a lot of info on this thread so I'm just trying to make sense
of all of it.

Eric

On Mon, 19 Mar 2007 11:01:57 -0400
Eric wrote:

> Looks like I have a lot to look into. I use putty myself and ssh into
> the office.
>
> So the VPN with ssh port forwarding is going to give me the capability
> to see, open and save files that are on a server behind the office
> gateway, leaving them store there?

With the VPN alone you should be able to do that - it should be
pretty much as though you were on the office LAN.

With ssh and port tunneling you could set up tunnels for the ports
samba uses on a local machine and forward them to the samba server in the
office. This would then make the samba server appear to be on the home
LAN. My thought was that this would need a separate machine at home since I
didn't think a Windows box would pay attention to a samba server that
appears to be on the box itself.

I am still trying to figure out Peter Boosten's suggestion that it
is possible to do it with just the Windows box. I don't have the necessary
to try it though.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Steve O'Hara-Smith wrote:
>
> I am still trying to figure out Peter Boosten's suggestion that it
> is possible to do it with just the Windows box. I don't have the necessary
> to try it though.
>

Steve,

Here's a network drawing of my situation:

http://www.boosten.org/media/tunnel.png

On the left hand side I use my desktop on my work to create a ssh session to
my FreeBSD server (ra). For this purpose I use putty, piggybacking the ssh
protocol over http (through the proxy). So far straight forward (blue line).

In putty I defined a local port 3389, connecting to xp (the Windows XP in my
home network), again on port 3389. It's important that the FreeBSD box can
resolve the name you type in here. For this purpose I could use any local port
but your application (in my case Remote Desktop) has to be able to connect to
different ports. The red line shows the path the traffic flows. From my
work desktop however this looks like a direct connection with my home XP.

When I connect to my FreeBSD box, a local port 3389 opens. When I start
Remote Desktop on my work desktop, and connect to localhost, then Remote
Desktop connects through the ssh tunnel to xp (my home XP).

In theory you could configure putty to connect your local rpc ports (137-139)
to a machine in your central location. Your client then would make a
connection with \\localhost. There are two things to consider: the local ports
have to be closed before starting putty (that means no server service on the
windows machine, in my case no Remote Desktop allowed _to_ my work desktop).
The second 'downside' is that you can only connect to one machine in the
central location. In my case I could setup several local ports (3390, 3391)
pointing to different machines in my home network, but I don't think it's
possible to direct rpc services to other ports.

If things are still unclear, don't hesitate to contact me.

Peter

--
http://www.boosten.org

Mail: peter at boosten dot org

On Tue, 20 Mar 2007 06:53:49 +0000 (UTC)
nobody@nowhere.invalid (Peter Boosten) wrote:

> Steve O'Hara-Smith wrote:
> >
> > I am still trying to figure out Peter Boosten's suggestion that
> > it is possible to do it with just the Windows box. I don't have the
> > necessary to try it though.
> >
>
> Steve,
>
> Here's a network drawing of my situation:
>
> http://www.boosten.org/media/tunnel.png

OK that's a setup I would expect to work - and swapping out the
work side Windows XP for a Samba server would make no real difference to
this.

> In theory you could configure putty to connect your local rpc ports
> (137-139) to a machine in your central location. Your client then would
> make a connection with \\localhost.

Now that's the one I didn't think would work - not that I've tried
it. If that works then it is probably a perfect solution for the OP. Eric
give it a whirl and report back - then we'll all learn something

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/

Begin <20070316063258.eeb2cd5b.steveo@eircom.net>
On 2007-03-16, Steve O'Hara-Smith wrote:
>> Inside your network. Once the client can reach the nmbd it can ask
>> questions like, well, all the blather it'd usually shout around on the
>> local segment. I'd run one to cut the broadcasting a bit anyway.
>
> That requires another box on the home LAN yes ?

Not necessairily.


[snip!]
> A common reason but not in this case, the problem is that the
> internal network is very large and has grown partly by acquisitions and so
> it occupies a lot of the RFC1918 space and the VPN sets up routes for a lot
> (perhaps all) of the RFC1918 space.

That just means it's time to clean up the internal network. Even for
RFC1918 space you need a plan instead of using ``but it's private
space'' as an excuse to squander it frivolously. Sure, migrating
networks is a pain, but it's also a great way to correct configuration
mistakes and knock old cruft off the net. Having a freshly rolled out
well planned network is a great timesaver.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

On 27 Mar 2007 20:56:21 GMT
jpd wrote:

> [snip!]
> > A common reason but not in this case, the problem is that the
> > internal network is very large and has grown partly by acquisitions and
> > so it occupies a lot of the RFC1918 space and the VPN sets up routes
> > for a lot (perhaps all) of the RFC1918 space.
>
> That just means it's time to clean up the internal network. Even for

Heh I wouldn't disagree - but I'm not in the netops group, nor
do I want to be

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/