Unexpected GRE Decapsulation on Affected Arista Switches: How VXLAN Programming Created a DDoS Relay Risk

Unexpected GRE Decapsulation on Affected Arista Switches: How VXLAN Programming Created a DDoS Relay Risk

By Comcast Threat Research Labs (CTRL)

At Comcast, we spend a great deal of time looking for threats directed at our customers and our network. Frequently, that work uncovers things we didn't expect but are just as important - infrastructure that can be repurposed for further attacks against someone else besides Comcast. That broader "defend the ecosystem, not just yourself" framing is a key component of Comcast's proactive cyber defense work.

In coordinated work with Arista, we identified a vulnerability affecting Jericho/Jericho+ platforms in which the presence of VXLAN configuration could cause hardware to program a decapsulation entry keyed to a loopback address. We saw this on affected systems, which created an unexpected path where unsolicited GRE or other IP-in-IP traffic sent to that loopback IP could be decapsulated, and the inner packet forwarded, even when no corresponding operational tunnel existed. This behavior aligns with the broader class of tunneling-protocol risks documented by CERT/CC and NVD, where exposed interfaces can be abused to route arbitrary traffic because tunneled packets are not sufficiently validated.

That mattered immediately for two reasons. First, we confirmed exploitation in the wild. Second, the affected devices were not being used merely as targets. Under the right conditions, they could become unwilling relay points for spoofing, reflection, and amplification activity.

A routine alert that stopped being routine

This investigation did not begin with an obvious outage or a high-confidence exploitation chain. It started with routine firewall telemetry - repeated alerts consistent with DNS amplification activity.

Ordinarily, that kind of signal is generally background noise on the public internet. What made this case different was one simple contradiction - both the apparent source and the apparent destination IP addresses were external.

Traffic with that shape should not traverse enterprise infrastructure at all.

That inconsistency forced us to revisit an assumption that is easy to make during triage - that the alert is noisy, rather than the packet path itself is wrong.

The packet path that broke the model

Zeek logs, netflow data, and packet captures showed that the traffic was not native DNS traffic moving through the network in the ordinary sense. It was inner traffic encapsulated inside GRE, IP protocol 47.

The outer packets were being sent from the internet to loopback addresses assigned to Arista switches.

That was immediately suspicious. No GRE tunnels were configured. No GRE service had been intentionally exposed. There was no operational reason for those packets to be accepted, much less decapsulated and forwarded.

But they were.

Why VXLAN mattered, even when VXLAN was not operational

The key detail was not GRE configuration. It was VXLAN configuration.

On affected platforms, a VXLAN configuration as simple as the following was enough to create the vulnerable condition:

interface Vxlan1

vxlan source-interface Loopback1

vxlan udp-port 4789

Even when that configuration did not result in a fully operational VXLAN interface, the device still programmed a decapsulation entry in hardware keyed to the Loopback1 IP address.

That distinction matters. From an operator's perspective, it's easy to assume that a feature, which is not fully enabled, is functionally inert. In this case, it was not inert in the data plane.

When an IP-in-IP packet arrived with an outer destination matching the configured loopback IP, the device could decapsulate the packet and forward the inner traffic onward.

What the switch was actually doing

On the affected Jericho/Jericho+ platforms, the hardware decapsulation behavior did not sufficiently discriminate on tunnel type for this path. In practical terms, that meant a decapsulation entry associated with VXLAN-related programming could still be hit by unsolicited GRE traffic directed at the decapsulated IP.

The packet path looked like this:

• A GRE packet arrived from the public internet with an outer destination equal to the switch loopback IP.

• The switch decapsulated that packet in hardware.

• The inner packet, which could contain a spoofed source address, was then forwarded according to the device's normal forwarding logic as though it had arrived natively.

• At that point, the switch was no longer acting merely as passive infrastructure. It had become part of the attack path.

In our case, that was not theoretical. We observed confirmed exploitation in the wild.

Affected platforms

Based on our analysis, the issue affected all Arista 7280R/R2 and 7500R/R2 platforms using Jericho/Jericho+ silicon, including DCS-7280QR-C36 and related models in those families.

Later generations were materially different. On Jericho2 and newer platforms, there is a different architecture, which prevents VXLAN from being vulnerable on these systems.

That architectural distinction is important because it explains why this was platform-specific rather than a universal property of VXLAN-enabled systems.

Mitigation and remediation

The immediate mitigation was straightforward - block unsolicited GRE and related IP-in-IP traffic at the edge, especially when destined for infrastructure loopback addresses that should never be reachable from the public internet.

Once that filtering was put in place, the abusive traffic path stopped.

Arista has published product-specific guidance through its advisory, and defenders should follow the vendor's remediation recommendations for affected systems. In some environments, platform-specific filtering approaches may also be available, but those should be validated carefully against legitimate overlay use before deployment.