Bridged VLAN interfaces in v14

[bacquaviva]

Thanks.

Responding here so we can shortcut the support queue.

#1, can you start a ping 4.2.2.1 (or something) from behind vlan 10 internal so we can see traffic trying to reach the internet?
#2, vlan 10 internal is bridge to vlan 10 external, and there is a source route in wan balancer which is correct. However, the gateway for vlan 10 external is 10.1.1.1 does not respond, so that "WAN" is offline. You need to figure out why 10.1.1.1 is not responding to ARP requests. They are being sent.

on the wire (with the propert 802.1q tag)



from eth0.10 interface itself:



Until the gateway is reachable that WAN is going to be offline...

"However, the gateway for vlan 10 external is 10.1.1.1 does not respond, so that "WAN" is offline. You need to figure out why 10.1.1.1 is not responding to ARP requests. They are being sent." –
YES that is the point! If I knew why it was doing that, I wouldn't be in this thread or have opened a support ticket.

as for not being able to reproduce it, unless you can show me where i went wrong in the fresh build i setup just for this thread, i can reproduce it 100 times out 100. it does it when its behind a sonicwall or behind a unifi usg pro. it does it when its in front of a TPlink smart switch or a unifi switch. I’m out of hardware vendors to try on both ends of the bridge at this point. The only thing common is v14.

I don't know if It's a total fluke or not, but the two systems I’ve had running v14 that have vlans setup, after about 24 hours of uptime they started rebooting and would get stuck in a boot loop. none of my non vlan systems have done this (so far). so, the system i setup last night for this thread is no longer and a new UID is available if you want me to email it to you. and yes, 4th fresh install in two days that exhibits this behavior with vlans.

Please, show me in untangle where I’ve configured vlans wrong for v14 and I will happily change it.

[dmorris]

Nothing looks wrong to me. However, since your gateway does not respond to ARP requests, its going to be offline, so while nothing looks "wrong" I also see nothing surprising. It should be offline - the gateway is not reachable. It doesn't matter how much you change on Untangle or its configuration or version. Unless your gateway responds to ARP requests, Untangle won't be able to reach the gateway.

I would look at your switch configuration, or perhaps run tcpdump there or on the gateway itself to see if it sees the ARP requests, and if it replies, and if it does, where the replies are going. Is it seeing the ARP requests (on VLAN 10)? Is it responding?


edit: is there a switch between the sonicwall and untangle? it would be better/simpler if there wasn't but totally understand if thats not feasible. one less thing to troubleshoot between why arp resolution isn't working.

[bacquaviva]

In this instance, there no switch between.

I’m going to PM you a new UID. This is to a newly created v13.2.1 setup (like before, this is just for the purposes of figuring this out, if changes need to be made, feel free). VLAN tagging is working as it always has - well, since the beginning of support for them. I’m curious to know if this install has the same issues you were seeing with the fresh v14 install.

Assuming everything on v13.2.1 is working as it should (it is as far as I can tell), I would then like to upgrade that system to v14 (no changes other than the upgrade). Once its finished upgrading, I’ll let you know and you can take a look at it again to see what, if anything changes.

To kill two birds with one stone, I’ve installed the 13.2.1 on completely different hardware. Prior boxes were all SuperMicro w/ onboard Intel NIC’s. This one is a Dell OptiPlex with an add-in Intel NICs. I very highly doubt this has anything to do with it, but I’ve seen far stranger things…

[dmorris]

great! thanks!

[dmorris]

To those having issues try this patch:
https://wiki.untangle.com/index.php/...y_initializing

Huge thanks to bacquaviva for providing a testing setup for both 13.2.1 and 14.0.0 to find this issue!
We would have never found this without that!

[tizigman]

https://wiki.untangle.com/index.php/...y_initializing
The fix

[woodsky]

https://wiki.untangle.com/index.php/...y_initializing

This has fixed the problem for me too. Thank you bacquaviva, dmorris and the Untangle team! Thanks also to the others who've shared their experiences and comments here.

[rauder]

To those having issues try this patch:
https://wiki.untangle.com/index.php/...y_initializing

Huge thanks to bacquaviva for providing a testing setup for both 13.2.1 and 14.0.0 to find this issue!
We would have never found this without that!

The patch resolved my issue as well, however I'm a bit surprised that the Untangle engineering team did not setup a similar test lab after so many customers reported suspected problems with VLANs that worked well in prior software/hardware installations but failed after upgrading to v14.

[dmorris]

The patch resolved my issue as well, however I'm a bit surprised that the Untangle engineering team did not setup a similar test lab after so many customers reported suspected problems with VLANs that worked well in prior software/hardware installations but failed after upgrading to v14.

Its not that simple - If you look at the patch you will see it only happens depending on the way your interfaces are named because of a bad regex.
ie echo br-eth0-10 | grep "eth0.10"

Also, for the record, we still do not recommend installing like this. Thats why it says "not recommended" in bold and all caps. Untangle is a firewall/router, we suggest using it as such.

[TangleTamer]

I can confirm that the patch fixed my issue too. Was running untangle in transparent bridge mode with vlans in between unifi USG and unifi switch.

Also switched to the new kernel via “grub-set-default 0“