Business CommunityGatewaysOmada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Gateways

Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails

Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails

Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Friday
Tags: #VLAN & Multi-Networks #ACL #Routing
Model: ER605 (TL-R605)  
Hardware Version:
Firmware Version:

Hi everyone,

 

I am running into a very strange issue with Omada inter-VLAN routing and I am trying to understand whether this is:

  • a bug
  • expected behavior
  • provisioning corruption
  • or something I fundamentally misunderstand.

 

Setup:

  • ER605 v2.0 gateway
  • Omada Software Controller (latest v6)
  • Omada switch SG2210MP
  • VLANs managed directly by Omada
  • Dockerized controller running in HOST mode
  • No Guest Portal involved for the actual issue
  • ACL tests already simplified heavily

 

Network example:

  • Main VLAN: 192.168.14.0/24
  • New VLAN: 192.168.21.0/24

 

Problem:
Devices in VLAN14 CAN access VLAN21.


BUT:
Devices in VLAN21 CANNOT access VLAN14.

Even simple ping fails.

Example:

  • 192.168.14.x → 192.168.21.x = works
  • 192.168.21.x → 192.168.14.x = fails

 

What makes this strange:

  • The VLAN21 gateway itself (192.168.21.1) is reachable
  • Inter-VLAN routing therefore clearly exists
  • ACLs were disabled completely for testing
  • Isolation settings show ZERO isolated networks
  • VLAN21 is NOT configured as guest network
  • No client isolation enabled
  • Devices tested via both WiFi and Ethernet
  • Same behavior reproduced in a second Omada setup at a friend’s house

 

Important discovery:
I also have a separate WireGuard instance running DIRECTLY on the ER605.
Through THIS WireGuard tunnel, VLAN21 becomes reachable correctly.

This strongly suggests:

  • ER605 CAN route the VLANs
  • VLAN21 itself is valid
  • this is probably not a hardware

 

 

Packet captures:
Using packet capture on the Omada switch, I can see ICMP echo requests from VLAN21 devices going to VLAN14 devices, but there is never any response.

Example:
192.168.21.53 → 192.168.14.100 ICMP Echo Request
(no response)

 

Additional notes:

  • I also tested with all LAN→LAN ACLs temporarily set to PERMIT ALL
  • Rebooted gateway and switches
  • VLANs are directly configured on the ER605 itself
  • No static routes should theoretically be required for directly attached VLANs

 

What confuses me:
This feels too basic to simply be “unsupported”.
Inter-VLAN routing between directly connected VLANs should normally work out of the box.

Has anyone seen:

  • asymmetric VLAN communication like this
  • stale ACL/provisioning bugs
  • Omada controller state corruption
  • hidden isolation behavior
  • ER605 quirks with software controller setups

Any ideas would be highly appreciated because I am running out of things to test.

 

Thank You...

0
0
#1
6 Reply
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Friday

  @FN737 

 

This should not be too hard to troubleshoot, depending on what you have available (such as a laptop, etc.).

 

In Omada networks, inter-VLAN routing is allowed by default unless a VLAN is isolated or ACLs are used to deny traffic.  You stated that the VLANs are not isolated and that your ACLs are all temporarily set to allow traffic.  With that being true, it would appear that something is misconfigured somewhere.

 

I would check:

1.  The VLAN settings (gateway IP, default gateway, DHCP and DNS settings) for each VLAN
2.  The gateway and switch settings for the trunk and access ports, ensuring the ports are correctly configured for the untagged/tagged VLANs.


If everything still appears to be correct, it would be helpful if you could post a topology map and some screenshots of your configurations.
 

1x ER7406 1x OC300 4x SG2008 1x EAP610 3x EAP650-Desktop 1x EAP772-Outdoor
0
0
#2
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Friday

  @jra11500 

Thank you for the reply.

Yes, according to Omada documentation, inter-VLAN routing should be allowed by default unless VLAN isolation or deny ACLs are configured. That is exactly why this behavior is confusing.

 

We already tested the following extensively:

- VLAN isolation is disabled
- ACLs were temporarily changed to fully allow traffic between VLANs
- Gateway ACLs were even removed completely for testing
- Devices and Omada equipment were rebooted multiple times
- Tested both wired and wireless clients
- Tested from multiple devices (Windows laptop, iPhone, NAS, Unraid server)
- Tested communication in both directions
- Tested access not only by ping but also TCP connections and direct service access
- Same issue reproduced on a second independent Omada setup at another location

 

Current behavior:
- Devices in VLAN1 (192.168.14.0/24) CAN access VLAN21
- Devices in VLAN21 (192.168.21.0/24) CANNOT access VLAN1
- Even the gateway IP of VLAN1 cannot be reached from VLAN21
- Packet captures show ICMP echo requests leaving VLAN21 but no replies returning

 

Additional important finding:
- A WireGuard tunnel running directly on the ER605 itself CAN correctly reach VLAN21 and other VLANs
- However, a VPS WireGuard server behind the Omada network cannot
- This suggests the ER605 routing itself works, but traffic handling/provisioning/ACL behavior inside Omada may be inconsistent

 

Hardware / software:
- ER605 v2.0
- SG2210MP switch
- Omada Software Controller running in Docker (host mode already tested)
- Latest available firmware versions installed

 

At this point it no longer seems related to a simple ACL or isolation configuration issue, because the same behavior was reproduced on two separate Omada installations with clean VLAN setups.

I can provide screenshots/topology if needed please let me know which one exactly. 

 

Thank You

0
0
#3
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Friday - last edited Friday

  @FN737 

 

Does your main VLAN (192.168.14.0/24) have a VLAN tag of 1 or 14?  In your first post, it was 14 and in your last post. it is 1.  Are you using a separate VLAN for management?  How many total VLANs do you have configured?

 

One last question...  Are you using any switch ACLs?

1x ER7406 1x OC300 4x SG2008 1x EAP610 3x EAP650-Desktop 1x EAP772-Outdoor
0
0
#4
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Monday

Hi @FN737 

 

Thanks for reaching out to TP-Link Business Forums.

 

Do you change the managment VLAN on the controller?

I agree with @jra11500 that there might be some misconfigurations on your settings. Could you please upload your VLAN and gateway settings to here for further investigation?

0
0
#5
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Monday

  @Gabriel-TP 

Hi Gabriel,

thank you for your reply.

I checked the Omada Software Controller (v6.x), but I could not find any global “Management VLAN” setting for the controller or the site itself.

Could you please tell me exactly where this setting is located in the current Omada Controller version?

I would like to verify whether a management VLAN is configured somewhere, but I cannot find a global option for it.

Could you please provide:

  • the exact menu path
  • or a screenshot/example
  • and whether this is configured globally, per device, or per port profile?

Thank you very much.

 

0
0
#6
Re:Omada strange inter-VLAN behavior: Main VLAN can access new VLAN, reverse traffic completely fails
Yesterday

Hi @FN737 

 

You may refer to this article: How to configure Management VLAN for Omada Devices | Omada Network Support

0
0
#7

Information

Helpful: 0

Views: 192

Replies: 6

Tags

VLAN & Multi-Networks ACL Routing
About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.