Shorewall users - Nov 2002 - SMB browsing over FreeS/Wan tunnel?

Hi!

I have been able to set up FreeS/Wan in a working confirguration (yea!) :)

Everything is neatly tunneled but SMB browsing doesn''t work yet. If I
take
a linux box on either end of the tunnel and browse a client on the other 
side by parsing the destination ip to smbclient which forces it to look at 
the box on the other side I can see the shares and connect and all.

This means that the tunneling of SMB protocol is working correctly?

Don''t understand however why clients on neither side of the tunnel are 
able to see each other.

Is it because of the standard setting that all SMB chatter will be killed 
as a default by shorewall or need I do something special with Samba or 
the clients to make things work?

Couldn''t find any info relating to this on the FreeS/Wan or shorewall 
side, should it work automagically?

I have this in my policy file:
loc		vpn		ACCEPT
vpn		loc		ACCEPT
and any ''all'' rules below these 2 lines

I have put the settings for samba as described in the samba file on 
shorewall.net in my rules file, these are for fw<->loc. But as general 
policy vpn<->loc is ACCEPT I assumed no additional rules were needed?

On the remote side I use a separate gateway, only doing that, firewall and 
vpn and all servers are located elsewhere on the network. The local side 
is my home server, being firewall and SMB server, Wins server and  
everything.

Any help / input greatly appreaciated!

Remco


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

I have a WINS server on both sides of the tunnel. On my local side it is 
running on the same box as the firewall, FreeS/Wan etc. etc. On the remote 
side the WINS server is running on another box on that local net.

I don''t think that is the problem however, I suspect the problem is
that
the browsing traffic is not being sent through the vpn tunnel. (Sorry 
forgot to mention that I have a net-to-net setup in my earlier mail).

Remco

On Tue, 19 Nov 2002, Jan Johansson wrote:
> >Don''t understand however why clients on neither side of the
tunnel are
> >able to see each other.
> 
> 
> Because you need a WINS server, since SMB is a broadcast propagated
> protocol.
> 
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

> From: Remco Barendse [mailto:shorewall@barendse.to]=20
>=20
> I have a WINS server on both sides of the tunnel. On my local=20
> side it is=20
> running on the same box as the firewall, FreeS/Wan etc. etc.=20
> On the remote=20
> side the WINS server is running on another box on that local net.
do they replicate each other? IMHO its easier to use just one
WINS-Server somewhere and point every client to this one. To avoid
problems its also better not to use the VPN-Server as a WINS-Server
because FreeSWAN normally doesnt allow direct access to the opposite
VPN-Gateway. So you would take the remote one.
> I don''t think that is the problem however, I suspect the=20
> problem is that=20
> the browsing traffic is not being sent through the vpn tunnel. (Sorry=20
> forgot to mention that I have a net-to-net setup in my earlier mail).
Could be another indication that the WINS-Servers don''t replicate. I
also experienced problems with slow links (64kb), I couldn''t see the
remote network neighbourhood either, though WINS was configured
properly. But in fact its better this way, because opening the network
neighbourhood over a slow link costs you at least two coffees.
> Remco
Andreas

> From: Jan Johansson [mailto:jan.johansson@nwl.se]=20
>=20
> >do they replicate each other?=20
>=20
> Since he stated one of them runs on the FreeS/WAN box, that means a
> SAMBA server, which can''t replicated even if it wanted to :)
oops, I don''t use SAMBA for WINS-Services, so I dont know very much
about that.

but according to your statement, it can''t work for him. Each WINS has
only ''his'' hosts/workgroups/domains in its database. Or am I
wrong?

Andreas

btw: why don''t you reply to the list, it could be helpful for
everybody,
even if its OT.

could I play around with DHCP as a *very* dirty hack?

According to WINIPCFG, Winblows can contact a Primary an Secondary WINS 
server. If I pass the remote WINS servers IP to the clients as *primary* 
WINS server..... I presume the clients would try to go to the remote WINS 
server first and then to the local WINS server?

On the other hand, this might create browsing problems and slowdowns to 
browse the local net??


