Different treatment for registered and unregistered MAC addresses - TCP-IP

This is a discussion on Different treatment for registered and unregistered MAC addresses - TCP-IP ; Hello Sorry if either of these is the wrong group for this query ... let me know if there's a better place to post this. Are there any routers / switches that allow you to route traffic from all unregistered ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Different treatment for registered and unregistered MAC addresses

  1. Different treatment for registered and unregistered MAC addresses

    Hello

    Sorry if either of these is the wrong group for this query ... let me
    know if there's a better place to post this.

    Are there any routers / switches that allow you to route traffic from
    all unregistered MAC addresses to a particular interface (say, the
    public Internet) and allow unrestricted acces to registered MAC
    addresses?

    I am setting up a network where internal personnel need to access our
    own servers, but would like to use the same network for vistors who
    should not be able to have their traffic routed to our internal
    infrastruture.

    Tx & rgds


  2. Re: Different treatment for registered and unregistered MAC addresses


    jeremy.brest@gmail.com wrote:
    > Hello
    >
    > Sorry if either of these is the wrong group for this query ... let me
    > know if there's a better place to post this.
    >
    > Are there any routers / switches that allow you to route traffic from
    > all unregistered MAC addresses to a particular interface (say, the
    > public Internet) and allow unrestricted acces to registered MAC
    > addresses?
    >
    > I am setting up a network where internal personnel need to access our
    > own servers, but would like to use the same network for vistors who
    > should not be able to have their traffic routed to our internal
    > infrastruture.



    My first comment is that this is a bad idea, and does not provide the
    security you want. Not the least problem is that MAC addresses are
    trivial to change, and trivial to figure out. Second, MAC addresses
    never pass a router (level 3) boundary, so any filtering has to be done
    on the same (bridged) network as the workstation of interest resodes.

    Plenty of routers and bridges (switches) allow you to filter on MAC
    addresses, lathough in the case of routers they might only do so for
    protocols they're bridging. So you might have to do two layers (a
    separate transparent bridge and then a router) - although that can be
    virtual and not necessarily two physical boxes.

    Given how easy MAC addresses are to spoof, why not just use IP
    addresses for filtering, and set up your DHCP server to allocate a
    certain range of IP addresses to the "known" MACs? Better yet, put two
    separate subnets on the same LAN, and give DHCP leases to one or the
    other based on MAC address, and then just bind the router interfaces to
    one (or both) subnets as appropriate (and have appropriate forwarding
    rules to prevent indirect routing back to the internal LAN).

    But again, no of that produces anything you could properly call
    security.

    If you really have both visitors and internal users on the same LAN,
    you should treat it as a DMZ (or worse), and require some form of
    authentication (and probably VPN) for your authorized users to access
    your internal network. That might be slightly easier to implement if
    this is wireless, where you could set up two overlapping wireless
    networks, one "public" and the other properly secured so that only your
    internal users can authenticate to the access points that connect back
    to your internal network. Over a wired LAN you might be able to deploy
    something like PPPoE, and authenticate at the PPP level and segregate
    traffic that way at the router at the other end of the PPPoE link.

    A problem with all of the schemes that will allow you to share a single
    LAN for both internal users an visitors is that it will require the
    internal users to authenticate, which will require at least some work
    for all of those installations. I like my "public" wireless
    overlay network. Leave your internal users wired (or on a separate
    wireless network), and just insist that the visitors have Wi-Fi
    adapters on their laptops.


  3. Re: Different treatment for registered and unregistered MAC addresses

    On Thu, 18 May 2006 19:34:53 -0700, jeremy.brest wrote:

    > Hello
    >
    > Sorry if either of these is the wrong group for this query ... let me
    > know if there's a better place to post this.
    >
    > Are there any routers / switches that allow you to route traffic from
    > all unregistered MAC addresses to a particular interface (say, the
    > public Internet) and allow unrestricted acces to registered MAC
    > addresses?
    >
    > I am setting up a network where internal personnel need to access our
    > own servers, but would like to use the same network for vistors who
    > should not be able to have their traffic routed to our internal
    > infrastruture.


    The usual way to set this up is to use 802.1x. Usual as in "it was
    designed for this task", I yet have to see the first deployment myself.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  4. Re: Different treatment for registered and unregistered MAC addresses

    > Are there any routers / switches that allow you to route traffic from
    > all unregistered MAC addresses to a particular interface (say, the
    > public Internet) and allow unrestricted acces to registered MAC
    > addresses?


    Yes you can do this with a switch. Use vlans and statically define the
    the ports or the MAC addresses into different vlans.

    > I am setting up a network where internal personnel need to access our
    > own servers, but would like to use the same network for vistors who
    > should not be able to have their traffic routed to our internal
    > infrastruture.


    Yep. The following might do what your wanting on a cisco switch:

    int fa0/1 switchport access vlan 2
    int fa0/2 switchport access vlan 2
    int fa0/3 switchport access vlan 3
    int fa0/4 switchport access vlan 3

    Put a non-bridging firewall between port 2 and port 4. Connect your
    internal net to port 1, your guest net to port 3. This is called a
    "router on a stick" configuration.

    Optionally you can use trunking to backhaul to the firewall on one
    port, but your router/firewall has to know how to do trunking in that
    case.

    -Matt


+ Reply to Thread