Switch chip not working?

Omnia hardware Omnia HW help
41

Firewalling is all well and understood. But that is not my concern.

https://openwrt.org/docs/guide-user/network/vlan/switch_configuration

Virtual Local Area Network, it is a virtual partitioning of physical network switches on OSI layer 2.
It is a way to keep network clients separated from each other even if they use the same shared physical network, without setting up a whole subnet and a router.
It works by adding a label (VLAN ID) on networking traffic, and using this label to route the traffic to keep isolated clients in different VLANs.

Since the switch chip is managing the VLAN it would be expected to prevent access between different VLAN ids like it is common in soho/commercial switch appliances.

The traceroute from one VLAN (id1 with subnet 192.168.112.0/24) client to the other (VLAN id2 with subnet 10.168.112.0/24) is not passing the CPU (hoop) but goes straight in between (which should not happen).

Summary

tracetcp 10.168.112.12

Tracing route to 10.168.112.12 on port 80
Over a maximum of 30 hops.
1 Destination Reached in 2 ms. Connection established to 10.168.112.12
Trace Complete.

tracert 10.168.112.12

Tracing route to 10.168.112.12 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 10.168.112.12

Trace complete.

Commonly a management VLAN would not be established by firewall rules but by assigning different VLAN ids.

42

As far as I know communication between subnets is always(!) routedā€¦

1 Like
43

Yes but when thereā€˜s a route between these VLANs (which is automatically set up by rour TO) the isolation must also be set up on Layer 3

44

If it was routed by the kernel (CPU) it should show the CPU as hoop in the trace, no?

45

Yes it should. Are you sure the 2 clients are not in the same subnet? (Maybe they have 2 interfaces?). As I said as far as I understand OSI layers communication between subnets must be routed, they can not happen on Layer 2ā€¦

46

It is possible on layer 2 if the clients are in same VLAN id

Summary

https://www.youtube.com/watch?v=aBOzFa6ioLw

Yes.

47

In my understanding VLAN is just simulation of more wires over one physical wire (very simply said) and thatā€™s the only security. Because attacker always can sniff traffic for VLANs and set it manually on NIC to reach any VLAN he wants.

Subnets cannot see each other but can reach each other. In my experience there must be drop rule.

48

Maybe that is a shortfall of this chip or this kernel or some software bug but normally in a switch it does not require a firewall rule to create an isolated (traffic) VLAN, e.g. a management VLAN

49

I believe it is not the switch but routes forwarding.
In some cases GW can be set to not reply on ICMP etc.
Could you try drop rule? If it will work (block) then you will have confirmed that forwarding is done after switch - means by CPU.

1 Like
50

I think so, too. But proof us wrong :+1:t3:

Edit: And isolation works for me

1 Like
51
Summary 
config defaults
	option syn_flood '1'
	option output 'ACCEPT'
	option input 'DROP'
	option forward 'DROP'

config zone
	option input 'DROP'
	option forward 'DROP'
	option output 'ACCEPT'
	option name 'guest'
	option network 'guest'

I can still ping/traceroute the client on the other vlan.

The video link I posted above surely shows that it works without any routing instructions on layer 3 and that different vlan id lead to vlan isolation. Or just look up management vlan. It is all done on the switch and does not require firewall rules.

52

He said (in video) that they cannot communicate over switch but they can communicate over router (8:45) or layer3 switch

By drop rule I mean SRC DST DROP (classic firewall rule). Could you try please? Iā€™m quite confident from my experience itā€™s necessary to do so.

Edit: imagine there is a router on the right side of the switch in video. Then flow loops back from router to switch to another client.

1 Like
53

iptables -I INPUT -s 192.168.112.192 -d 10.168.112.12 -j drop ping/traceroute do not work and it proves that traffic passes through the CPU and indeed being rerouted to the other VLANā€¦

I am going to play with

--vlan
        Attribute 1 (int): port_based (Use port-based (non-802.1q) VLAN only)

And see whether that makes a difference.

1 Like
54

Please share results after. Iā€™m interested.

55

Same outcome, i.e. without that particular fw rule the client on the other side can be pinged/tracetouted.
Run a network scanner which thus picked up the scent of if the other node.

Not certain but seems that the vanilla fw rules are not preventing network sniffing between vlans, i.e. some in the guest vlan could potentially start sniffing around the hostā€™s lan.

Further reading confirmed whilst the vlans being invisible on layer 2. However, it seems that fine tuning security/privacy in general is possible but the switch chip lacking such feature set (or swconfig) - Promiscuous port (P-Port) and Host port. Host port further divides in two types ā€“ Isolated port (I-Port) and Community port (C-port)

Traffic from an Uplink port to an Isolated port will be denied if it is in the Isolated VLAN. Traffic from an Uplink port to an isolated port will be permitted if it is in the primary VLAN.