On Tue, 19 Nov 2002, Andreas Marbet wrote:
> > From: Remco Barendse [mailto:shorewall@barendse.to] 
> > 
> > I have a WINS server on both sides of the tunnel. On my local 
> > side it is 
> > running on the same box as the firewall, FreeS/Wan etc. etc. 
> > On the remote 
> > side the WINS server is running on another box on that local net.
> 
> do they replicate each other? IMHO its easier to use just one
> WINS-Server somewhere and point every client to this one. To avoid
> problems its also better not to use the VPN-Server as a WINS-Server
> because FreeSWAN normally doesnt allow direct access to the opposite
> VPN-Gateway. So you would take the remote one.
> 
> > I don''t think that is the problem however, I suspect the 
> > problem is that 
> > the browsing traffic is not being sent through the vpn tunnel. (Sorry 
> > forgot to mention that I have a net-to-net setup in my earlier mail).
> 
> Could be another indication that the WINS-Servers don''t replicate.
I
> also experienced problems with slow links (64kb), I couldn''t see
the
> remote network neighbourhood either, though WINS was configured
> properly. But in fact its better this way, because opening the network
> neighbourhood over a slow link costs you at least two coffees.
> 
> > Remco
> 
> Andreas
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@shorewall.net
> http://www.shorewall.net/mailman/listinfo/shorewall-users
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

> From: Remco Barendse [mailto:shorewall@barendse.to]=20
>=20
> could I play around with DHCP as a *very* dirty hack?
what do you want to achieve with DHCP? You would just set your network
options automatically instead of manually. Because DHCP is also
broadcast-based, you can''t use it across a VPN without changing the VPN
and patch it.
If you just want to enable domain logons you could also have a look at
the lmhosts-file on the windows machines.
> According to WINIPCFG, Winblows can contact a Primary an=20
> Secondary WINS=20
> server. If I pass the remote WINS servers IP to the clients=20
> as *primary*=20
> WINS server..... I presume the clients would try to go to the=20
> remote WINS=20
> server first and then to the local WINS server?
when using primary and secondary WINS, the problem remains the same: you
have to make sure that both databases keep all records. But as Jan
Johannson pointed out, replication is not possible when using SAMBA. The
clients contact the first server and if this succeeds, they don''t touch
the second one.
> On the other hand, this might create browsing problems and=20
> slowdowns to=20
> browse the local net??
try it :)
IIRC Win Machines normally keep other SMB-Machines in their cache after
resolving via WINS. I don''t expect it to slow down the local net very
much.

Andreas

>could I play around with DHCP as a *very* dirty hack?
What good would that do?
>According to WINIPCFG, Winblows can contact a Primary an Secondary WINS
>server. If I pass the remote WINS servers IP to the clients as
*primary* 
>WINS server..... I presume the clients would try to go to the remote
WINS 
>server first and then to the local WINS server?
No, no and yet again no. Unless you can _guarantee_ that both those wins
servers are replicated, you would introduce a risk of horrible
inconsistencies. Ponder this:

1. Client binds to remote WINS
2. Link goes down
3. Client tries to access a WINS, fails.
4. Client registers with local wins

Now you have two registrations, which triggers the infamous
"tombstone"
in MS Wins servers.
>On the other hand, this might create browsing problems and slowdowns to
>browse the local net??
Yes, but that is the least of your problems.

Bottom line is still: Either you have two replicating WINS servers
(which means using MS WINS), or else you do not use WINS on one of the
subnets.

After dealing with a WINS comprising of over 40.000 entries, I know what
incosistancies can lead to :)

Hmmmz, I was sort of hoping that by telling the clients through DHCP which 
WINS server to use I could let the clients ''switch'' between
them.

But if this is going to wreak havoc.... i better not try it

Always thought WINS was some sort of volatile temporary thing, restart the 
bugger and you''re all in the clear. Obviously I am wrong...

