Date: Tue, 20 Mar 2018 17:44:26 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Andreas Scherrer <ascherrer@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Multicast/SSDP not working (on VLAN interface) Message-ID: <201803210044.w2L0iQww018953@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <a7d2a418-24d5-a1c1-2fe5-8d4bcc6c1dfc@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi > > Thank you, Rodney and Ivan, for coming back to me (and so quickly). > > On 20.03.18 00:11, Rodney W. Grimes wrote: > > ... > > >> So I suspect that "something" is dropping the M-SEARCH packets for some > >> reason after they are received. And I cannot get rid of the feeling that > >> it has something to do with the fact that the incoming interface is a > >> VLAN interface... > >> My first guess, anti spoofing, seems not to be the problem (I am using > >> ipfw and "not antispoof in" but that does not seem to drop any traffic). > > > > Are you running with "firewall_type="simple""? > > If so it is set to block all 224/4 packets, see this part > > of /etc/rc.firewall: > > ... > > No, my firewall is made from "hand curated" ipfw rules. > > And I am pretty sure (never 100%, but 99% this time), that this is not a > firewall issue. Why? > > I have the following rule that should accept traffic from my client(s) > to 239.255.255.250:1900 in place: > > allow ip from any to not me in recv re1\* > > And, when I place a rule like this just before and after that rule: > > count log ip from any to any via re1\* > > I see hits before but not after the "allow" rule. Hence, the policy > accepts the packet(s). No? > > Also, just adding the route for 224.0.0.0/4, without touching the ipfw > rules, makes things work... And I am *not* using "verrevpath" in my ifpw > rules (I do use "antispoof", but as the packets hit the rule(s) > mentioned above, that does not seem to be the problem). Your missing that WITHOUT that route the packets from your application TOWARDS your client are going to try and use the default route and go out the default interface. Your IN RULE has 0 effect on that, however your route add probably changes the interface these OUTWARD packets have. > > I might give Ivan's code a try, but I am not very good at compiling and > installing software :( > > If anybody is able to provide an additional hint in the mean time, I am > more than happy to follow up. Show me your full firewall rule set, without that I can only speculate as to where it is getting blocked, but given your symptoms I highly suspect the firewall is blocking the packets OUT of your SERVER back towards the client as they try to go out what ever interface your default route is on. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803210044.w2L0iQww018953>