On Mon, 3 Jul 2017 06:29:41 +0200 "O. Hartmann" <ohartm...@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 for 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. Now, the router shows this: Internet: Destination Gateway Flags Use Mtu Netif Expire 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 ] 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 port 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). > > > > [ sysctl stuff snipped - not relevant, I think ] > > > > > > > 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. > > > > > > > > > > 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). > > > > > > > > > The problem still persists. I did some experiments by setting trying to ssh into several hosts from several 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 -> 126.96.36.199 (no DNS): ok Ping from any VLAN to another VLAN host without the trunking cable connected 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=0, even pinging > > > > host should not work. Try tcpdump to see what's going on. > > > [ schnipp ] > > > > 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. Since the VoIP phone has a very restricted interface and shell capability set, I need to do this from another FreeBSD 12-CURRENT host and as I showed above, I put that 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 may 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. > > 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-CURRENT > of a very well known OS. > > I'll check as soon as I have acces. > > > > Regards, > > Milan > > > > Thank you very much and kind regards, > > Oliver > _______________________________________________ > email@example.com mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
Description: OpenPGP digital signature