Just out of interest, how do guys like Cisco solve this? I have a Cisco 
VPN 3005 (which isn''t suitable for net2net connections, unless you have
Cisco hardware at both ends). 
In this VPN router you simply make a setting for your WINS server and 
every client can see both the local and remote machines.

It''s frustrating to have a vpn tunnel to find out only that you have
only
limited use for it....

Remco

On Tue, 19 Nov 2002, Jan Johansson wrote:
> >could I play around with DHCP as a *very* dirty hack?
> 
> What good would that do?
> 
> >According to WINIPCFG, Winblows can contact a Primary an Secondary WINS
> 
> >server. If I pass the remote WINS servers IP to the clients as
> *primary* 
> >WINS server..... I presume the clients would try to go to the remote
> WINS 
> >server first and then to the local WINS server?
> 
> No, no and yet again no. Unless you can _guarantee_ that both those wins
> servers are replicated, you would introduce a risk of horrible
> inconsistencies. Ponder this:
> 
> 1. Client binds to remote WINS
> 2. Link goes down
> 3. Client tries to access a WINS, fails.
> 4. Client registers with local wins
> 
> Now you have two registrations, which triggers the infamous
"tombstone"
> in MS Wins servers.
> 
> >On the other hand, this might create browsing problems and slowdowns to
> 
> >browse the local net??
> 
> Yes, but that is the least of your problems.
> 
> Bottom line is still: Either you have two replicating WINS servers
> (which means using MS WINS), or else you do not use WINS on one of the
> subnets.
> 
> After dealing with a WINS comprising of over 40.000 entries, I know what
> incosistancies can lead to :)
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

I don''t recall where I got the directions for my setup but what I have
is
this. Both subnets are part of the same "workgroup". In *ONE* of the
subnets
I have the samba wins server. It is also local and domain master. All the
windows boxes in both subnets point to it as the wins server. If you just
have this, all the boxes on both sides will "eventually" be seen by
all the
others unless you have WinXP or Win2K boxes running. Make sure you have
netbios going over tcpip. To make things work better (and to work at all
with WinXP/Win2K boxes), on the "other" side, I have another samba
running
that is not domain master but is still local master and is not a wins
server. It points wins to the main wins server. With this, both sides are
able to fully browse each other. The only difficulty occurs when the vpn
goes down. When this happens and the 2ndary samba loses connection to the
main wins server, it orphans itself so the key is that when the vpn comes
up, the samba on the non-wins-server side needs to be (re)started.. Also
make sure you set the "priority" in the samba configuration to at
least 65
so the samba servers win the server election over any WinXP or Win2K boxes
in the subnet. On my setup the samba servers are not running on the firewall
boxes. I don''t know the implications of running it there versus
separate.

Steve

----- Original Message -----
From: "Remco Barendse" <shorewall@barendse.to>
To: "Jan Johansson" <jan.johansson@nwl.se>
Cc: <shorewall-users@shorewall.net>
Sent: Tuesday, November 19, 2002 8:08 AM
Subject: RE: [Shorewall-users] SMB browsing over FreeS/Wan tunnel?

