Openwrt not working with Unifi switch but other 3rd party firmware works with same unifi switch

meazz1 · December 20, 2020, 3:26pm

I'm having an issue with OpenWrt on x86 setup.

New setup with openwrt:
1 have setup my Openwrt X86 which has eth0 & eth1.
eth1=wan
eth0=eth0.1 - lan 192.168.4.0/24
eth0.20 - vlan20 10.0.20.0/24
Netgear managed switch is setup with trunk port
T=untagged, lan
= tagged, vlan20

With the above setup, Openwrt behind my main Opnsense router everything in Openwrt works, I can browse internet and depending on which port on the netgear switch I get specified IP on my pc/laptop.

My Opnsense setup is X86 router with eth1 & eth0 running Opnsense & Unifi switch 60W.
same setup as above except here I'm using an Unifi managed switch Lan and Vlan profile. This setup works flawlessly.

Now the issue,
If I take the Opnsense out and replace with Openwrt router, the Vlan devices gets Ip address but no Lan devices receives
any IP.

So, the question is, there's something with Openwrt Lan interface setup and unifi switch.

Pls advice and ask if I'm missing any critical info.

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdc0:0ad1:e372::/48'

config interface 'lan'
        option proto 'static'
        option ipaddr '192.168.4.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ifname 'eth0.1'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'
        option peerdns '0'
        list dns '9.9.9.9'
        list dns '1.1.1.1'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'

config interface 'VLAN20'
        option proto 'static'
        option ipaddr '10.0.20.1'
        option netmask '255.255.255.0'
        option ifname 'eth0.20'

/etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan wan6'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        ist icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'
config include
        option path '/etc/firewall.user'

config zone
        option network 'VLAN20'
        option forward 'REJECT'
        option output 'ACCEPT'
        option name 'VLAN20'
        option input 'REJECT'

config forwaeding
        option src 'VLAN20'
        option dest 'wan'

config redirect
        option dest_port '51820'
        option src 'wan'
        option name 'WG(VPN'
        option src_dport '51820'
option target 'DNAT'
        option dest_ip '192.168.4.8'
        option dest 'lan'
        list proto 'udp'

config rule
        option dest_port '53'
        option name 'VLAN20 DNS'
        option target 'ACCEPT'
        option src 'VLAN20'
        option dest 'wan'

config rule
        option name 'VLAN20 DHCP'
        option target 'ACCEPT'
        list proto 'udp'
        option src 'VLAN20'
        option src_port '67 68'
        option dest_port '67 68'
config forwarding
        option dest 'wan'
        option src 'lan'

config forwarding
        option dest 'wan'
        option src 'VLAN20'

config forwarding
        option dest 'VLAN20'
        option src 'lan'

psherman · December 20, 2020, 3:33pm

Your lan is currently tagged (eth0.1). You probably want that to be simply eth0 so that it is untagged on eth0, to match your switch trunk configuration.

meazz1 · December 20, 2020, 9:56pm

Thanks for the quick solution. It's working great now.
One question, what does eth0.1 do? Does it tag Vlan1?

dlakelan · December 20, 2020, 9:59pm

exactly, eth0.1 is emitting and receiving only tagged packets.

Normally it's a good idea on any port that you have some tagged packets, make everything tagged.

psherman · December 20, 2020, 10:14pm

@meazz1 - the comment above is a matter of personal preference / professional opinion and also context specific. @dlakelan is a proponent for all tagged networks on any trunk line -- this is totally valid and there are some really good reasons to follow this advice. That said, this is not a hard requirement and there are some situations where having an untagged network on a trunk can be useful and/or necessary. The 802.1q standard allows trunks to consist of zero or one untagged networks + one or many tagged networks -- so do what makes the most sense for your environment.

P.S. I'm pretty sure @dlakelan and I have had some friendly debates about this topic in these forums.... @dlakelan is extremely knowledgable and gives really good advice, so it is worth considering the advice .

dlakelan · December 20, 2020, 10:25pm

Thanks for the kind words, and no problemo with what you said here. You're absolutely right that it's not a hard requirement. The main reasons for sticking to all tagged is I think primarily to not wind up accidentally leaking packets onto the wrong vlan. If one interface is using untagged packets, then the VLAN it's talking on is not part of the config of the machine it's a config of the switch, and that could change either on purpose or accidentally. When the port ID is set up incorrectly, a machine sending untagged packets expecting them to show up on vlan 1 for example might wind up being on some other vlan, and it wouldn't even know! If the machine is set up so that it only has tagged interfaces, each one is clearly tagged what its supposed to be.

But there are probably valid reasons to leave one untagged. Like for example if you have a desktop machine that mostly acts like a desktop machine, but occasionally needs to access a different vlan for configuring things or similar, just adding tagged access to that vlan could make sense and make the config of the desktop machine simpler. Other situations may arise.

psherman · December 20, 2020, 11:10pm

Another example is Unifi equipment. It generally prefers to have the management network untagged. It is possible to use tagged networks, but that is a relatively recent addition (maybe ~2-3 years ago, if memory serves).

To me, one of the most compelling arguments for untagged networks on a trunk is the home scenario combined with "if I get hit by a bus" -- if someone without knowledge of VLANs needed to say swap out a router or something in my absence, the untagged network scenario on the trunk would make it just kinda work. Not that it is ideal (but then again, neither is getting hit by a bus ), but it is less likely to cause significant confusion or downtime for the main network. Again, this applies to a home setup where the others in the home may not be so network savvy.

system · December 30, 2020, 11:10pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.