Core Responding with Wrong MAC for Edge Switch IPs Across Site-to-Site VPN

[manny1811]

Background: I inherited a network with VOSS fabric at two sites (Site A and Site B) connected via SonicWall site-to-site IPsec VPN. It appears the original engineer's intent was to implement Fabric Extend between sites, but this was never completed. For now, I need basic management visibility to edge switches at the remote site through the existing VPN tunnel. I can work on properly implementing Fabric Extend later.

The Problem:

• From Site A, I can ping/manage the Site B core switches (10.254.1.1-2) successfully 
• From Site A, I CANNOT reach Site B edge switches (10.254.1.3+) 
• Packet capture on Site B firewall shows responses from edge switches, BUT the source MAC address matches the CORE's MAC, not the edge switch's MAC
• This prevents static ARP entries on the firewall

Environment:

• Hardware: Extreme 5520/5420 switches running VOSS 8.10.3.0
• Site B: Two core switches in SMLT/vIST cluster, multiple edge switches in ISIS fabric
• Site A: Similar setup at remote site
• Connectivity: SonicWall site-to-site IPsec VPN between sites
• Management IPs: All switches use CLIP addresses (10.254.1.x range)

What Works:

• ISIS fabric is healthy at both sites
• Site B cores can ping Site B edge switches directly (10.254.1.3 responds)
• Static routes added on Site B cores for Site A networks (10.10.0.0/24 → firewall)
• Firewall has routes to switch management subnet

What I've Found:

• show interfaces vlan on Site B cores shows:
  • VLAN 100 (firewall-facing): DOPROXY = false, DORESP = true
• No proxy-arp, arp-respond, redirect, or directed-broadcast commands in running config
• Cores have no ARP entries for edge switch IPs (they're ISIS/CLIP addresses, not in VLANs)

The Question: When traffic from the firewall (VLAN 100) is destined for edge switch CLIP IPs, why is the core responding with the edge switch's IP address but the CORE's MAC address? Is this related to the DORESP setting on VLAN 100?

Has anyone encountered this scenario where fabric management IPs need to be reachable across a site-to-site VPN (without Fabric Extend)? What's the proper configuration to allow the firewall to reach edge switches without the cores proxying the response?

Any guidance would be greatly appreciated!

[Phil_]

Hi Manny,
I have some questions;
Site A and B share the same MGMT Clip IP Subnet or are they different?
Whats the next-hop from Site A to B and from B to A?

Regarding your question, I would guess that you see the core switch mac as src is because the core switch is the next-hop in the route for the response form the edge switch. Does the core and firewall both share an IP Interface in VLAN 100? If so, that would explain why you see the mac of the core for the response.

Best regards,
Philipp

[james637e]

---

@manny1811 wrote:

Background: I inherited a network with VOSS fabric at two sites (Site A and Site B) connected via SonicWall site-to-site IPsec VPN. It appears the original engineer's intent was to implement Fabric Extend between sites, but this was never completed. For now, I need basic management visibility to edge switches at the remote site through the existing VPN tunnel. I can work on properly implementing Fabric Extend later.

The Problem:

• From Site A, I can ping/manage the Site B core switches (10.254.1.1-2) successfully 
• From Site A, I CANNOT reach Site B edge switches (10.254.1.3+) 
• Packet capture on Site B firewall shows responses from edge switches, BUT the source MAC address matches the CORE's MAC, not the edge switch's MAC
• This prevents static ARP entries on the firewall

Environment:

• Hardware: Extreme 5520/5420 switches running VOSS 8.10.3.0
• Site B: Two core switches in SMLT/vIST cluster, multiple edge switches in ISIS fabric
• Site A: Similar setup at remote site
• Connectivity: SonicWall site-to-site IPsec VPN between sites
• Management IPs: All switches use CLIP addresses (10.254.1.x range)

What Works:

• ISIS fabric is healthy at both sites
• Site B cores can ping Site B edge switches directly (10.254.1.3 responds)
• Static routes added on Site B cores for Site A networks (10.10.0.0/24 → firewall)
• Firewall has routes to switch management subnet

What I've Found:

• show interfaces vlan on Site B cores shows:
  • VLAN 100 (firewall-facing): DOPROXY = false, DORESP = true
• No proxy-arp, arp-respond, redirect, or directed-broadcast commands in running config
• Cores have no ARP entries for edge switch IPs (they're ISIS/CLIP addresses, not in VLANs)

The Question: When traffic from the firewall (VLAN 100) is destined for edge switch CLIP IPs, why is the core responding with the edge switch's IP address but the CORE's MAC address? Is this related to the DORESP setting on VLAN 100?

Has anyone encountered this scenario where fabric management IPs need to be reachable across a site-to-site VPN (without Fabric Extend)? What's the proper configuration to allow the firewall to reach edge switches without the cores proxying the response?

Any guidance would be greatly appreciated!

---

EZ Pass NJ is New Jersey’s electronic toll collection system, letting you breeze through tolls on roads like the NJ Turnpike and Garden State Parkway. It saves time and money with discounts.

[williamgarcia44]

Superb work! This writing sets a new standard for explaining this topic.