Breaking out of a VLAN


#1

Surf SOHO HW2 with firmware 7.1.1s064 build 3203

I was playing with the logging feature of the Windows 10 firewall and found that it logged some traffic that I did not expect to see at all.

The Win10 machine is ethernet connected to the router on the untagged LAN. Its subnet is 192.168.1.x. The router also has a WiFi network that is assigned to a VLAN that does not allow inter-vlan routing. This wifi network is using the 10.44.44.x subnet and WPA2 Enterprise.

There is an iPad connected to the Wifi network with IP address of 10.44.44.105.
The router is assigned 10.44.44.4 in this subnet.

The Windows 10 firewall, logged this activity

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2018-11-04 10:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 11:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 12:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 13:44:50 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 12:18:18 ALLOW UDP 10.44.44.4 255.255.255.255 67 68 0 - - - - - - - RECEIVE

It seems as if packets escaped from the VLAN and were visible to the 192.168.1.x untagged LAN.

Granted these are special IP addresses and I don’t know what they are used for, but should anything break out of a VLAN?

Layer 2 isolation was NOT on for the VLAN at the time. I have since enabled it. I had overlooked it because the advanced VLAN settings are not visible by default.


#2

@Michael234 Checking on this.


#3

Update: It seems that WPA2 Enterprise is critical to this.

The iPad in question is now connected to a WPA2-PSK SSID and there is no packet leak. The RADIUS server used by the WPA2-Enterprise network is a NAS on the untagged LAN that shuts down at night, so the iPad must have fallen back to the WPA2-PSK network which it has used before. Each SSID used by the iPad is assigned to the same VLAN.


#4

@Michael234

Do you mean when the IPAD connect to WPA2-PSK SSID have no issue ? and you only see the firewall logs when IPAD connect to WPA2-Enterprise network ?

The firewall logs as given above is more on Multicast traffics … just worry the IPAD connect to the wrong VLAN with IP address 10.44.44.105 and generated such logs.


#5

It turns there are two issues.The log entries below are from a Windows 10 machine. What Apple uses port 5353 for is not relevant. Whether the UDP packets were allowed or dropped is not the point. The point, to me, is why the Windows 10 machine sees these packets at all since the VLAN does not allow inter-VLAN routing. I realize this could be a documentation issue. Many issues are.


The traffic below happens on either SSID, WPA2-PSK or WPA2-Enterprise. The router (10.44.44.4 on each Wi-Fi SSID as they are both on the same VLAN) is doing some type of broadcast from port 67 to port 68 that is being heard by the Ethernet connected Windows 10 machine on the untagged LAN which is the 192.168.1.x subnet.

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2018-11-04 12:18:18 ALLOW UDP 10.44.44.4 255.255.255.255 67 68 0 - - - - - - - RECEIVE
2018-11-07 21:23:23 ALLOW UDP 10.44.44.4 255.255.255.255 67 68 0 - - - - - - - RECEIVE


The traffic below is coming from the iPad (10.44.44.105), not the router. it is only seen on the Windows 10 machine when the iPad is on the WPA2-Enterprise SSID

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path.

2018-11-04 10:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 11:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 12:44:51 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 13:44:50 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE
2018-11-04 14:44:50 DROP UDP 10.44.44.105 224.0.0.251 5353 5353 77 - - - - - - - RECEIVE


#6

@Michael234

Reproducing the reported issue.

It should be related to Multicast traffics & some Broadcast traffics. I will keep you update for this.