> Hmmmz, I was sort of hoping that by telling the clients through DHCP which
> WINS server to use I could let the clients ''switch''
between them.
>
> But if this is going to wreak havoc.... i better not try it
>
> Always thought WINS was some sort of volatile temporary thing, restart the
> bugger and you''re all in the clear. Obviously I am wrong...
>
> Just out of interest, how do guys like Cisco solve this? I have a Cisco
> VPN 3005 (which isn''t suitable for net2net connections, unless you
have
> Cisco hardware at both ends).
> In this VPN router you simply make a setting for your WINS server and
> every client can see both the local and remote machines.
>
> It''s frustrating to have a vpn tunnel to find out only that you
have only
> limited use for it....
>
> Remco
>
> On Tue, 19 Nov 2002, Jan Johansson wrote:
>
> > >could I play around with DHCP as a *very* dirty hack?
> >
> > What good would that do?
> >
> > >According to WINIPCFG, Winblows can contact a Primary an Secondary
WINS
> >
> > >server. If I pass the remote WINS servers IP to the clients as
> > *primary*
> > >WINS server..... I presume the clients would try to go to the
remote
> > WINS
> > >server first and then to the local WINS server?
> >
> > No, no and yet again no. Unless you can _guarantee_ that both those
wins
> > servers are replicated, you would introduce a risk of horrible
> > inconsistencies. Ponder this:
> >
> > 1. Client binds to remote WINS
> > 2. Link goes down
> > 3. Client tries to access a WINS, fails.
> > 4. Client registers with local wins
> >
> > Now you have two registrations, which triggers the infamous
"tombstone"
> > in MS Wins servers.
> >
> > >On the other hand, this might create browsing problems and
slowdowns to
> >
> > >browse the local net??
> >
> > Yes, but that is the least of your problems.
> >
> > Bottom line is still: Either you have two replicating WINS servers
> > (which means using MS WINS), or else you do not use WINS on one of the
> > subnets.
> >
> > After dealing with a WINS comprising of over 40.000 entries, I know
what
> > incosistancies can lead to :)
> >
> >
> >
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@shorewall.net
> http://www.shorewall.net/mailman/listinfo/shorewall-users

> -----Original Message-----
> From: Remco Barendse 
> Sent: Tuesday, November 19, 2002 7:08 AM
> Subject: RE: [Shorewall-users] SMB browsing over FreeS/Wan tunnel?
> 
> 
> Hmmmz, I was sort of hoping that by telling the clients 
> through DHCP which WINS server to use I could let the clients
> ''switch'' between them.
Actually, DHCP can be used to set WINS and Netbios Node Type of each client.
If your running a WINS server on each LAN, just make sure that your DHCP
scope returns the local WINS server for that LAN. Although, WINS replication
is a separate issue.
> 
> But if this is going to wreak havoc.... i better not try it
If you want network neighborhood to work across your VPN, you really have no
other choice but to implement a WINS server. Well short of editing a LMHOSTS
file. :-(
> 
> Always thought WINS was some sort of volatile temporary 
> thing, restart the  bugger and you''re all in the clear.
> Obviously I am wrong...
Microsoft developed WINS just to solve the problem of browsing across
subnets. With W2K server, MS finally started using AD/DNS. Thank goodness!
> 
> Just out of interest, how do guys like Cisco solve this? I 
> have a Cisco  VPN 3005 (which isn''t suitable for net2net
> connections, unless you have Cisco hardware at both ends). 
> In this VPN router you simply make a setting for your WINS
> server and every client can see both the local and remote
> machines.
I''m not aware of cisco implementing this feature. DHCP yes, but not
WINS.
> 
> It''s frustrating to have a vpn tunnel to find out only that 
> you have only limited use for it....
If you take the time to "properly" setup a WINS server as suggested in
the
other replies to your post, you should NOT have any limitations at all. 

FWIW: Your going through a standard learning curve. Your MS clients netbios
node type has been set to broadcast (type 1) by default since day one, now
you need to implement a WINS server and change each systems netbios node
type to query (type 8). 
>From man dhcp-options
option netbios-node-type uint8;

   The NetBIOS node type option  allows  NetBIOS  over  TCP/IP  clients
   which  are  configurable  to  be  configured  as  described  in  RFC
   1001/1002.  The value is specified as a single octet  which  identi-
   fies the client type.

      Possible node types are:

          1    B-node: Broadcast - no WINS
          2    P-node: Peer - WINS only.
          4    M-node: Mixed - broadcast, then WINS
          8    H-node: Hybrid - WINS, then broadcast

Steve Cowles

Everybody thanks for all the explanations, I have a lot of stuff to try 
now :)
> If you want network neighborhood to work across your VPN, you really have
no
> other choice but to implement a WINS server. Well short of editing a
LMHOSTS
> file. :-(
Interesting option, I only need the clients on the other side to see 
2 servers, not anything else. The ip numbers will not change and LMHOSTS 
could be forced through the logon script. Will try that as a last resort.

> > It''s frustrating to have a vpn tunnel to find out only that 
> > you have only limited use for it....
> 
> If you take the time to "properly" setup a WINS server as
suggested in the
> other replies to your post, you should NOT have any limitations at all. 
Time is not the issue, but I am looking for a solution that doesn''t 
involve any Micro$oft  ''solution'' :)

 
> FWIW: Your going through a standard learning curve. Your MS clients netbios
> node type has been set to broadcast (type 1) by default since day one, now
> you need to implement a WINS server and change each systems netbios node
> type to query (type 8). 
> 
> >From man dhcp-options
> 
> option netbios-node-type uint8;
I tried enforcing this option once through dhcp and as a result nobody 
could see the exchange server anymore. But then again I may have had some 
other things completely wrong at the time :)

