From owner-freebsd-net@freebsd.org Wed Mar 21 22:50:13 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FB10F4692E for ; Wed, 21 Mar 2018 22:50:12 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AF616CF0C for ; Wed, 21 Mar 2018 22:50:12 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id v21so1370874wmc.1 for ; Wed, 21 Mar 2018 15:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=CH5pWzh0HRFthPJTcKQmp/hbyItl3cFtdX451n+DmS0=; b=b5Gm04tENkcurlGxlSQ49kJX6fwpKDgnA9r7ySo2RgncECL8IfQKc2CIH/TIDbkZRE 4/eQIzl7V5/h2O3GY1xoLcMVyaNc4CAJ6mCgT/o2AxQiYte8TiqgAddualqHu7ovcVuU phhVe1jbETKn5/oeWDJzkZCM7hukG6V8fQtr1ToJJ8vbrsoh0Q9j8ntP3lMIVY4yjhkS KXQUV/7LqQI5Uy1aAspMkyZL14U07OmW67DVU0QaV5/fFRnvbT5V6snAnc2UWU7DZJTl cmTLHUWaHqw/n1f2N4/Jz8YtmY5tmd25pYSvUSJ6Sx14ixxbTmONez5EejyuXWfNn2yw QSIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CH5pWzh0HRFthPJTcKQmp/hbyItl3cFtdX451n+DmS0=; b=EO7ZMhUNLl/6vyGHzoHxFx6p7qNJOrkMeuGHDqcqyfZzrmONnWVddxB3cHWadABvdH 701VBdON45ct/ls8IXf1cR1ShEXso0C1bSXlFBgQE6d7jwSTY6/IKSti27UeTjSv7zJQ xRmRIcfltdXMGWUWPwdS3UJSoOkYVw7gUuP5waBM5cRxPpJvt65MfF7SY3AD6gqGbtsi yfdtfkkSI+VUrboqIxnkVph1hhU280WiIO8P4cLggRpg/J2zIqq139V4Xge8oQGUHEUd LdZpSBykJdvbhXjLrdHrEuE38l+x3MVyrdIc6N8oRnXX8YX/6vtb4eni2hlF8oNYSwNf xwew== X-Gm-Message-State: AElRT7H40zUIWmsFXNkWFbwIkHv4X4/QvLUdGRs0A4yl2gtEO9znswcY zXGxd/msxGzFTFvL0pFd2nqo8APF X-Google-Smtp-Source: AG47ELsz6pW6XOwI8Ky9tf/WrrnsNVMNvkCQKE3V4F0MpK7Hg7+ble5P41N3lDO5z630SMVZLk4lBg== X-Received: by 10.80.201.196 with SMTP id c4mr22717086edi.32.1521672610914; Wed, 21 Mar 2018 15:50:10 -0700 (PDT) Received: from juntos.woohoo.ch ([2a02:168:681c:460:2c94:a00:34cb:9fa1]) by smtp.gmail.com with ESMTPSA id w10sm383221eda.66.2018.03.21.15.50.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 15:50:09 -0700 (PDT) Subject: Re: Multicast/SSDP not working (on VLAN interface) To: freebsd-net@freebsd.org References: <201803210044.w2L0iQww018953@pdx.rh.CN85.dnsmgr.net> From: Andreas Scherrer Message-ID: <0b920e07-8ad3-deb9-a876-9523b18678f7@gmail.com> Date: Wed, 21 Mar 2018 23:50:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201803210044.w2L0iQww018953@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 22:50:13 -0000 Thank you for bearing with me. On 21.03.18 01:44, Rodney W. Grimes wrote: ... > 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. OK, I see your point. But I obviously forgot to mention some important things. I am sorry for that. First of all, my rules file is 800+ lines, I am not sure how much it helps to throw that at anybody. I agree that this makes it somewhat more likely that the firewall IS the problem, but I do have reason to believe that it is not. I did check on the interface the default route is pointing through: there is no incorrect outgoing traffic. Obviously, if the firewall blocks the traffic, then I expect not to see any. But there are the following rules as well: allow ip4 from me to "table($internal)" out xmit re1\* keep-state allow ip4 from me to "table($broadcast)" out xmit re1\* table($internal) is basically RFC1918 and table($broadcast) contains 224.0.0.0/4 and ff00::/8. To test, I have also added the following rule allow ip4 from me to "table($broadcast)" out xmit but did not see any outgoing multicast traffic from MiniDLNA. Also, when MiniDLNA is running before I add the interface route for 244.0.0.0/4, the VLC test client does NOT discover the MiniDLNA server (despite the route). If, however, the MiniDLNA service is (re)started after the route is in place (but before the test client is running), it does detect the server immediately. I therefore suspect that the "MiniDLNA startup code" does something different when the route is there as compared to when it is not. But I don't know what... I assume it is not related to mrouted (which is NOT running)? Also, again, if setting the interface route for 224.0.0.0/4 absolutely IS required, I will not be able to make my intended setup work. I have multiple interfaces connected to potential clients for MiniDLNA. Best regards andreas