From owner-freebsd-current@freebsd.org Tue Jul 11 20:48:16 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 039ADDABD28 for ; Tue, 11 Jul 2017 20:48:16 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69E7C675CE for ; Tue, 11 Jul 2017 20:48:15 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.227.219.210]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M7YF5-1dqOst0nP5-00xLC0; Tue, 11 Jul 2017 22:48:12 +0200 Date: Tue, 11 Jul 2017 22:48:04 +0200 From: "O. Hartmann" To: freebsd-current@freebsd.org Cc: "O. Hartmann" , Milan Obuch , Freddie Cash Subject: VLAN routing fails from VLAN -> non VLAN [was: Re: static routes on VLAN on CURRENT] Message-ID: <20170711224804.25628840@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170703062941.4eb9658d@freyja.zeit4.iv.bundesimmobilien.de> References: <20170702133957.1f337a2e@hermann> <20170702143934.2bbcc98a@zeta.dino.sk> <20170702201344.274eb23d@hermann> <20170702211217.0d22b349@zeta.dino.sk> <20170703062941.4eb9658d@freyja.zeit4.iv.bundesimmobilien.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/AhWem03ZjpQdyt=N=hambZS"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:DighPVxmOyrpGsUpVVMf/RfkIcR2xHHY6ssCs7eGZ5xjpd8C6wD Co8C4LufiRSlS6uu40OIh1tQQkof4aspEehSGXnKamJ9bCKaYmkMxwy8hk8VyGntHUDnama /9S5rQcSvGOc2XySzV5qQnh6aXt3LqE2PJp6H1xKmrwQ/jofnKQpkn79oeYbV/0QRZVXjJn acQDZeXyefvOkmEd3dTJQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:hYxQ3dkO9Vw=:OPuOlDLb4p9qutQFXb+4TM HAh1tOt8XM6p00iRYpk6rdPUVo2GYqg4Pd2SPgeu7p49R3m/dPFTGkC+vQ4FqEP0eqC69Rtbz njh3KXHu8SSP0wbGLSURgpsX135vFsCKceucvPoWch3fCCbnZjlwD7U4k/2OpCmGO9gJn1vOW 4C14XXRicJaTw6Ml3bU0OmPC1MYjrNRTTyJWfX95XcP39O0bvJc+5qv1yjpXIkD6VRCA5XHLj Fp5CcsoyOH8Caw8XDJ1TJKZwKuu3aq3gBd5YFy86jReQLbffO1KbbGWgPU7nqa/QbNkBAjjpc A70juqG+J/aK4nk24bDJ8TZr/qFwQUWh6Ap4KjRHmWJ6xKz0Gpp3B8/w/IOhVRJy5SL4zI0kf 169owiq3bdgoyREVCrmg13VcAZDjd9IfwLXk7F1SX/EcN34W7g6TBdBemiQNJwvayIVDsRKAT wX7EezNYErfbbumJ5BcqsT3H1zGQk+FxCOiQd86tc+naMgB6vWzc7F1Lzc7xNXAZ7J9M2hzt3 7qy8LeUt8zuq3kxgxgTTBZFDqpuCgVZ381XM0KGUwYg4MqYIacI3rebIKRtfF8+peZ4eApnoa +0hdd0v/yQE3TFwSBjK1ZrxbOR0+j/bLoyoKL1J98Ez1TEruQc8oya18N0DU27ftfTpHtJENB LaL87NOxcE6Mj3WDUU2UmUzvolKh8k9YN/SHT1py06tBcDK8NaUkThXrm9//AfWFqB2FVsNz+ fZat7sXhG9SMeOjAFJE/Z38/wRybCpyW05gtDYcm3NDdD1wUq92AiZ5lcSM= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 20:48:16 -0000 --Sig_/AhWem03ZjpQdyt=N=hambZS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 3 Jul 2017 06:29:41 +0200 "O. Hartmann" wrote: Hello, I figured some severe problemes with the configuration of the cheap SoHo smart-managed switch Netgear GS110TP. This piece of crap is way to smart fo= r me. For short: If one leaves a port as "U" (untagged) withing a VLANG group in = the membership configuration and this port is also member of another VLAN as "U" (untagged) (Cisco calls those ports access ports), nothing works. There= is obviously no consistency check for such mistakes. So, after that, I was able to manage separated VLANs on the switch which get routed by the a freeBSD 12-CURRENT. The uplink port (igb1) on the FBSD box "trunks" all VLANs to the switch.=20 Now, the router shows this: Internet: Destination Gateway Flags Use Mtu Netif Exp= ire default xxx.xxx.xxx.xxx US 513 1492 tun0 xxx.xxx.xxx.xxx link#12 UHS 0 1492 tun0 xxx.xxx.xxx.xxx link#12 UHS 0 16384 lo0 127.0.0.1 link#5 UH 111 16384 lo0 192.168.2.0/24 link#7 U 0 1500 igb1.2 192.168.2.1 link#7 UHS 0 16384 lo0 192.168.10.0/24 link#8 U 0 1500 igb1.10 192.168.10.1 link#8 UHS 0 16384 lo0 192.168.66.0/24 link#10 U 0 1500 igb1.66 192.168.66.1 link#10 UHS 0 16384 lo0 192.168.100.0/24 link#11 U 0 1500 igb1.100 192.168.100.1 link#11 UHS 0 16384 lo0 192.168.0.0/24 link#9 U 0 1500 igb1.1000 192.168.0.1 link#9 UHS 0 16384 lo0 [ schnipp ]=20 tun0 is the ppp opened device towards my VDSL modem. ssh on the router box is listening on 192.168.0.1 - this for completeness. I also have FreeBSD hosts in networks 192.168.0.0/24 and 192.168.10.0/24 (network 192.168.10.0/24 is on a dual port NIC, the host is not gatewaying, checking pinging from 192.168.10.0/24 to 192.168.0.0/24 without the trunk p= ort from switch towards the router doesn't work, but works, when trunk port is connected - I consider this a s quick test that routing works). > >=20 > > [ sysctl stuff snipped - not relevant, I think ] > > =20 > > > > > From the routing device itself, it is possible to ssh into a VoIP > > > > > client attached to the switch to which igb1.2 trunks the net. > > > > > Pinging is also possible. > > > > >=20 > > > > > Attached to igb1 is the 192.168.0.1/24 network with a bunch of > > > > > hosts. From any host within this network it is possible to ping > > > > > the 192.168.2.0/24 network and its hosts within, but no SSH, not > > > > > web (80, 443).=20 > > > > > =20 > > > >=20 The problem still persists. I did some experiments by setting trying to ssh into several hosts from sev= eral spots. the router has 192.168.0.1:ssh 192.168.0.0/24 is on igb1.1000 ping: 192.168.0.111 -> 192.168.0.1 : ok ssh: 192.168.0.111 -> 192.168.0.1 : ok ping: 192.168.0.1 -> 192.168.0.111 : ok ssh: 192.168.0.111 -> 192.168.0.111 : ok ping: 192.168.0.111 -> google.com : ok 192.168.66.0/24 is on igb1.66 host 192.168.66.111 is a notebook with sshd enabled ping: 192.168.66.111 -> 192.168.0.1 : ok ssh: 192.168.66.111 -> 192.168.0.1 : NOT ok ssh: 192.168.0.1 -> 192.168.66.111 : NOT ok (do not understand this) ping: 192.168.66.111 -> 8.8.8.8 (no DNS): ok Ping from any VLAN to another VLAN host without the trunking cable connecte= d to the switch fails. With the cable plugged in, ping works. ping: 192.168.0.1 -> 192.168.2.50 (VoIP phone): ok ssh: 192.168.0.1 -> 192.168.2.50 (VoIP phone): ok ping: 192.168.0.111 -> 192.168.2.50 (VoIP phone): ok ssh 192.168.0.111 -> 192.168.2.50 (VoIP phone): NOT ok > > > > Weird - if icmp (ping) works and tcp (web, ssh) not, something is > > > > filtering traffic. But with net.inet.ip.forwarding=3D0, even pinging > > > > host should not work. Try tcpdump to see what's going on. =20 > > >=20 [ schnipp ] > >=20 > > Then I just recommend tcpdump - I would use 'tcpdump -nepi igb1.2 host > > 192.168.0.x and host 192.168.2.y' and 'tcpdump -nepi igb1 host > > 192.168.0.x and host 192.168.2.y' in two session and compare outputs > > when pinging from 192.168.0.x to 192.168.2.y and when trying to ssh > > from the former to the later. Also there is a question then what these > > two devices are, what OS are they running, their network > > configuration... then we can analyse the problem better.=20 Since the VoIP phone has a very restricted interface and shell capability s= et, I need to do this from another FreeBSD 12-CURRENT host and as I showed above, I put t= hat host into VLAN 66, bound to igb1.66 -> 192.168.66.1/24 on the router: Pinging from 192.168.0.111 <-> 192.168.66.111 gives on both machines nice "= ping-pong" results: echo request and echo reply. But ssh from one to the other is a mysterium magnum. ssh from 192.168.0.111= -> 192.168.66.111 gives something like 192.168.0.111 > 192.168.66.111: Flags [S] An never a response. The same in the opposite direction. Since I don't have= much computers to test (I need the notebook for setting up the switch) results m= ay be a bit sloppy. It seems that for the vlan 66, vlan 2 and even the vlan 10 (I did also test= ) there is never a return answer ... I have no further ideas :-( Oliver p.s. Also with ipfw (which is in-kernel) switched to allow everything, the = picture is the same. =20 >=20 > Thank you very much for the details of analysing. I regret, at the moment= I > have no access to the facility. But except the device bearing the IP > 192.168.2.y, which is a commercial VoIP endpoint, other parties are 12-CU= RRENT > of a very well known OS.=20 >=20 > I'll check as soon as I have acces. > >=20 > > Regards, > > Milan > > =20 >=20 > Thank you very much and kind regards, >=20 > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/AhWem03ZjpQdyt=N=hambZS Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWWU5hAAKCRDS528fyFhY lLRBAf4rpTOuU/5GM9wOUFgKxcN3UD7RuI1/rsXo2sRV3t9wN0tVzowd/HnlUrqV 0OO0ffmULKKfxwlknBxyHxfpb5lsAf9d9S5WNrbs1DursjWDrqrJZLyr4B7FOuZY zMMaul7mpCnQ6PTjQak96LqCJI5D5CW3bYLPm9SQzOami7Hb/3t0 =QZ/G -----END PGP SIGNATURE----- --Sig_/AhWem03ZjpQdyt=N=hambZS--