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 -> 8.8.8.8 (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
> _______________________________________________
> freebsd-current@freebsd.org 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).

Attachment: pgpbo70O_Kjkd.pgp
Description: OpenPGP digital signature

Reply via email to