VLAN help GS1920

Network setup inherited from previous employee(s). Two geographically separated locations conntected via two Sophos XG firewalls with VPN. The VPN is deemed healthy by Sophos support and the VPN connection itself is as stable as it gets. Mostly everything seems to be working just fine except it seems the vlan-setup on the GS1920 isnt quite up to par. We have a server on one location not being able to communicate with a client on the other location. Plenty of details here so I've put it all in a Excel-document. Ive been trying to read up on how it is supposed to be setup, but alas, I'm afraid Im unable (due to time) to aquire the needed knowledge before this is becoming too urgent for the users. Any help would be greatly appreciated!!!


«1

All Replies

  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    When I read this well, LocB-LinuxIoT is not able to ping anything, including devices in the same location/vlan/subnet.
    Is it reachable on LAN at all?

  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    edited September 2021
    Thank you for your reply and sorry for the confusion. The ones marked green = ping OK, the ones marked red = timeout, the ones marked grey = it is not possible to do a ping *from* this device (ie the LinuxIoT thing has no interface or telnet...or any other way to control it)

    Edit: So all devices can ping "LocB-LinuxIoT" except "LocA-XGFW", "LocA-WinSrv" and "LocB-PC1"
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Ah yes. Now it makes sense. LocB-LinuxIoT doesn't seem to be able to communicate with anything outside it's subnet. So my guess is that it's default gateway is wrong. I think that should be 192.168.4.1.

  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    edited September 2021
    Yes that would explain the problems we're seeing, but the thing is that the *only* way to change the IP-settings on this device is to use a RS232 and manually set it with some special hardware & software. This was done summer 2020 and it has been working fine up until spring/summer 2021 when someone changed the Zyxel settings. 

    Edit: I dont have the knowledge, but still the vlan-settings on the GS1920 seems a bit weird to me if you look at the "VLAN Detail", "StaticVLAN" and "PortSetup" portions of the Excel-file.

    From what Ive been able to gather the 192.168.4.x-net (VID 1) is NOT vlan'ed (?). I do have basic network-knowledge so if someone in simple terms could explain how it should be setup I could perhaps try to do it myselves.
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Right. Only now I see the document contains more pages. Did you somewhere document which port is used by LocB-LinuxIoT?

    (802.1Q) VLAN's are not difficult to understand. What makes it difficult is that most switches support features which are possible due to the implementation in the switch chip, but which are not useful in real life. (Or it's at least very hard to make up a usecase).

    What you want is that a switch port is connected to a certain vlan, except a special case where you want to be able to carry several vlan's on a single wire, in most cases the uplink to the router, or to some other switch. Right?

    Basically a vlan is no more that a tag (the VLAN ID) in an ethernet packet. Due to this extra tag, the ethernet packet is no longer a 'plain, valid' ethernet packet. So all non vlan aware devices which need to extract the payload (in most cases an IP packet) will drop it, while devices which handle pure ethernet (switches) will simply forward it. (A non vlan aware switch can forward vlans, as long as it can handle the slightly bigger packets due to the tag).
    And yes, by convention VLAN 1 is 'plain ethernet', not containing the tag.

    For the 'several vlans on a single wire' scenario the switch has to select which vlans you want, and send them tagged outside, and drop all other packets. For the incoming data nothing has to be done, except maybe drop all packets containing a tag of another vlan (one which is not allowed on that port). This part is not hard.

    To get the simple 'port is connected to vlan' scenario, the switch needs to drop all outgoing traffic with the wrong tag, and strip the tag of the packages which actually go out. For the traffic going in, it needs to inject the tag. For some stupid reason this is implemented at two places. You have to untag the wanted vlan on one place, and inject the tag on another place. Tag injecting is called PVID. This seperation makes it error prone, while I can't think of a real life usecase where you want to have the send and receive of a switchport connected to different vlans. Further the implementation makes it possible to untag several vlans on the same port, while, of course, return traffic can only get one vlan tag.
    So rule of thumb: only one vlan should be untagged on a port, and PVID for that port should be set to the same vlan.
    Tagged vlans are seldom a problem, as the connected clients will simply ignore tagged packets.

    When you do something wrong, in most cases the connected client can't communicate at all, and that doesn't seem to be the case in your case, as the LocB-LinuxIoT can be pinged from it's own subnet.
    Of course it is possible that your device is vlan aware, and used a vlan to communicate to the server. (The Linux kernel supports vlan's out of the box, so any Linux client can be configured to use them).

  • Wow...thank you for the detailed reply. The "LocB-LinuxIoT" should NOT be vlan'ed. It is programmed to use 192.168.4.70. I've been trying to put the device into many of the ports that seems to be setup to be VID=1 ports, but none of them seems to be working. Could it be that there is some sort of "mismatch" in the setup between the "StaticVLAN" and "PortSetup"??


  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    h3ctic said:
    I've been trying to put the device into many of the ports that seems to be setup to be VID=1 ports, but none of them seems to be working.
    Not even in the port where LocB-PC2 is connected? Does LocB-PC2 work in the port where now LocB-LinuxIoT is connected? In that case it can hardly be a switch configuration problem, unless there is some significant difference between the PC and the IoT device that I don't see.

    Does the switch support port mirroring? In that case you could use Wireshark to see how the IoT device replies to ping (or doesn't).
    When you ping it from inside the subnet, you would expect an ARP request for the MAC address of the sender, to be able to create the return packet.
    341    3.670257468    172.23.172.155    172.23.172.196    ICMP    98    Echo (ping) request  id=0x0007, seq=120/30720, ttl=64 (reply in 344)
    342    3.671873693    IntelCor_c8:51:c2    IntelCor_ac:a1:cf    ARP    42    Who has 172.23.172.155? Tell 172.23.172.196
    343    3.671881855    IntelCor_ac:a1:cf    IntelCor_c8:51:c2    ARP    42    172.23.172.155 is at 80:19:34:ac:a1:cf
    344    3.984914004    172.23.172.196    172.23.172.155    ICMP    98    Echo (ping) reply    id=0x0007, seq=120/30720, ttl=128 (request in 341)
    When it's pinged from outside the subnet, it should request the MAC address of the gateway, and send the reply to that address.
    When there is no reaction at all (while the ping request arrives), then the device doesn't know where to send it, and so it doesn't have a gateway for the source address.

  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    edited September 2021
    The main problem is that 172.16.0.6 (LocA-WinSrv) is unable to communicate with 192.168.4.70 (LocB-LinuxIoT). As you can see the LocA-WinSrv is unable to ping any device in VID 1 except the SophosAP (192.168.4.101) - but I suspect that the SophosFW routes it directly somehow (since I know theres "special communication" between Sophos XG firewall/routers and their Access Points). LocA-WinSrv is able to ping LocB-PC1 but this PC is in the VID 200 which is NOT where the LocB-LinuxIoT should reside.

    Im not sure if the GS1920 supports port mirroring and I wireshark is not something Ive used before.

    I will however locate excactly what ports the different devices are using and do some testing by switching them around in the switch (most likely monday).

    Did you take a look at the 
     "StaticVLAN" and "PortSetup"....the setup looks a bit weird to me...

    Thanks again for your help!!

    (Edited some spelling)
  • Zyxel_Chris
    Zyxel_Chris Posts: 653  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    @h3ctic,
    Can you share IoT connect to which port? (I assume it's connect on 33 to 44), same question on device LocB-XGFW, Also which port is your uplink?
    Chris
  • Mijzelf
    Mijzelf Posts: 2,598  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    edited September 2021
    h3ctic said:
    The main problem is that 172.16.0.6 (LocA-WinSrv) is unable to communicate with 192.168.4.70 (LocB-LinuxIoT). As you can see the LocA-WinSrv is unable to ping any device in VID 1 except the SophosAP (192.168.4.101) - but I suspect that the SophosFW routes it directly somehow (since I know theres "special communication" between Sophos XG firewall/routers and their Access Points).
    LocA-WinSrv cannot ping LocB-PC2, but LocB-PC2 can ping LocA-WinSrv. In that case I suspect routing/firewalling rather than VLAN's.

    Did you take a look at the  "StaticVLAN" and "PortSetup"....the setup looks a bit weird to me...
    Yes I did, and I see some inconsistencies. Yet it is hard to read without knowing which port is suspicious. I must admit that it's some time ago I configured ZyXEL switches. And in that case I had 10 switches which supposed to be identical, but had 3 different firmwares, resulting in 3 different webinterfaces. Cannot remember why I didn't bring them all to the same firmware version. Maybe different hardware revisions. I'm more used to TP-Link (yes, I'm a cheap guy) and D-Link, but they all have the configuration weirdness I mentioned above.

    /Edit: Speaking about inconsistence: Why has this post two different fonts?

Nebula Tips & Tricks