M4300 Inter-VLAN routing not over default gateway

[oheymanns]

Hello Community,

I need your help, please. Maybe this topic has already been discussed here, but unfortunately I have found nothing. I have two questions about the switch.

1.
We have created 3 4300-52G in the cluster, created VLANs and enabled VLAN routing. PCs have got the right IPs to the VLANs, the cluster also acts as a gateway. Intra-VLAN routing and access from the VLANs to the Internet also works.

My problem:

The packets are sent via the default route to my firewall. On my firewall (Sonicwall) the packets also appear with the correct source IP but on the wrong interface (VLAN254). All my firewall rules will not work with the wrong source vlan.

My question:
Is there a way not to take the Default Gateway but to stay in the VLAN of the PCs?

2nd question
How can I prevent clients from a VLAN from accessing the web interface of the switch?

Switch
MGMT 10.21.254.240 (V254) GW 10.21.254.1
PCs 10.21.21.0/24 (V21)

firewall
10.21.254.1 (V254)
PCs 10.21.21.1 (V21)
If you need more information please let me know.
I would be very grateful for your help!

[LaurentMa · Accepted solution]

OK thank you very much. I believe it won't work per your requirements with current static routing. I would revert back to pure Layer 2 installation of your VLAN 12 and your VLAN 21. These two VLANs should not be "routing VLANs" anymore and all their traffic should be sent to your firewall straight. A trunk with all VLANs should go to your firewall and your firewall should act as the gateway for VLAN 12 and VLAN 21. This way, your firewall rules will function normally. @schumaku do you think the same?

The switches' management VLAN 254 can remain a routing VLAN, in order to let all services function normally in the switch. I hope this helps - 

[schumaku]

Aehm, wild guess this is because of these PCs are using the Sonic Wall IP as the default gateway. In the "fun" of a static IP routing environment, you have to make the relevant switch routing interface the default gateway instead.

[oheymanns]

Hello schumaku,

Thank you for your prompt reply.

No, the switch is the gateway for the PCs. Please see the attachment below.

[oheymanns]

The second picture is the packet capture of my sonicwall. You can see the ingress interface.

[schumaku]

Still correct - looks like the switch default gateway (configured along the management IP config) is on the VLAN 256. The fun of static routing. All traffic flowing out over one VLAN, over that one subnet with the (management, sigh...) IP network, nd that network is on VLAN 256.

You seem to expect that the switch does inter-VLAN routing while keeping the "outgoing" traffic dedicated on each VLAN which is connected to the security appliance, do you?

[oheymanns]

No, i know the definition of the defaut route and i know that the switch does everything right. I am not expecting that the switch send the traffic to dedicated vlan but i would make my job easier if it worked. 

If it does not work, then please answer the second question. How can I prevent the PCs from accessing the web interface?

THX!

[schumaku]

---

@oheymanns wrote:

No, i know the definition of the defaut route and i know that the switch does everything right. I am not expecting that the switch send the traffic to dedicated vlan but i would make my job easier if it worked. 

If it does not work, ...xxxx

I'm still confused. 

What is "if it worked" and "if it does not work" here?

What test/ping is done on this Windows PC? Any routing between the switch connected and L3 routed subnets must work locally on the switch, undoubted.

The security appliance does receive the ICMP originating from the PC LAN interface on the VLAN 256 with a subnet different from the routing config for this very VLAN on some 192.168.0.x subnet, or this is another subnet on the security appliance as it says forwarded to 192.168.0.2. As this subnet isn't a part of the switch routing config, I state it's correct that the traffic is sent to the switch default gateway.

@oheymanns wrote:

How can I prevent the PCs from accessing the web interface?

What is the relation of PCs to the switch management interface - in VLAN, in IP addresses, ....?

In general, I tend to put up outgoing ACLs from networks I don't want to grant access to the management VLAN, based on IP or based on the services run on the management network. 

It's hard to provide community assistance based on very limited information. I'm not Netgear, further on I have no access to a crystal ball, too.

[oheymanns]

Sorry for the confusion and thank you for your time.

The PC is on VLAN 21 with the IP 10.21.21.100 and ping a device on the sonicwall with a separeted network. The netgear switch is on mgmt V254 and send all outgoing traffic over V254 to my sonicwall. But the destination ip is not important, the source VLAN254 that receives the sonicwall is the problem. I would prefer if the switch would send the traffic not over VLAN254 but over VLAN21 to the sonicwall. if I understood you correctly, that will not work.

The PC on VLAN21 can open the webinterface on 10.21.21.240. How can i deny the access?

[schumaku]

