Hi
As per my follow up mail I implemented the ProxyArp configuration as per the
Documentation on the Web site and all seemed to be working correctly.
However, the one thing that doesn''t seem to be working properly is
Samba.
I have Samba running on the FW machine and one of the servers 192.168.0.8 on
the Local Lan.
I can connect to a Share using Samba from Server to Server, however It is the
identification of the Samba server names that is failing, which of course
relies on Broadcast addresses. i.e. the Samba Name Servers synch with each
other by sending Broadcasts. There are no dropped packets within the Logs
so it is not a Firewall issue persay. In fact the Rules & Policy files have
not changed from what was used ( without problems with Samba ) using SNAT.
I have a horrible feeling that this is to do with the inability of ProxyArp in
handling Broadcast addressing?
For completeness :-
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 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0d:61:73:66:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0
inet6 fe80::20d:61ff:fe73:6660/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
inet6 fe80::204:5aff:fe8c:676a/64 scope link
valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
ip route show
192.168.0.8 dev eth1 scope link
192.168.0.255 dev eth1 scope link
192.168.0.10 dev eth1 scope link
192.168.0.3 dev eth1 scope link
192.168.0.2 dev eth1 scope link
192.168.0.5 dev eth1 scope link
192.168.0.6 dev eth1 scope link
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.4
default via 192.168.0.1 dev eth0
proxyarp :-
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
192.168.0.2 eth1 eth0 No Yes
192.168.0.3 eth1 eth0 No Yes
192.168.0.5 eth1 eth0 No Yes
192.168.0.6 eth1 eth0 No Yes
192.168.0.8 eth1 eth0 No Yes
192.168.0.10 eth1 eth0 No Yes
Regards
Stewart
--
Stewart Outram
UK
stewart wrote:> Hi > > As per my follow up mail I implemented the ProxyArp configuration as per the > Documentation on the Web site and all seemed to be working correctly. > > However, the one thing that doesn''t seem to be working properly is Samba. > > I have Samba running on the FW machine and one of the servers 192.168.0.8 on > the Local Lan. > > I can connect to a Share using Samba from Server to Server, however It is the > identification of the Samba server names that is failing, which of course > relies on Broadcast addresses. i.e. the Samba Name Servers synch with each > other by sending Broadcasts. There are no dropped packets within the Logs > so it is not a Firewall issue persay.Shorewall silently drops all against-policy SMB traffic that is not explicitly allowed -- otherwise, your logs would overflow from the bleating of the "lost sheep" (Windows systems). In fact the Rules & Policy files have> not changed from what was used ( without problems with Samba ) using SNAT. > > I have a horrible feeling that this is to do with the inability of ProxyArp in > handling Broadcast addressing?It''s not ProxyARP itself but it is the way that the routing and subnetting is set up under Proxy ARP. I suspect that your kernel won''t accept 192.168.0.255 broadcasts on eth1 since the broadcast address there is 10.0.0.255. You might get this to work if you configure one of your Samba servers as a WINS server and configure all of the other SMB clients (including the other Samba box) to use it. -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:> stewart wrote: > >>Hi >> >>As per my follow up mail I implemented the ProxyArp configuration as per the >>Documentation on the Web site and all seemed to be working correctly. >> >>However, the one thing that doesn''t seem to be working properly is Samba. >> >>I have Samba running on the FW machine and one of the servers 192.168.0.8 on >>the Local Lan. >> >>I can connect to a Share using Samba from Server to Server, however It is the >>identification of the Samba server names that is failing, which of course >>relies on Broadcast addresses. i.e. the Samba Name Servers synch with each >>other by sending Broadcasts. There are no dropped packets within the Logs >>so it is not a Firewall issue persay. > > > Shorewall silently drops all against-policy SMB traffic that is not > explicitly allowed -- otherwise, your logs would overflow from the > bleating of the "lost sheep" (Windows systems). > > In fact the Rules & Policy files have > >>not changed from what was used ( without problems with Samba ) using SNAT. >> >>I have a horrible feeling that this is to do with the inability of ProxyArp in >>handling Broadcast addressing? > > > It''s not ProxyARP itself but it is the way that the routing and > subnetting is set up under Proxy ARP. I suspect that your kernel won''t > accept 192.168.0.255 broadcasts on eth1 since the broadcast address > there is 10.0.0.255. You might get this to work if you configure one of > your Samba servers as a WINS server and configure all of the other SMB > clients (including the other Samba box) to use it. >Note that if you to this, you should configure Samba on the firewall to only listen on eth1! You don''t want it to try to be the master browser for 192.168.0.0/24 -- that should be one of your internal systems. -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