What I''m doing:
I have Shorewall on a SuSE 9.0 machine, which is the firewall/router
on the network. External interface is eth0 172.16.1.1, internal
interface is eth1 10.40.1.1. (I used the Two-interface Linux System
Quickstart Guide). All works well with that configuration. I also use
PPPD for dial-in clients, and have two modems for incoming calls.
Recently I added VPN interface eth2 10.40.2.1. I am using PPTP
running on the firewall for my VPN, and wireless users connect to the
VPN through eth2. I''ve set up PPTPD to listen on eth2 which I wanted
to do so I could have dial-in users in a different zone from VPN
users. I also have DHCPD listening on eth2 so I don''t have to mess
with IP settings on wireless client machines.
With the exception of Windows network browsing, I''ve got things
working the way I want. VPN users are able to get a DHCP address on
the 10.40.2.0/24 network. They can then connect to the PPTP VPN and
are assigned a DHCP address on the 10.40.1.0/24 network. Routing and
firewall is working fine the way I want it to.
In addition to Internet access, I want VPN users to be able to browse
the local network and connect to Windows shares. I am running Samba
on the firewall/router, and have it configured as the WINS server. On
a Windows 2000 VPN client, I am able to go to the ''Computers Near
Me''
window and view all the shares on the network. However, when I try to
connect to any of the Windows shares, I get "\\share is not
accessible. The network path was not found." But, if I type in the
network address manually, like "\\10.40.1.2" I can get to the share
folder and have no trouble from that point on.
For what it''s worth, clients on the 10.40.1.0/24 network (who
haven''t
connected through the VPN) can browse the network with no problem,
and connect to any of the available shares. The smb.conf includes:
workgroup = SHL
netbios name = NEBO
server string = Samba Server
interfaces = eth1 10.40.1.0/24
os level = 230
preferred master = Yes
domain master = Yes
wins support = Yes
hosts allow = 10.40.1. 127.
Can anyone point me in the direction of a solution here? I''m almost
there, network browsing works, but connecting with the netbios name
doesn''t work. I have to use the IP address. BTW, this is only true of
the Windows shares. I can connect to the Samba Server (NEBO) without
using the IP address.
I have used ''/sbin/shorewall show log'' to troubleshoot while
trying
to connect to a share, and don''t see anything in there that is
related. I''m wondering if this post is a bit off-topic, and that my
problem is related more to DHCP and SMB configuration than it is to
my Shorewall configuration.
Shorewall files:
INTERFACES--
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 172.16.1.2 routefilter
loc eth1 10.40.1.255 dhcp
vpn eth2 10.40.2.255 dhcp
ppp ppp+
================
ZONES--
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local Network
ppp PPP Dialin users
vpn VPN Wireless users
================
MASQ--
#INTERFACE SUBNET ADDRESS
eth0 eth1 172.16.1.2
eth0 10.40.1.0/24
================
TUNNELS--
# TYPE ZONE GATEWAY GATEWAY
# ZONE
pptpserver net 0.0.0./0
================
POLICY--
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
fw net ACCEPT
# The following two lines control access for vpn on eth2
net vpn REJECT
vpn net REJECT
# The following two lines control access for dialin
net ppp REJECT
ppp net REJECT
#
net all DROP info
all all REJECT info
================
RULES--related to VPN and SAMBA
# Allow PPTP VPN to Nebo
ACCEPT vpn fw 47 - -
ACCEPT vpn fw tcp 1723 -
#
# Accept Samba connections between LAN and NEBO
AllowSMB fw loc
AllowSMB loc fw
#
# Accept Samba connections between VPN and NEBO
AllowSMB fw ppp
AllowSMB ppp fw
#
# Accept Samba connections between PPP and LAN
AllowSMB loc ppp
AllowSMB ppp loc
#
# Accept Samba connections between VPN and LAN
AllowSMB loc vpn
AllowSMB vpn loc
================
# shorewall version 2.0.14
================# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:10:5a:11:ae:f7 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.2/24 brd 172.16.1.255 scope global eth0
inet6 fe80::210:5aff:fe11:aef7/64 scope link
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:50:da:b6:ee:86 brd ff:ff:ff:ff:ff:ff
inet 10.40.1.1/24 brd 10.40.1.255 scope global eth1
inet6 fe80::250:daff:feb6:ee86/64 scope link
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:50:da:b6:ed:1f brd ff:ff:ff:ff:ff:ff
inet 10.40.2.1/24 brd 10.40.2.255 scope global eth2
inet6 fe80::250:daff:feb6:ed1f/64 scope link
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
329: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
3
link/ppp
inet 10.40.1.1 peer 10.40.1.61/32 scope global ppp1
330: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
3
link/ppp
inet 10.40.1.1 peer 10.40.1.9/32 scope global ppp0
================# ip route show
10.40.1.61 dev ppp1 proto kernel scope link src 10.40.1.1
10.40.1.9 dev ppp0 proto kernel scope link src 10.40.1.1
172.16.1.0/24 dev eth0 proto kernel scope link src 172.16.1.2
10.40.2.0/24 dev eth2 proto kernel scope link src 10.40.2.1
10.40.1.0/24 dev eth1 proto kernel scope link src 10.40.1.1
default via 172.16.1.1 dev eth0
David Hoffman wrote:> > I have used ''/sbin/shorewall show log'' to troubleshoot while trying to > connect to a share, and don''t see anything in there that is related. I''m > wondering if this post is a bit off-topic, and that my problem is > related more to DHCP and SMB configuration than it is to my Shorewall > configuration.When debugging Samba/SMB problems, you MUST disable the common Drop and Reject actions by adding these entries in /etc/shorewall/actions: :DROP :REJECT Otherwise, the common actions silently drop/reject any SMB traffic that isn''t allowed by rules or policies. Shorewall silently handles this traffic by default so that your log isn''t flooded by the barrage of noise that your and your neighbors'' Windows systems spew out 24 hours a day, but it makes debugging SMB problems nearly impossible unless you disable it. My other suggestion is do remove the ''interfaces'' line in your smb.conf file until you get this working. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > When debugging Samba/SMB problems, you MUST disable the common Drop and > Reject actions by adding these entries in /etc/shorewall/actions: > > :DROP > :REJECT >I''ve outlined a slightly better approach at the bottom of http://shorewall.net/samba.htm -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
At 1:32 PM -0700 4/14/05, Tom Eastep wrote:>When debugging Samba/SMB problems, you MUST disable the common Drop and >Reject actions by adding these entries in /etc/shorewall/actions: > >:DROP >:REJECT > >Otherwise, the common actions silently drop/reject any SMB traffic that >isn''t allowed by rules or policies. > >Shorewall silently handles this traffic by default so that your log >isn''t flooded by the barrage of noise that your and your neighbors'' >Windows systems spew out 24 hours a day, but it makes debugging SMB >problems nearly impossible unless you disable it. > >My other suggestion is do remove the ''interfaces'' line in your smb.conf >file until you get this working.I tried disabling common Drop and Reject actions for SMB and still didn''t see anything in the Shorewall log. The only thing I''m seeing is this line: Apr 15 15:35:49 nebo kernel: Shorewall:all2all:REJECT:IN=ppp0 OUT= MAC= SRC=10.40.1.60 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=4577 PROTO=UDP SPT=68 DPT=67 LEN=308 and I see that everytime one of my ppp clients connects, whether it is a dial-in user or a VPN user. Just once, when they first connect. I also removed the ''interfaces'' line in smb.conf, with no difference. So, I''m just about to give up on Windows network browsing. Internet services work fine for VPN users, and that is what most of them will be using anyway. I have noticed that if I go to a share once by using the IP address (\\10.40.1.2) then using the Netbios name in the Computers Near Me window works fine after that. I don''t have much more time to spend on this, so that will have to do for now. -- DAvid
David Hoffman wrote:> At 1:32 PM -0700 4/14/05, Tom Eastep wrote: >> When debugging Samba/SMB problems, you MUST disable the common Drop and >> Reject actions by adding these entries in /etc/shorewall/actions: >> >> :DROP >> :REJECT >> >> Otherwise, the common actions silently drop/reject any SMB traffic that >> isn''t allowed by rules or policies. >> >> Shorewall silently handles this traffic by default so that your log >> isn''t flooded by the barrage of noise that your and your neighbors'' >> Windows systems spew out 24 hours a day, but it makes debugging SMB >> problems nearly impossible unless you disable it. >> >> My other suggestion is do remove the ''interfaces'' line in your smb.conf >> file until you get this working. > > I tried disabling common Drop and Reject actions for SMB and still > didn''t see anything in the Shorewall log. The only thing I''m seeing is > this line: > > Apr 15 15:35:49 nebo kernel: Shorewall:all2all:REJECT:IN=ppp0 OUT= MAC> SRC=10.40.1.60 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 > ID=4577 PROTO=UDP SPT=68 DPT=67 LEN=308DHCP...> > and I see that everytime one of my ppp clients connects, whether it is a > dial-in user or a VPN user. Just once, when they first connect. > > I also removed the ''interfaces'' line in smb.conf, with no difference. > > So, I''m just about to give up on Windows network browsing. Internet > services work fine for VPN users, and that is what most of them will be > using anyway. I have noticed that if I go to a share once by using the > IP address (\\10.40.1.2) then using the Netbios name in the Computers > Near Me window works fine after that. I don''t have much more time to > spend on this, so that will have to do for now.FWIW, I''ve had problems with network browsing across LAN segments also since upgrading to Samba 3. I don''t use Samba much any more (only have two Windows systems), so I haven''t spent a lot of time trying to sort it out. I did find though that it worked better to have the WINS server in the same LAN segment as my file server rather than on my firewall (I don''t run Samba on my firewall at all anymore). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
David Hoffman wrote on 15/04/2005 17:44:23:> At 1:32 PM -0700 4/14/05, Tom Eastep wrote: > > I tried disabling common Drop and Reject actions for SMB and still > didn''t see anything in the Shorewall log. The only thing I''m seeing > is this line: > > Apr 15 15:35:49 nebo kernel: Shorewall:all2all:REJECT:IN=ppp0 OUT= > MAC= SRC=10.40.1.60 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 > TTL=128 ID=4577 PROTO=UDP SPT=68 DPT=67 LEN=308 > > and I see that everytime one of my ppp clients connects, whether it > is a dial-in user or a VPN user. Just once, when they first connect. >this is bootp/dhcp. If your firewall is a dhcp server, you should open those ports.> > I also removed the ''interfaces'' line in smb.conf, with no difference. > > So, I''m just about to give up on Windows network browsing. Internet > services work fine for VPN users, and that is what most of them will > be using anyway. I have noticed that if I go to a share once by using > the IP address (\\10.40.1.2) then using the Netbios name in the > Computers Near Me window works fine after that. I don''t have much > more time to spend on this, so that will have to do for now. >I use the following set of rules and actions to let my w2k3 AD servers Communicate through a shorewall firewall: action.OkADS: #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT PORT(S) LIMIT GROUP OkLDAP - - AllowSMB - - ACCEPT - - tcp kerberos # no idea why, but I must use the following port. ACCEPT - - tcp 1025 # this one, I should not have to use. it''s novell control protocol. ACCEPT - - tcp 524 action.OkLDAP is: #TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT PORT(S) LIMIT GROUP ACCEPT - - tcp ldap,ssl-ldap ACCEPT - - udp ldap With those set of rules, I''m able to communicate with and browse the remote network. Hope it helps, ________________________ Eduardo Ferreira Icatu Holding S.A. Supervisor de TI (5521) 3804-8606