Let's try to call in @LaurentMa here. On one hand ref  an ability to configure just inter-VLAN L3 routing for attached networks but keeping a plain L2 LAN-local default gateway & as well a user friendly KB on how to protect the management port/L3 router LAN IP from access by direct connected devices. I know there are a few KB entries, but it's more than crzptic for the average network admin. Merci @LaurentMa 8-)

[LaurentMa]

Hi,

<<The PC on VLAN21 can open the web interface on 10.21.21.240. How can I deny the access?>>

The web interface is a routing IP interface here, too. So, it is reachable by definition. I would use a Management Access Control and Administration List (ACAL) to restrict the access to the web interface. 

Overview:
In order to ensure the security of the switch management features, the administrator may elect to configure a management access control list. The Management Access Control and Administration List (ACAL) component is used to ensure that only known and trusted devices are allowed to remotely manage the switch via TCP/IP. Management ACLs are only configurable on IP interfaces, not on the service port.

Note: A Management ACAL is essentially an IP ACL that is configured in the hardware the same way as other ACLs. This means, for example, that when a Management ACAL is configured for the HTTP service, only HTTP packets are allowed for that network but all other IP packets are dropped by an implicit “deny all” rule. NETGEAR Fully Managed Switches Management ACAL allows configuration of the following services: HTTP, HTTPS, SNMP, SSH, TELNET and TFTP to provide a minimal set of services. Exceptions to this are the DHCP, DNS, TFTP, and NSDP (SCC) services which are always enabled to allow the switch to obtain an IP address, enable SCC discovery, etc..

Operation in the Network:
When a Management ACAL is enabled, incoming TCP packets initiating a connection (TCP SYN) and all UDP packets will be filtered based on their source IP address and destination port. Additionally, other attributes such as incoming port (or port-channel) and VLAN ID can be used to determine if the traffic should be allowed to the management interface. When the component is disabled, incoming TCP/UDP packets are not filtered and are processed normally.

There is also an option to restrict all the above packets from the network interface. This is done by specifying “console only” in the MACAL component. If this is enabled, the systems management interface is only accessible via the serial port. All TCP SYN packets and UDP packets are dropped except UDP packets sent to the DHCP Server or DHCP Client ports.

 You can configure the MACAL using the Web GUI: 

Security / Access / Access Control / Access Profile Configuration and Access Rule Configuration. You can follow the User Manual found on the support page:

User Manual starting page 527.

I would allow a few IP addresses for instance for HTTP, HTTPs, Telnet - and deny access to all others. Let us know how it goes!

[oheymanns]

Thank you for the great and detailed answer. I'll go to the ACLs right now;)

Can you please answer the first question too? The PC in VLAN21 sends its request to its gateway (switch with IP 10.21.21.240). If he does not know the net, he sends everything through his default gateway (10.21.254.1). That's correct and it works.
But can the switch route in the client's VLAN? So for example to the 10.21.21.1 in the VLAN21? My problem is that now all packets arrive at my firewall via VLAN254.

Thanks!

[schumaku]

The routing problem is related to the fact that the L3 switch/routers do the full routing, anything beyond the Inter-VLAN routing does flow out on the [management!] VLAN holding the switch CPU port default gateway (except of what might be rerouted by static routes). I would love to hear if @LaurentMa has some magic hands (read: more product insight) to proof I'm wrong. 

[LaurentMa]

We would need to see the routing table before making any guess (would a Layer 2 setup be more suitable to your application, or should we continue tuning the static routes).

Please post a screenshot of the Weg GUI learned routes at Routing\Routage Table\Advanced\Route Configuration - thanks in advance

[schumaku]

@LaurentMa on a side note: Users are often confused because we tend to talk of "Inter-VLAN routing" in the documentation and the community. This does raise the impression that L3 routing can work "just" for the routing between the VLANs, while everything else can be covered the L2 way e.g. a VLAN traffic can be "routed" to a direct L2 connection.  

[oheymanns]

learned routes

[oheymanns]

10.21.12.0 is an other VLAN 12 for other PCs on an other M4300 switch with the ip 10.21.254.241. Do you need any other information?

[LaurentMa · Accepted solution]

OK thank you very much. I believe it won't work per your requirements with current static routing. I would revert back to pure Layer 2 installation of your VLAN 12 and your VLAN 21. These two VLANs should not be "routing VLANs" anymore and all their traffic should be sent to your firewall straight. A trunk with all VLANs should go to your firewall and your firewall should act as the gateway for VLAN 12 and VLAN 21. This way, your firewall rules will function normally. @schumaku do you think the same?

The switches' management VLAN 254 can remain a routing VLAN, in order to let all services function normally in the switch. I hope this helps - 

[oheymanns]

I already thought so. Now I have also the proof. Thank you both for the clearing and the help!