Date: Tue, 11 Jul 2017 22:48:04 +0200 From: "O. Hartmann" <ohartmann@walstatt.org> To: freebsd-current@freebsd.org Cc: "O. Hartmann" <ohartmann@walstatt.org>, Milan Obuch <freebsd-current@dino.sk>, Freddie Cash <fjwcash@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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" <ohartmann@walstatt.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170711224804.25628840>