Wired Intelligent Edge

last person joined: 2 days ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

This thread has been viewed 9 times
  • 1.  Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 04, 2020 11:17 AM

    Hi, OSI scares me, and this is my first foray into enterprise networking. I have lots of questions, but I’m only going to ask a few of them as they will most likely answer some others, but also create new ones.

     

    I have a 2930f and I am making it overcomplicated on myself, because why not?

     

    My questions stem mainly around VLANs, how they are managed/worked, and how ACLs function within them.

     

    First, to set this up these are the VLANs I have created and an image of the desired ACL outcome of how these VLANs will talk with each other.

     

    vlan 1

    name "DEFAULT_VLAN"

    ip address 192.168.1.2 255.255.255.0

     

    vlan 5

    name "Me"

    ip address 192.168.5.2 255.255.255.0

     

    vlan 10

    name "Management"

    ip address 192.168.10.2 255.255.255.0

     

    vlan 20

    name "Cameras"

    ip address 192.168.20.2 255.255.255.0

     

    vlan 30

    name "Servers"

    ip address 192.168.30.2 255.255.255.0

     

    vlan 40

    name "Wired"

    ip address 192.168.40.2 255.255.255.0

     

    vlan 50

    name "Wireless"

    ip address 192.168.50.2 255.255.255.0

     

    vlan 60

    name "Wireless Guest"

    ip address 192.168.60.2 255.255.255.0

     

    vlan 70

    name "IoT"

    ip address 192.168.70.2 255.255.255.0

     

    accessaccess

     

    Is that informative enough to understand my desires? I will also be utilizing a separate pfSense firewall, but only for higher level management. I will not be using pfSense in a router-on-a-stick fashion; all of the routing and intervlan routing will be done at the switch level. The ‘network’ itself is pretty bland: ISP Modem in bridge mode > pfSense Firewall > 2930f (One 48 port PoE) > everything else.

     

    I would like the 2930f to handle DHCP.

     

    Again, assume I have zero understanding of how this stuff works.

     

     

    I know that part of it is that I need to enabled ‘ip routing’, and the plan was to have the upstream firewall at 192.168.10.1, so I would need to have a ‘ip route 0.0.0.0 0.0.0.0 192.168.10.1’ for that, correct?

     

    Is there an issue with the firewall being in this vlan? Does it need to be in its own separate vlan? VLAN10 will not have management mode enabled, it’s simply a VLAN for “backend” devices. Should this be done with the ‘no switchport’ option and just point it at the port it’s plugged in to?

     

    What gateway should the vlans have? If one at all. Should they all point to the 192.168.10.1 address of the firewall, or should they be pointing to their own 192.168.x.1 “vlan specific firewall”? I suppose a further question would be – for the devices downstream in this vlan, what would their gateway be? Would it be the switch specific in their vlan: 192.168.x.2, the vlan specific firewall 192.168.x.1, or the actual firewall IP address of 192.168.10.1?

     

     

    Moving on to the next can of worms – ACLs. I’m assuming that extended acls are the choice for this? Ideally, I would like to take advantage of the log feature, but I’m not married to it. On the onset I plan on just doing blanket allow/deny for all ports, but I may eventually get more specific with blocking certain ports, or only allowing certain ones.

     

    For some reason, I cannot wrap by head around the ACL in/out designation, and on what vlan they should be placed on. What is the standard practice? Should in or out be used? Should ACLs be based on the source or destination vlan? Are in rules on the destination vlan best? Our out rules on source vlan? Is there a need to have in on src, or out on dest ever?

     

    ACLs are top>down first match, yes? When creating the ACL initially, is there a need to specify the sequence numbers, or only when I need to modify in the future and need to add something between two, and have to specific 12 or 15 or something?

     

    Should I manage internet blocking at the switch level, or should I let the firewall do that part? From what I understand that firewall will still need to have an understanding of what VLANs the switch has, and will need to be created there to be able to send that internet request back to the source. I suppose it’s just a matter of reporting at that point? Do I want to see that deny on the switch or firewall?

     

    The other question at the top of my head is access to switch management in each vlan. As it is, any vlan would have access to log in to the switch at 192.168.x.2. Enabling management mode on a separate vlan that only works on a specific port would stop that yes? Though I am not sure I want to do that As I would like to be able to access the switch management from some of the other vlans. Is there another way to achieve this? Or is the only other option to use port specific rules in ACLs to block 80/443 in each vlan to 192.168.x.2?

     

    Lastly, one thing I have not ventured in to is how the wireless guest access will alter the current layout. I have a unifi AP I will be using, and plan to use the guest feature. While the AP does have two ports, the secondary is only a bridged port, and cannot be configured as a separate “guest” port back to the switch. So, I think this means instead of two separate vlans for Wireless and Wireless Guest, they need to be on the same vlan, and be tagged ports, is that correct? I need to do some more reading up on this, but I should still be able to apply ACLs based on those tags? Or what would be the best way to handle that?

     

     

    I would be grateful for anyone who could spend a bit of their time to assist me with these questions - I've watched a few videos and tutorials. I will be glad to fill in any blanks that I can. I do have some other questions, but this is the high-level stuff I have for the moment.

     

    Thank you!



  • 2.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    EMPLOYEE
    Posted Aug 04, 2020 03:46 PM

    Hi,

     

    Here are some replies to the extended questions list

     

    I know that part of it is that I need to enabled ‘ip routing’, and the plan was to have the upstream firewall at 192.168.10.1, so I would need to have a ‘ip route 0.0.0.0 0.0.0.0 192.168.10.1’ for that, correct?

     

    Spoiler
    Yes it is correct. But you also need to add a route back from firewall for every subnet since the switch will not support NAT..

    ip route 192.168.1.0 255.255.255.0 192.168.10.2

    ip route 192.168.5.0 255.255.255.0 192.168.10.2

    ip route 192.168.20.0 255.255.255.0 192.168.10.2

    ip route 192.168.30.0 255.255.255.0 192.168.10.2

    ip route 192.168.40.0 255.255.255.0 192.168.10.2

    ip route 192.168.50.0 255.255.255.0 192.168.10.2

    ip route 192.168.60.0 255.255.255.0 192.168.10.2

    ip route 192.168.70.0 255.255.255.0 192.168.10.2

     

    Is there an issue with the firewall being in this vlan? Does it need to be in its own separate vlan? VLAN10 will not have management mode enabled, it’s simply a VLAN for “backend” devices. Should this be done with the ‘no switchport’ option and just point it at the port it’s plugged in to?

    Spoiler
    It is normal to have a transit VLAN for routing.. In your case you are calling it management but it is actually used for routing.. It is better not to have backend devices on this vlan and strictly use it for routing..

    What gateway should the vlans have? If one at all. Should they all point to the 192.168.10.1 address of the firewall, or should they be pointing to their own 192.168.x.1 “vlan specific firewall”? I suppose a further question would be – for the devices downstream in this vlan, what would their gateway be? Would it be the switch specific in their vlan: 192.168.x.2, the vlan specific firewall 192.168.x.1, or the actual firewall IP address of 192.168.10.1?

    Spoiler
    You said you want the switch to handle all the routing and not the firewall. The gateway must be a device on the same vlan as the device.. So in your case, for every vlan you will have the gateway as 192.168.X.2 which is the IP address of the switch

    Moving on to the next can of worms – ACLs. I’m assuming that extended acls are the choice for this? Ideally, I would like to take advantage of the log feature, but I’m not married to it. On the onset I plan on just doing blanket allow/deny for all ports, but I may eventually get more specific with blocking certain ports, or only allowing certain ones.

     

    For some reason, I cannot wrap by head around the ACL in/out designation, and on what vlan they should be placed on. What is the standard practice? Should in or out be used? Should ACLs be based on the source or destination vlan? Are in rules on the destination vlan best? Our out rules on source vlan? Is there a need to have in on src, or out on dest ever?

     

    Spoiler
    It is easier to a follow one approach to simplify the configuration. I prefer to use ACLs in the inbound direction everywhere  (if I am forced to use ACLs).. As such, you will apply one ACL per vlan in inbound direction. You need to match both on source and destination to meet your connectivity requirements..

    ACLs are top>down first match, yes? When creating the ACL initially, is there a need to specify the sequence numbers, or only when I need to modify in the future and need to add something between two, and have to specific 12 or 15 or something?

    Spoiler
    By default, whenever you create an ACL entry, its position will increment by 10. So your first entry will be 10, second 20, 3rd 30..etc. You can add entries in between by specifying the position number.. Yes, ACLs are processed one entry at a time and the first match will be executed..

    Should I manage internet blocking at the switch level, or should I let the firewall do that part? From what I understand that firewall will still need to have an understanding of what VLANs the switch has, and will need to be created there to be able to send that internet request back to the source. I suppose it’s just a matter of reporting at that point? Do I want to see that deny on the switch or firewall?

    Spoiler
    Usually, Internet blocking should be done at firewall level since usually firewalls have Layer 4-7 visibility.. In that case, you might want to review your design (For example make the gateway of the guest traffic directly on firewall and doing the filtering there.. ) You can also do the filtering on the switch side (You usually block the traffic that you don't want first then you allow the rest that you want..)

     

    The other question at the top of my head is access to switch management in each vlan. As it is, any vlan would have access to log in to the switch at 192.168.x.2. Enabling management mode on a separate vlan that only works on a specific port would stop that yes? Though I am not sure I want to do that As I would like to be able to access the switch management from some of the other vlans. Is there another way to achieve this? Or is the only other option to use port specific rules in ACLs to block 80/443 in each vlan to 192.168.x.2?

     

    Spoiler
    Check the ip authorized-managers command to allow access from specific subnets only.. You will also need to make sure that your ACLs don't block the management access from the subnets that you want..

    Lastly, one thing I have not ventured in to is how the wireless guest access will alter the current layout. I have a unifi AP I will be using, and plan to use the guest feature. While the AP does have two ports, the secondary is only a bridged port, and cannot be configured as a separate “guest” port back to the switch. So, I think this means instead of two separate vlans for Wireless and Wireless Guest, they need to be on the same vlan, and be tagged ports, is that correct? I need to do some more reading up on this, but I should still be able to apply ACLs based on those tags? Or what would be the best way to handle that?

     

    Spoiler
    If the AP supports tagging, then you configure the switch port as tagged with multiple vlans that map to your wireless networks..

     

    Hope this is a bit helpful..



  • 3.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 05, 2020 03:37 PM

    Thank you for replying to each segmented question, Ayman!

     

     

    Part1..

    I assumed incorrectly on what the attached device to that vlans gateway would be then. Instead of my vlan IP addresses being 192.168.x.2, it's typical of the gateway being x.1 in the rest of the world. Not that this matters, but how does this then translate in to the firewall? If I want the firewall to be 192.168.10.1 (really just something .1) but that won’t work if all the gateways are x.1 - is there a best practice of what the firewall IP address should be? Should it be 192.168.10.2 instead? 

     

    ip route 0.0.0.0 0.0.0.0 192.168.10.2

    ip route 192.168.1.0 255.255.255.0 192.168.10.1

    ip route 192.168.5.0 255.255.255.0 192.168.10.1

    ip route 192.168.10.0 255.255.255.0 192.168.10.1

    ip route 192.168.20.0 255.255.255.0 192.168.10.1

    etc

     

    Is there a typical way of handling the "best practice" of IP addressing with this?

     

    On your topic of transient vlans - Do I need to rethink what vlan my firewall is in? Should I leave it in the default vlan 192.168.1.2? Or just create a new vlan with only the firewall in it?

     

     

    Part2..

    I want to address ACLs a bit more in-depth, but first I want a slight better understanding as I continue to research them.

     

    As an example, though, you mention having ACLs based on the IN direction, so the ACLs will be based on source then since source is the first IP listed in the 'ip access-list extended' command? Silly question, do I need to have a rule for its own subnet?

     

    Would this be an accurate ACL for the Servers VLAN?

     

    ip access-list extended "Servers" log

    10 permit ip 192.168.5.0 255.255.255.0 192.168.30.0 255.255.255.0

    20 permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0

    30 permit ip 192.168.30.0 255.255.255.0 192.168.30.0 255.255.255.0

    40 permit ip 192.168.40.0 255.255.255.0 192.168.30.0 255.255.255.0

    50 permit ip 192.168.50.0 255.255.255.0 192.168.30.0 255.255.255.0

    60 permit ip 192.168.70.0 255.255.255.0 192.168.30.0 255.255.255.0

    70 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

     

    vlan 30

    name "Servers"

    ip access-group "Servers" in

    ip address 192.168.30.2 255.255.255.0

     

    Instead of line 70, should it be "70 deny any any" or does it not matter?

     

    How would this work for vlans that are supposed to reach the firewall? Should I add explicit denys to the other vlans, and have a permit any any at the end? How does ‘ip route 0.0.0.0 0.0.0.0 192.168.10.1’ play a rule in this?

     

    I agree with the firewall handling actual internet handling, but sorry for the confusion, as an example, the Server VLAN shouldn’t need internet access, should I deny that at the ACL level, OR let the server vlan access to the firewall, and then block all traffic from that IP address on the firewall – does it matter?

     

     

    Part3..

    Thanks for the management and tagging info, I will look in to that a bit more.. but I’m having a bit of trouble understanding how the VLANs come in to play with this.

     

    Do I tag them both on the same switchport and then do the configuration on the AP:

     

    vlan 50

    name "Wireless"

    tagged 40

    ip address 192.168.50.2 255.255.255.0

     

    vlan 60

    name "Wireless Guest"

    tagged 40

    ip address 192.168.60.2 255.255.255.0

     

    And in the AP, define the SSID of whatever wireless is as 192.168.50.2 and whatever the SSID of guest route to 192.168.60.2?

     

     

    Again, thank you!



  • 4.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    EMPLOYEE
    Posted Aug 06, 2020 08:18 AM

    Here is my reply for the below...

    Spoiler

     

    For part 1, there is no right/wrong way. You can configure any IP as the gateway. Yes, I usually see customers using the first IP (.1) or last IP (.254) as the gateway in each subnet. The recommended option is to use a consistent approach and to use sequential IP address pools wherever possible instead of randomly selecting VLANs and IPs.

    For the below request,

     

    On your topic of transient vlans - Do I need to rethink what vlan my firewall is in? Should I leave it in the default vlan 192.168.1.2? Or just create a new vlan with only the firewall in it?

     

     

    Spoiler
    You need one vlan to route traffic between your switch and gateway. The vlan needs to exist on your switch and firewall (unless it is configured as access port)

    For this part,

     

    Would this be an accurate ACL for the Servers VLAN?

     

    ip access-list extended "Servers" log

    10 permit ip 192.168.5.0 255.255.255.0 192.168.30.0 255.255.255.0

    20 permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0

    30 permit ip 192.168.30.0 255.255.255.0 192.168.30.0 255.255.255.0

    40 permit ip 192.168.40.0 255.255.255.0 192.168.30.0 255.255.255.0

    50 permit ip 192.168.50.0 255.255.255.0 192.168.30.0 255.255.255.0

    60 permit ip 192.168.70.0 255.255.255.0 192.168.30.0 255.255.255.0

    70 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

     

    vlan 30

    name "Servers"

    ip access-group "Servers" in

    ip address 192.168.30.2 255.255.255.0

     

     

    Spoiler
    Your approach is correct but the configured ACL is not. The traffic initiated in vlan 30 has the source of 192.168.30.0/24 so only line 30 will match some traffic and line 70 will deny everything else. You need to write your commands based on the source address. Also the mask is 0.0.0.255 and not 255.255.255.0 (if you write the acl as permit ip 192.168.30.0/24 192.168.5.0/24, the switch will automatically configure the wildcard mask)

    10 permit ip 192.168.30.0 0.0.0.255 192.168.5.0 0.0.0.255

    20 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

    etc..

    70 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

     

    Instead of line 70, should it be "70 deny any any" or does it not matter?

    Spoiler
    It is the same

    How would this work for vlans that are supposed to reach the firewall? Should I add explicit denys to the other vlans, and have a permit any any at the end? How does ‘ip route 0.0.0.0 0.0.0.0 192.168.10.1’ play a rule in this?

    Spoiler
    Usually, you build your network by configuring the switching/routing then you add the firewalling/ACLs. The switch is doing switching/routing for the traffic. If a traffic reaches it and it doesn't have a route for it, it will send to its default gateway which is the firewall. Based on the policy of the firewall, it will allow the traffic and once the reply arrives it needs to have a route back to reach the switch..

    I agree with the firewall handling actual internet handling, but sorry for the confusion, as an example, the Server VLAN shouldn’t need internet access, should I deny that at the ACL level, OR let the server vlan access to the firewall, and then block all traffic from that IP address on the firewall – does it matter?

    Spoiler
    You can do it at either.. Try to do in a consistent manner though to make your operations easier.. If you are 100% sure that no server will need internet access, then do it at the switch ACL level (as such you will save the resources on the firewall and you do the filtering as close as possible to the source)

    For part 3, check the below

     

    vlan X

    name "AP_MGMT"

    untagged 1 <--- This is the port where the AP is connected (add additional ports as needed)

     

    vlan 50

    name "Wireless"

    tagged 1 <--- This is the port where the AP is connected (add additional ports as needed)

    ip address 192.168.50.2 255.255.255.0

     

    vlan 60

    name "Wireless Guest"

    tagged 1 <--- This is the port where the AP is connected (add additional ports as needed)

    ip address 192.168.60.2 255.255.255.0

     

    I would strongly recommend you attend an Aruba Switching fundamentals training or consult an Aruba partner to help you in the setup..



  • 5.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 07, 2020 04:33 PM

    Let’s assume I want to use 192.168.x.1 as my gateway for everything, and I want vlan10 as the one with my firewall in it. Namely I will need to change all my VLANs to x.1 instead of x.2, not a big deal. Nothing else really changes.

     

    vlan 10

    name "Management"

    ip address 192.168.10.1 255.255.255.0

     

    I would need to change the default ip route though from ‘ip route 0.0.0.0 0.0.0.0 192.168.10.1’ to ‘ip route 0.0.0.0 0.0.0.0 192.168.10.x’ or whatever I change the firewall ip address to.

     

    Question: Is there a typical IP address for upstream firewalls? I know it doesn’t matter, but I’m just curious. I suppose in this situation I’ll lean towards .254

     

    Question: I planned vlan10 to be a limited access vlan where very secure things are to be in; with the firewall in the “management” vlan10 (again, not management mode, just backend devices), is there concern with all default traffic coming to this vlan, namely the firewall specific IP, when ACLs are blocking everything to it mostly? Such as:

     

    ip route 0.0.0.0 0.0.0.0 192.168.10.254 (just adding this as reference)

    10 permit ip 192.168.10.0 0.0.0.255 192.168.5.0 0.0.0.255

    20 permit ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255 (this isn’t needed, since no routing within the same vlan?)

    30 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255

    40 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

     

    How would that work?

    Would I need a ‘35 permit ip 192.168.10.254 0.0.0.1 192.168.0.0 0.0.255.255’ ?

     

    On the topic of ACLs – I thought I had understood it, but I guess not. If I am adding an IN ACL on vlan10, wouldn’t IN indicate vlan10 is the destination (coming IN to vlan10) and only take affect when traffic is coming from another vlan in to vlan10? Or am I completely misunderstanding? ‘10 permit ip 192.168.10.0 0.0.0.255 192.168.5.0 0.0.0.255’ is saying .10.0 is the source, and .5.0 is the destination, why wouldn’t we want to place this as an IN acl on vlan5? This seems backwards to me lol.

     

    Thank you for the other info, I understand what you are saying about the internet traffic and AP stuff.



  • 6.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 13, 2020 03:44 PM

    I think I wrapped my head around ACL in/out src/dest.

     

    I was thinking in terms of "inside" of the switch - IE the packet is already made it in to the switch, so when using an "in" acl on a vlan, I assumed that acl was meant for the vlan of destination since the packet would be coming in to that as the dest, and so the source IP of that acl were the other VLANs.

     

    That is incorrect, I needed to think it terms of coming IN TO the switch - IE: PC1 > VLAN1 > VLAN2 > PC2

     

    An in acl is placed on vlan1, and means a packet coming to it from PC1, and an in acl placed on vlan1, that vlan ip would be the src address of the acls, with the destination of other vlans.

     

    Is that correct?

     

    Ugh, I was finding this so hard to follow but I read a few more KBs, and finally found one that mentions looking at it from a different perspective.

     

     

    Ayman, or anyone else, would you please have some time to give me some feedback on my previous questions?

     

    Thank you!

     



  • 7.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    MVP GURU
    Posted Aug 13, 2020 08:39 PM

    I think a correct approach to understand how to manage VLAN ACLs (quoted from an old thread) "is that you need to view them from the perspective of the routing engine of the switch, not from the perspective of the VLAN, so incoming is traffic FROM that VLAN [*] to other VLANs and outgoing is traffic TO that VLAN from other VLANs."

     

    [*] from the VLAN you're applying the ACL.

     

    Don't know if that is totally correct but I always try to imagine to be "sat down on the router engine" on the particular VLAN SVI interface (where I'm applying the ACL) and looking at the sources/destinations declared on ACE as seen from that point of view (so incoming, if applied IN).



  • 8.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 14, 2020 04:35 PM

    That does help, yes. It's some much similar when thinking about it in those terms.

     

     

    I should have asked this earlier since I assumed this would be the case.. but ACLs will communication in a deny direction when it's being requested from an allowed source, yes?

     

    The last time I touched firewall stuff was back in Microsoft ISA Server days.

     

    If I have two VLANs where vlan1 has an allow to vlan2, but vlan2 has a deny to vlan1 - as long as vlan1 initiates the request in to vlan2, then two vlans will freely communicate over that port/session/request, right?



  • 9.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    MVP GURU
    Posted Aug 15, 2020 01:17 PM

    @SephYuyX wrote: If I have two VLANs where vlan1 has an allow to vlan2, but vlan2 has a deny to vlan1 - as long as vlan1 initiates the request in to vlan2, then two vlans will freely communicate over that port/session/request, right?

    No.

     

    If VLAN 1 is allowed to talk with VLAN 2 BUT VLAN 2 is denied to talk with VLAN 1...then VLAN 1 is permitted to initiate a talk with VLAN 2 but that VLAN 2 will never answer because it is not permitted to talk to VLAN 1 (this is asymmetric...I know)...it's like when you talk to someone which is not permitted to answer...it stays muted...but...there is a way to permit a VLAN to talk back unidirectionally to ESTABILISHED connections only incoming from a particular VLAN...where, normally, that particular VLAN can't talk (is denied) by starting connections form itself to that particular VLAN and it's not denied when the connection is due to a response from incoming connections from that particular VLAN.



  • 10.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 16, 2020 12:04 PM

    Fascinating - thanks for the link. Given the KB phrase of "This is actually quite interesting and tricky communication security requirement.", and the date of creation, I am quite surprised. I have never been in an organization where the assumption is just because one lan1 can talk to lan2, lan2 can freely talk to lan1 - it's always been restricted based on source being the initiator, and only then can lan2 talk with lan1. So I just assumed this was the default behavior, but it makes sense it is not.

     

    Rabbit hole after rabbit hole..

     

    As I understand it, the "established" option does the work of a couple things to where it's essentially allowing ack, but blocking syn from leaving the blocked vlan. Fun.

     

    Since UDP is a stateless protocol is there a best practice way for trying to simulate a similar experience as the tcp established method? Or basically SOL and should just limit any udp permits on both vlans to specific ports only?

     

    IE: If I were running NTP on server in vlan1 where vlan2 should not be able to communicate - UDP 123 should be the only port opened?

     

    DHCP is a little more "secure" since it has separate server/client ports to where the blocked vlan would just need to be listening to the client port, and most other protocols have a TCP counterpart. 

     

    I don't really plan on using NTP anyway (possibly one day us DHCP though), so I may just not worry about UDP stuff anyway.

     



  • 11.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 22, 2020 05:26 PM

    I didn't even get out of the starting gate. Tired a few things first, but could not get my PC (In "Me" VLAN) talking to the Management VLAN switch IP of 192.168.10.1 (or another PC in that VLAN). Both PCs can access the switch in their own VLANs.

     

    Now I have it down to just the bare bones, and still doesn't work? What am I not understanding?

     

    Also, is it not possible to look at the acl logs without a syslog server? I would have thought any acl permit/denies could be viewable somewhere in switch debug/logging?

     

    I must be missing something really simple. I also removed default gateway since that's not used in ip routing mode, and removed "ip route 0.0.0.0 192.168.10.254" from the config for the time being (it will eventually be uplink firewall/router).

     

    I should need that stuff just to achieve routing within the switch? Am I missing a need of a gateway even for that?

     

    ip routing
    vlan 1
    name "DEFAULT_VLAN"
    no untagged 1-52
    no ip address
    exit
    vlan 5
    name "Me"
    untagged 1
    ip access-group "Me" in
    ip address 192.168.5.1 255.255.255.0
    exit
    vlan 10
    name "Management"
    untagged 2-52
    ip access-group "Management" in
    ip address 192.168.10.1 255.255.255.0
    exit
    ip access-list extended "Me"
    10 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 log
    exit
    ip access-list extended "Management"
    10 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 log
    exit

     

     

     



  • 12.  RE: Routing, VLANs, ACLs, Gateways, Tagging - Otherwise known as "I know nothing"

    Posted Aug 25, 2020 09:38 AM

    Poked at it a bit more, reset to defaults and started over, but still the same results. My PC in vlan5 can't ping vlan10 gateway, and vice versa.

     

    Any thoughts on why this may be?

     

    Aruba-2930F-48G-PoEP-4SFP(config)
    Internet (IP) Service

    IP Routing : Enabled

    Default TTL : 64
    Arp Age : 20
    Domain Suffix :
    DNS server :

     

    | Proxy ARP
    VLAN | IP Config IP Address Subnet Mask Std Local
    -------------------- + ---------- --------------- --------------- ----------
    DEFAULT_VLAN | Disabled
    Me | Manual 192.168.5.1 255.255.255.0 No No
    Management | Manual 192.168.10.1 255.255.255.0 No No

     

    IP Route Entries

    Destination Gateway VLAN Type Sub-Type Metric Dist.
    ------------------ --------------- ---- --------- ---------- ---------- -----
    127.0.0.0/8 reject static 0 0
    127.0.0.1/32 lo0 connected 1 0
    192.168.5.0/24 Me 5 connected 1 0
    192.168.10.0/24 Management 10 connected 1 0