Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 5189 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.
  • 0
    priller,

    That's interesting. Your devices with the issue, which devices were they? Like Blackberries, or iPads, etc? Just trying to see if there is a pattern with a specific manufacturer. 

    I would hope that this should follow one of the IEEE standards and not be random. I've seen Blackberries being flaky when it comes to WiFi (some firmware versions), so I wasn't totally surprised by this case. 

    I'll need to do port mirroring and see what the WireShark captures. 

    Thanks!
  • 0
    Yes, very interesting.  It sounds like there might be an issue with this new capability.  If anyone with a paid license can duplicate this, please get a bug report to Support.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to dmitripr

    That's interesting. Your devices with the issue, which devices were they? Like Blackberries, or iPads, etc? Just trying to see if there is a pattern with a specific manufacturer. 


    I only had iPhone and MacBooks.  Very limited.  

    I just used tcpdump on the UTM to capture everything on the interface.  You can see the DHCP request/response to the tagged/untagged requests.
  • 0
    OK, I didn't have to do TCP dump, just looked at the DHCP log. Log entries below. (I edited the MAC addresses).

    First one for Blackberry: 

    2015:01:26-16:53:18 localdomain dhcpd: DHCPDISCOVER from 40:6f:2a:XX:XX:XX (BLACKBERRY ) via eth0

    2015:01:26-16:53:18 localdomain dhcpd: DHCPDISCOVER from 40:6f:2a:XX:XX:XX (BLACKBERRY ) via eth0.99

    2015:01:26-16:53:19 localdomain dhcpd: DHCPOFFER on 192.168.1.104 to 40:6f:2a:XX:XX:XX (BLACKBERRY ) via eth0

    2015:01:26-16:53:19 localdomain dhcpd: DHCPOFFER on 192.168.99.100 to 40:6f:2a:XX:XX:XX (BLACKBERRY ) via eth0.99

    2015:01:26-16:53:19 localdomain dhcpd: DHCPREQUEST for 192.168.1.104 (192.168.1.1) from 40:6f:2a:XX:XX:XX (BLACKBERRY ) via eth0

    2015:01:26-16:53:19 localdomain dhcpd: DHCPACK on 192.168.1.104 to 40:6f:2a:XX:XX:XX via eth0

    2015:01:26-16:53:19 localdomain dhcpd: DHCPREQUEST for 192.168.1.104 (192.168.1.1) from 40:6f:2a:XX:XX:XX via eth0.99: wrong network.

    2015:01:26-16:53:19 localdomain dhcpd: DHCPNAK on 192.168.1.104 to 40:6f:2a:XX:XX:XX via eth0.99



    Second for iPad: 

    2015:01:26-16:57:34 localdomain dhcpd: uid lease 192.168.1.109 for client 60:92:17:XX:XX:XX is duplicate on 192.168.1.0/24

    2015:01:26-16:57:34 localdomain dhcpd: DHCPDISCOVER from 60:92:17:XX:XX:XX via eth0

    2015:01:26-16:57:34 localdomain dhcpd: DHCPOFFER on 192.168.1.109 to 60:92:17:XX:XX:XX via eth0

    2015:01:26-16:57:34 localdomain dhcpd: DHCPDISCOVER from 60:92:17:XX:XX:XX via eth0.99

    2015:01:26-16:57:35 localdomain dhcpd: DHCPOFFER on 192.168.99.101 to 60:92:17:XX:XX:XX ( iPad) via eth0.99

    2015:01:26-16:57:36 localdomain dhcpd: DHCPREQUEST for 192.168.99.101 (192.168.99.1) from 60:92:17:XX:XX:XX ( iPad) via eth0: wrong network.

    2015:01:26-16:57:36 localdomain dhcpd: DHCPNAK on 192.168.99.101 to 60:92:17:XX:XX:XX via eth0

    2015:01:26-16:57:36 localdomain dhcpd: Wrote 0 deleted host decls to leases file.

    2015:01:26-16:57:36 localdomain dhcpd: Wrote 0 new dynamic host decls to leases file.

    2015:01:26-16:57:36 localdomain dhcpd: Wrote 18 leases to leases file.

    2015:01:26-16:57:36 localdomain dhcpd: DHCPREQUEST for 192.168.99.101 (192.168.99.1) from 60:92:17:XX:XX:XX ( iPad) via eth0.99

    2015:01:26-16:57:36 localdomain dhcpd: DHCPACK on 192.168.99.101 to 60:92:17:XX:XX:XX ( iPad) via eth0.99


    There is definitely a difference between the two. It seems that the duplicate request/response for the DHCP isn't totally the issue (just guessing here), it's which network it considers "wrong". For BB you'll notice the "wrong network" response for the 99 VLAN (which is incorrect). While for the iPad it sees the "internal" 1.0/24 as the "wrong network" (which is correct).

    Any other thoughts here?
  • 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!
  • 0
    How did you do TCP dump on UTM
      You need to log into the shell via ssh.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • 0 in reply to Scott_Klassen
    You need to log into the shell via ssh.


    OK, thanks! Is there a command that I need to run after logging in?

    EDIT:
    Nevermind, figured it out. TCPDUMP is the command.
  • 0
    I ran Wireshark on the wireless adapter of a Windows PC while I had it connecting to the guest network for the first time, and did see that there was only one DHCP discover request, I then checked DHCP log of the UTM and saw the same as before: 2 DHCP offers from eth0 and eth.99. 

    However, the PC was able to negotiate the correct address in the 99.0/24 space. That's a third device that's had no issues with negotiation of the correct DHCP address. After multiple tries on my Blackberry, it still can't do it correctly. 

    This is making me think that there is certainly a difference between how client devices interact and some can simply do a better job, based on how they're programmed. Not random. The only sure way to tell would be to wait for the next OS update for my BB, and see if that makes any difference.

    However strange, when I did port mirroring, mirrored the Access Point port, and did packet capture, after several tries I could never actually capture the initial DHCP request frame. It did capture the ARP requests and DHCP offers, but not the initial discover request. Not sure why. Hence, I just resolved to capture directly from PC's wireless adapter.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?