Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 5200 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need advice -- moving from non-VLAN to VLAN environment

dmitripr
Hi all,

Need advice from the experts on the forums here.

So far I've had a pretty simple home network:  

cable modem  UTM  unmanaged switch  EAP600 AP, other wired devices (e.g. Synology, etc.)


I've bought a manged switch (Cisco SG200-26) and would like to setup 2 VLANs: (1) internal home network; (2) guest network to be accessible through guest SSID on my WiFi AP with station separation. 

Pretty self-explanatory: internal network will basically remain as it is today, I'm just adding a guest VLAN that will have access to internet only (maybe through transparent proxy or not, haven't decided yet). I would also like to throttle the traffic across the guest VLAN (should I do it on the UTM or the switch?). 

How would I go about moving from my current 2 physical interfaces (WAN, internal) on the UTM to 1 physical for the WAN and 2 internal logical interfaces of VLANs? Can someone maybe help with a basic step by step process that will yield the least downtime? Screenshots would be great, but not required, I can follow just bullet points. 

I understand conceptually how to do this, but would love to hear any best practices (e.g. setup switch first or UTM? does it matter?, etc.). 

Thanks!
D


This thread was automatically locked due to age.
Parents
  • 0
    Here is my take ....

    + The type of client device is irrelevant.  They are just along for the ride.

    + The issue is that the initial DHCPDISCOVER broadcast is being seen coming in on the tagged VLAN (your eth0.99), while at the same time the tag is being ignored by the DHCP server and it thinks the DHCPDISCOVER broadcast is on the untagged native VLAN (eth0).

    + Once the DHCP address is assigned, it is aware of what the correct network assignment should be.   But, the damage has already been done.

    A packet capture would still be needed as a sanity check to verify that only a single DHCPDISCOVER is coming in and that it is tagged.  Then we would know for sure that it is the UTM misbehaving.

    This is most likely a bug with no workaround.  Other than to change the configuration to 2 tagged VLAN's.  I suspect that it would work correctly then.
  • 0 in reply to DavidWilliams1
    Here is my take ....

    + The type of client device is irrelevant.  They are just along for the ride.

    + The issue is that the initial DHCPDISCOVER broadcast is being seen coming in on the tagged VLAN (your eth0.99), while at the same time the tag is being ignored by the DHCP server and it thinks the DHCPDISCOVER broadcast is on the untagged native VLAN (eth0).

    + Once the DHCP address is assigned, it is aware of what the correct network assignment should be.   But, the damage has already been done.

    A packet capture would still be needed as a sanity check to verify that only a single DHCPDISCOVER is coming in and that it is tagged.  Then we would know for sure that it is the UTM misbehaving.

    This is most likely a bug with no workaround.  Other than to change the configuration to 2 tagged VLAN's.  I suspect that it would work correctly then.


    You're probably right that it shouldn't be seeing a request on the untagged network. Though it seems that some clients can handle this better than others. I wouldn't say that the type of client is irrelevant completely -- in my limited examples clients are behaving somewhat differently to the same responses from the server. Not completely "along for the ride" -- takes two to tango. 

    According to RFC1541 (https://tools.ietf.org/html/rfc1541#section-4.3.2) the client has the ability to request a specific address out of the "pool" that was offered, and the server can decline, of course. In case of BB client, it just feels like it accepts the first offer from DHCP server, and ignores everything else. Whereas iPad continues to negotiate for a little longer. 

    I will try to do port mirroring to see if I can capture the packets. How did you do TCP dump on UTM, I couldn't find that option anywhere? Maybe that'll be easier than trying to do mirroring, etc. 

    Thanks!
Reply
  • 0 in reply to DavidWilliams1
    Here is my take ....

    + The type of client device is irrelevant.  They are just along for the ride.

    + The issue is that the initial DHCPDISCOVER broadcast is being seen coming in on the tagged VLAN (your eth0.99), while at the same time the tag is being ignored by the DHCP server and it thinks the DHCPDISCOVER broadcast is on the untagged native VLAN (eth0).

    + Once the DHCP address is assigned, it is aware of what the correct network assignment should be.   But, the damage has already been done.

    A packet capture would still be needed as a sanity check to verify that only a single DHCPDISCOVER is coming in and that it is tagged.  Then we would know for sure that it is the UTM misbehaving.

    This is most likely a bug with no workaround.  Other than to change the configuration to 2 tagged VLAN's.  I suspect that it would work correctly then.


    You're probably right that it shouldn't be seeing a request on the untagged network. Though it seems that some clients can handle this better than others. I wouldn't say that the type of client is irrelevant completely -- in my limited examples clients are behaving somewhat differently to the same responses from the server. Not completely "along for the ride" -- takes two to tango. 

    According to RFC1541 (https://tools.ietf.org/html/rfc1541#section-4.3.2) the client has the ability to request a specific address out of the "pool" that was offered, and the server can decline, of course. In case of BB client, it just feels like it accepts the first offer from DHCP server, and ignores everything else. Whereas iPad continues to negotiate for a little longer. 

    I will try to do port mirroring to see if I can capture the packets. How did you do TCP dump on UTM, I couldn't find that option anywhere? Maybe that'll be easier than trying to do mirroring, etc. 

    Thanks!
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?