[Samba] getent not working after installing firewall

[L.P.H. van Belle]

> 
> my point is that the multihoming should happen on a device dealing with
> routing/internet traffic and not on a samba machine so that it's
> completly transparent to the LAN

And for that, you could use advanced routing. 
Which is an option, nothing more. 
You setup is also a good option. nothing more. 

> This might be 1,2 or 3 devices. 
> 
> it might be 3 devices, but none of them should be your Samba DC.
Again this depends on you needs, sometimes you must. 

A Samba DC could be used but is not adviced. 
Same as, Samba Member is using Winbind and not SSSD, but it could be used. 

> 
> > Or  https://tools.ietf.org/html/rfc4795 
> > The Link-Local Multicast Name Resolution (LLMNR) is a 
> protocol based on the Domain Name System (DNS)
> >  packet format that allows both IPv4 and IPv6 hosts to 
> perform name resolution for hosts on the same local link.
> 
> the point here is local link
Yep, and i'll add: for Ipv4

IPv6 is a bit different here, but lets not discuss that. 
I still have some work todo here. ;-) 

> 
> > So i dont totaly agree on you statement :
> > "there is no point dealing with multicast packets on the firewall"
> 
> not when the firewall seperate your LAN with the internet, mdns/broadcasts belong to the LAN.
> 
> > Again this all is highly subjected to you needs, 90% of the users wont need it.. 
> > On that i agree with you. 
> > 
> > On the samba list we do have beginners and very advanced users. 
> > So thats why i do show things.. 
> > 
> > And i do appriciate you input Harald. 
> > Things like this wil only make samba better and resulting setup's will be better
> 
> the point i made is that i question the OP's setup in general where
> internal hosts are aware of routing, multihoming and so at all
> 
> look at the first rules below
> 
> INBOUND:  that chain deals with packets from the internet
> OUTBOUND: that chain deals with packets to the internet
> INTERNAL: that chain deals with VPN traffic and "loopback"
> 
> "wan" is in fact a multihomed bridge running HSRP between the uplinks
> but that's still a different layer and so in the firewall 
> rules it don't
> matter, the virtual gateway stays the same and for inbound traffic ou
> don't need to care over which line it enters the gateway and ruleset
> 
> the LAN interface and the network including switches and servers don't
> need to know anything about that
> 
> when replacing the openvpn machine with wireguard most likely 
> there will
> be a new chain for the wireguard-interfaces and the decision 
> if a packet
> targets INTERNAL/WIREGUARD is made by the routing before, still
> completly transparent to the LAN
> 
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> num   pkts bytes target     prot opt in     out     source
>  destination
> 1     320M  302G ACCEPT     all  --  *      *       0.0.0.0/0
>  0.0.0.0/0            ctstate RELATED,ESTABLISHED
> 2      12M  703M INBOUND    all  --  wan    lan     0.0.0.0/0
>  0.0.0.0/0            ctstate NEW ! match-set EXCLUDES src
> 3    6480K  526M OUTBOUND   all  --  lan    wan     192.168.196.0/24
>       0.0.0.0/0            ctstate NEW
> 4     4128  277K INTERNAL   all  --  lan    lan     0.0.0.0/0
>  0.0.0.0/0            ctstate NEW

Yes, this also a good option. 

You know, MS is responce on a multihomed AD-DC and problems :-) hihi...   :-P 
This behavior is by design.  ( kb272294 ) 

Thank you for your input Harald, we have same thoughts, but 2 different solutions. 


Greetz, 

Louis