Are these the correct lines that I should put in dhcpd.conf :
  option netbios-name-servers 10.1.0.8;
  option netbios-dd-server    10.1.0.8;
  option netbios-node-type    8;
  option netbios-scope        "";

Where 10.1.0.8 is the ip of the server running SAMBA with wins (os level 
is set to 65).


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

> -----Original Message-----
> From: Remco Barendse
> Sent: Tuesday, November 19, 2002 10:42 AM
> Subject: RE: [Shorewall-users] SMB browsing over FreeS/Wan tunnel?
> 
> 
> Everybody thanks for all the explanations, I have a lot of 
> stuff to try now :)
> 
> > If you want network neighborhood to work across your VPN, 
> > you really have no other choice but to implement a WINS
> > server. Well short of editing a LMHOSTS file. :-(
> >
> Interesting option, I only need the clients on the other side
> to see 2 servers, not anything else. The ip numbers will not
> change and LMHOSTS could be forced through the logon script.
> Will try that as a last resort.
> 
> 
Personally, using the LMHOSTS approach would be an administration nightmare.
> > > It''s frustrating to have a vpn tunnel to find out only
that
> > > you have only limited use for it....
> > 
> > If you take the time to "properly" setup a WINS server as 
> > suggested in the other replies to your post, you should NOT
> > have any limitations at all. 
> >
> Time is not the issue, but I am looking for a solution that
doesn''t
> involve any Micro$oft  ''solution'' :)
Good Luck! Netbios by its very nature (design), will force you to implement
a WINS server when your requirements change to browse across separate LAN
segments. i.e. Your VPN. 

How you choose to implement this (MS WINS, Samba WINS or through LMHOSTS) is
up to you. But netbios broadcast packets do NOT span routers. Well, unless
you configure your router to do so. Which would be a big mistake! Netbios is
very chatty and would clog your tunnel with a bunch of un-necessary
broadcast traffic.
> 
>  
> > FWIW: Your going through a standard learning curve. Your MS 
> > clients netbios node type has been set to broadcast (type 1)
> > by default since day one, now you need to implement a WINS
> > server and change each systems netbios node type to query (type 8). 
> > 
> > >From man dhcp-options
> > 
> > option netbios-node-type uint8;
> 
> I tried enforcing this option once through dhcp and as a 
> result nobody  could see the exchange server anymore. But
> then again I may have had some other things completely
> wrong at the time :)
Did you also change your exchange servers netbios node type to hybrid.
Without doing so, it would not register with the WINS server. i.e. It''s
still broadcasting its workgroup/domain affiliation. So it would not show up
in network neighborhood if the other MS clients on your LAN''s are using
WINS
for netbios name resolution. This is a common mistake when organizations
make the transition to WINS.
> 
> Are these the correct lines that I should put in dhcpd.conf :
>   option netbios-name-servers 10.1.0.8;
>   option netbios-dd-server    10.1.0.8;
>   option netbios-node-type    8;
>   option netbios-scope        "";
> 
All I use at this end is... 

option netbios-name-servers 192.168.9.2;
option netbios-node-type 8;
> Where 10.1.0.8 is the ip of the server running SAMBA with 
> wins (os level is set to 65).
So has this system "won" the election process for domain master
browser? The
smbclient command will tell you who has won this election process. Use the
-L option. nmblookup is also a very useful tool.

Steve Cowles