[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] SMB options

I can't believe you were wanting to run smb over the WAN without a vpn. But I guess it
worked for you.  Here is a suggestion.  you can use network neighbor hood/places.  In W2k
and maybe in XP you can add a network place.  With that you can set it up to use ftp or
http. If you set it up to use ftp, you can click and drag the files and folders to copy
files.  You could probably even save data from programs to the remote folders.  There are
at least 2 draw backs that I can see right off.  1. You can't map it as a disk drive.  2.
Were ever it puts you in at the ftp login is the highest, (root), directory level you will
be able to access.

I can understand way Alltel did this.  It is just an example of a provider taken control
over something they shouldn't have too in order to keep support calls down. I don't need
to do an example on this list I am sure.


> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org]On Behalf Of David
> Hamm
> Sent: Saturday, January 10, 2004 11:31 AM
> To: ale at ale.org
> Subject: [ale] SMB options
> Hello,
> I have an FTP server sittting on the Internet.  One group of users uploads
> files via FTP the other group downloads those files via SMB.  Securing SMB
> communications in most cases is handeled by listing the SMB users's IP
> address in an IPTables rule with a -j ACCEPT.  But recently I gained an SMB
> user an ALLTel's network and ALLTel blocks port 135.  The only options I can
> come up with is eithher FreeSwan or PopTop and from recent experiences I'm
> not excited about using either.  I wonder if I could run SMB on another port?
> Under Linux I don't see a problem but the Windows workstations mounting the
> share can't be modified since they also participate in an SMB based LAN.  Any
> suggestions are welcomed.
> Thanks.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale