-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Brown wrote:
> Hi,
> 
> As far as I have read (on the samba website), workgroups will work fine
> across subnets - as long as you have WINS working fully.  DNS will get
> you some of the way, but is not complete in itself as WINS stores a
> "type" as well as the name (so that it can distinguish between clients,
> services, master browsers, etc.).  But if you don't have WINS setup on
> every machine, or have two WINS servers on the network, things go wrong
> quickly.  The examples on the samba website (at least, the ones I looked
> at) all have a single workgroup, which is okay for me (if I had to split
> it by subnet, that would be okay too).
> 
> I'm still not quite sure what firewall and routing rules are needed
> between the networks - if anyone knows a website with a clear
> explanation I'd be glad to see it.
> 
> My understanding at the moment is that the rules for name service (nmbd)
> and sharing (smbd) are slightly different - every computer on each (LAN)
> subnet will need nmbd access (udp 137, udp 138) to the WINS server, and
> the WINS server will need the same access to each machine (since it
> needs to contact the local master browser on each subnet, which could be
> any machine).  Additionally, the domain master browser (totally
> different thing from a domain controller, even if they happen to be the
> same machine) needs the same access to the local master browsers - I'd
> use the same samba server for that as for WINS.  There is no need for
> name service access to or from servers on any network (except to and
> from the WINS server).
> 
> For the file serving (tcp 135, tcp 139, tcp 445), then access only has
> to be as one would expect for a server - if a client on Lan 1 needs
> access to a server on Lan 2, then the smb ports need to be opened for
> that route.
> 
> 
> As for the idea of a "god box" - I can sympathise somewhat.  When I
> discussed hardware for a new firewall with my local computer shop (they
> are quite good for hardware, but are solidly windows-only), their idea
> of an advanced firewall (as distinct from a ready-made appliance) was a
> large, fast server (including SCSI disks for reliability), lots of
> single-port network cards, and - wait for it - Microsoft "Internet
> Security and Acceleration" server.  Estimated hardware costs of around
> $3500 - I don't know what the software costs would be, and it was not
> exactly what I had in mind when I think of "security" !
> 
> mvh.,
> 
> David
> 
> 
> 
> 
> DarkFoon wrote:
>> I was hired to do the same thing for a small business a year ago.
>>
>> I learned about a month and a half into the project that windows shares,
>> while they work across subnets, the hostname can't be used because of
>> WINS,
>> only the IP address. Workgroups especially do not work across subnets. I
>> would like to know if DNS will work for your workgroup. I can't
>> remember if
>> I tried that, or even had the proper settings for get it to work.
>>
>> My employer's entire network was set up with a workgroup that had been
>> tweaked to act sorta like a domain. I set up a FreeBSD domain server,
>> but he
>> wanted a "god box" that was his domain server, web server,
>> firewall-which I
>> wouldn't build due to security reasons-and he had some custom server
>> software that would only work under windows, so I was let go; his son
>> can do
>> windows stuff for free.
>> Sorry, I got off topic there.
>>
>> WebDAV over https sounds like an interesting idea.
>> I hope I have been of some help.
>>
>> ----- Original Message ----- From: "David Brown" <[EMAIL PROTECTED]>
>> To: <discussion@pfsense.com>
>> Sent: Thursday, January 04, 2007 12:09 AM
>> Subject: [pfSense-discussion] Windows shares across the firewall
>>
>>
>>> I'm planning to set up a new firewall/router at our company, and am
>>> leaning towards using pfSense because I want several green networks
>>> (either using multiple ports on the firewall machine, or using a managed
>>> switch and VLANs - as far as I understand it, they can work the same
>>> way).
>>>
>>> There are going to be a couple of server machines on different branches
>>> of the LANs, but I need access to them from the other branches.  The
>>> setup I've planned looks like this:
>>>
>>>
>>> /-----------\
>>> |           |-red1----internet
>>> |  pfSense  |-red2----(second internet connection, optional)
>>> |           |
>>> |           |-orange--DMZ---web server, mail server, squid, etc.
>>> |           |
>>> |           |-blue---(wireless for laptops, including visitors)
>>> |           |               |               |            |
>>> |           |           LinkSys WRT54GL    LinkSys      LinkSys
>>> |           |            /   \              /   \        /   \
>>> |           |         laptops, etc.
>>> |           |
>>> |           |-green1---LAN (192.168.1.x)---server1.1, pc1.1, pc1.2, etc.
>>> |           |
>>> |           |-green2---LAN (192.168.2.x)---server2.1, pc2.1, pc2.2, etc.
>>> |           |
>>> |           |-green3---LAN (192.168.3.x)---server3.1, pc3.1, pc3.2, etc.
>>> |           |
>>> \-----------/
>>>
>>>
>>> Making appropriate firewall and routing rules for access to the DMZ
>>> servers from the green LANs is easy enough, as are things like allowing
>>> ssh access on different LANs for administrative purposes.  But it is
>>> also important that I can get windows share access in some way across
>>> the LANs.  For example, pc1.2 (say, 192.168.1.102) should be able to
>>> mount a share on server2.1 (192.168.2.1), while the reverse is not true
>>> (i.e., no machine on LAN2 should see the pc's on LAN1).  Is it
>>> sufficient, and safe, to simply open a pinhole for traffic on port 139
>>> towards 192.168.2.1 from 192.168.1.x ?  I suppose I could set up VPNs
>>> somewhere to tunnel traffic around, but I can't see that this would
>>> actually improve matters (I have no need to encrypt traffic passing
>>> between greens) - I would need similar rules to limit the VPN traffic.
>>> In fact, I'm assuming that once I've got things figured for cross-green
>>> routing, I can use the same sorts of rules for VPN's from laptops on the
>>> blue zone or attaching via the internet.
>>>
>>> As far as I can tell, it is only the share access that I need from the
>>> SMB/CIFS protocols.  pfSense's DNS server should be able to handle
>>> naming, and I am not running a windows domain (it's all set up as a
>>> workgroup).
>>>
>>> If I can't get a stable and secure arrangement for SMB sharing, what are
>>> my other options?  At the moment, we have a couple of linux file servers
>>> and one old windows one, which can be replaced if it is not flexible
>>> enough.  I've heard of using WebDAV as a protocol - W2K and XP (and
>>> linux, and presumably FreeBSD :-) can mount WebDAV paths, and use them
>>> directly.  If the WebDAV access is over https, then it could be used
>>> directly from outside the LANs without needing a VPN.  Another idea I
>>> have read about is using a SFTP server along with WebDrive software.
>>>
>>> Any hints, tips, website pointers, or comments about how only an idiot
>>> would arrange things like that, would be much appreciated.
>>>
>>> mvh.,
>>>
>>> David

        WINS name resolution must be done via Samba or an equivalent Windows
DNS-enabled machine, or you will have to use the full or partial DNS
qualified names in resolving servers. See
<http://lists.samba.org/archive/samba-technical/1998-August/001858.html>
for an example of what I'm referring to (discussion is a bit old, but
still applies AFAIK).
        For WINS you need (IIRC) ports 137-139, maybe (netbios stuff), and 443
(Microsoft DNS aka "mdns") to be allowed through the firewall. You need
ports 137-139 for sure with 443 for SMB/CIFS based file/printer sharing
though, along with whatever ports you have in use for mountd since RPC
uses random ports for mapping out different related services (see your
OS's documentation for that).
- -Garrett
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.1 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFnt6HEnKyINQw/HARAvySAKCH5Kc3uqEe6XMsjbrYNtPWa96J3gCfR01Z
w2SOHaT/ZC3/q6y1ubAkfn0=
=Xi0l
-----END PGP SIGNATURE-----

Reply via email to