So how to block SSDP (there are also other, security related reasons to block SSDP/UPnP on your network as it has its share of vulnerabilities and poor implementations) for getting to the hub router and thus providing in spoke-spoke traffic in what Windows thinks is LAN traffic, while it is actually WAN traffic. So, although SSDP should remain local and you’d expect that the TTL would be set to 1 (quite similar to Bonjour in Apple networks), this was not happening for some traffic.
I saw, during the second troubleshooting, that the SSDP address was registered at the Rendezvous-Point (which is configured on the hub router) with specific endpoints “listening in” on the address. it should be dropped at the Internet edge router/firewall.įor small (home) networks that makes perfectly sense, but in a larger enterprise network where multicast is configured for other network endpoints you might want to restrict this specific multicast address… Which sounds quite logical, as SSDP uses 239.255.255.250 which is a local scoped multicast address, e.g. Instead Windows 10 appears to use SSDP multicast for that. It of course could use a port scan, but that is rather suspicious behavior. So how does Windows 10 “knows” which computers are on the local network. Not all computers at the customer’s site were part of the domain and it is very safe to assume that this default setting is not changed by many users. not completely.Ī couple of weeks later we still saw spoke-to-spoke traffic and started troubleshooting further.
So, the customer changed the group policy and disabled “Delivery Optimization”. But in a managed environment with controlled updates (with WSUS), you do not want to have that enabled. This is of course a great idea if all the PC’s are in the same LAN, so that the Internet line is less impacted in large downloads. It basically checks if an update is already downloaded by another PC in the LAN and then downloads that in a peer-to-peer manner. Research on the Internet learned that this is part of a new feature within Windows 10, called “Delivery Optimization”. So with a packet capture on one of the spoke routers we saw TCP traffic between the spokes on tcp port 7860. The network was behaving perfectly fine and spokes were happily communicating with the servers behind the hub until windows 10 came along… The customer started to see spoke-spoke traffic while that should not have happened in the first place. I recently ran across the following issue on a DMVPN Hub-Spoke network with some sites.
0 kommentar(er)