I hope it is understandable now that I have been wondering about isolation/segregation (management vlan) without firewall rules.

What I am not understanding is why in vanilla TOS eth2 is bridged in lan.

Also curious why kmod-8021q is not being installed in vanilla.

56

Tried openvswitch but did not succeed in completing the setup, in particular adding port eth0 or wlan0 did not provide connectivity.

Which might be down to my ignorance or netifd / hostpad being vastly out of sync with the upstream repo and neither being expected to receive updates in the TOS 3.x branch.

57

I believe it is compiled into the kernel. Without it all the vlan configs on the cpu (like vlan 7 for Deutsche Telekom VDSL) would not work.

root@turris:/proc# cat /proc/config.gz | gzip -cd | grep 8021Q
CONFIG_VLAN_8021Q=y

While some advanced options might be missing, basic vlan based separation should work with the switch chip in the Omnia. That switch chip was pretty reliable in other devices I used so far.
The best way of implementing is to assume all VLAN IDs are global to the switch (some advanced switches can have the same vlan id representing different L2 networks) and that only basic ingress/egress filtering exists.
That means (for tag based VLANs):

  • a tagged port is going to output all traffic if part of the VLAN with vlan tag left intact
  • a tagged port will accept all tagged traffic with vlan tags which the port is a member of (note: the switch chip can be run in an mode which accepts all tagged traffic even if not for a vlan id it is member in)
  • a tagged port will output traffic matching is PVID without a vlan tag
  • a tagged port will put any incoming untagged traffic into the vlan matching itā€™s PVID
  • a untagged port will only output traffic of the vlan matching itā€™s PVID and the traffic will be without a VLAN tag
  • a untagged port will only accept traffic without a vlan tag and will put it into the VLAN matching itā€™s PVID (note that the switch chip supports a mode where it accepts tagged traffic for all VLANs too).

To test the segregation you could:

  • put the CPU port (port 5) into tagged mode
  • configure VLAN 1 on the CPU port (but no other VLANs)
  • configure LAN0 to be part of VLAN 1 in untagged mode
  • configure LAN1 to be part of VLAN 1 in untagged mode
  • ensure all other ports are not part of VLAN 1
  • create VLAN 3 and assign LAN2 to it in untagged mode
  • give VLAN1 (eth0.1) an IP on the omnia (CPU)
  • connect two clients to LAN0 and LAN1 and give them an IP network assigned to VLAN1 in the previous step
  • ping the client which should work and show the ethernet src/dst to be the MACs of the two clients
  • move one client (e.g. the one on LAN1) to LAN2 port and observe that the pings stop as the two clients canā€™t see each other

Note the reason for not presenting the VLAN 3 to the CPU is that it removes a lot of possible leaks.
By default Linux IP stack attaches to all interfaces and by default accepts/forwards even if if the packet arrives on an interface with no IP. (see sysctl rp_filter as one pointer)

@anon50890781 I suspect that you got a leak in your config somewhere. Iā€™d hazard a guess that if you successfully ping between hosts in different VLANs you will see that the src/dst MAC is not the one of the two hosts (likely it is one belonging to Omnia).

As @protree mentioned, feel free to share your config (and preferably a tcpdump/wireshark packetdump) of the two clients (filter on icmp and arp as that is the only two interesting parts).

1 Like
58

Appreciate the exhaustive/educational input that aligns with

The issue though is that the client looses connectivity as soon as the lan(1) port it is connecting through gets tagged applied. That is with a 3.11.2 vanilla medkit and client directly on the wire with the router in order to mitigate any potential traps. Vanilla as in far as having changed the password via Foris, exited and entered LuCI and commmited the network changes.

network setting already applied/working prior committing the last last step of tagging the lan(1) 
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd51:a952:0be8::/48'

config interface 'lan'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option _orig_ifname 'eth0 eth2'
	option _orig_bridge 'true'
	option ifname 'eth0.1'

config interface 'wan'
	option ifname 'eth1'
	option proto 'none'

config interface 'wan6'
	option ifname 'eth1'
	option proto 'none'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0t 1 2 3 5t'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4 6'
	option vid '2'
59

I think this is because if you set Port 1 tagged it has no PVID set any more, so client connected to Port 1 needs to send tagged Ethernet Packages (with vid1), non-tagged packages are dropped.

Edit: So this should be expected behaviour

60

Untagged frames are dropped both ways (up/down) on the port? Hmm, now I have to figure out then how to accomplish sending the PVID tag from the client. Whilst that might be doable with a single client directly over the wire I am not sure how that would work with the wire to air extenders on the network or any other client that gets connected over the air, not sure they all can facilitate sending a PVID tag. :frowning: