Public IP Block Routing Over L3 Tunnel – Traffic Leaves Site A but Does Not Exit ISP Interface

th3e898 · February 21, 2026, 3:27am

Hello,

I am facing an issue with a clean L3 routed design (no L2 bridging), and I would appreciate a technical second opinion.

Architecture

Site A (primary DC)
Site B (edge router connected to an ISP over an L2 segment similar to a vRack)
WireGuard tunnel between Site A and Site B (underlay /30)
A public /28 block provided by the ISP
The gateway of that block is .190 inside the /28
Goal: allow Site A to use IPs from the /28 and egress to the Internet via Site B

There is no L2 bridge (no EoIP, no VXLAN). This is pure L3 routing.

Routing Design

Site A

main table → underlay
ipfo table → public egress
Routing rule: src-address=/28 → lookup ipfo
Default route in ipfo → WireGuard tunnel toward Site B

Site B

main table → underlay
ipfo table:
- 0.0.0.0/0 → .190 (ISP gateway)
- /28 → tunnel back to Site A

No NAT is used.

Observed Behavior

From Site A:

Ping to .190/28 (ISP gateway) works
ICMP to 1.1.1.1 leaves Site A and is visible entering Site B via the WireGuard tunnel

On Site B:

I see ICMP arriving from Site A (source = IP from the /28)
BUT traffic does not leave via the ISP interface (ether2)
No ICMP visible on the ISP-facing interface

What Has Been Verified

An IP from the /28 is configured on the ISP-facing interface
ARP toward the ISP gateway is working
rp-filter tested in loose mode
Routing policy rules are present to force /28 traffic into ipfo
WireGuard tunnel is stable
No firewall drops observed
No NAT involved

Questions

In a pure L3 multi-table design:

Does the ISP gateway need to be considered “connected” inside the same routing table as the default route?
Is it required to add an explicit “on-link” route for the /28 inside the dedicated routing table?
Is there any known next-hop validation behavior in RouterOS v7 that could cause a default route to remain inactive in a non-main table?
Could reverse path filtering or FIB resolution rules prevent forwarding from a secondary routing table?

The traffic clearly reaches Site B, but it does not exit toward the ISP.

Any technical insight would be greatly appreciated.

th3e898 · February 21, 2026, 3:41am

We previously used EoIP because we wanted to extend Layer 2 from Site B to Site A. The ISP provides multiple /28 public blocks on ether2 at Site B, and we were bridging that L2 all the way to Site A so our servers there could directly use those public IP blocks.

However, we now want to improve and modernize our infrastructure. So we decided to move to a routed design using WireGuard and BGP instead of L2 extension. The WireGuard link is stable, and the BGP sessions are established and working correctly.

Our long-term goal is to deploy multiple VXLAN segments and inject a specific /28 block into each VXLAN.

Each VXLAN must be fully isolated and must not use a /28 block that was not explicitly assigned to it.

Each public block provided by the ISP includes a gateway inside the subnet. For example, for the block .176/28, the gateway is .190/28. The Layer 2 network provided by the ISP on ether2 at Site B is configured in proxy ARP mode.

The strange part is the behavior: Sometimes the gateway IP of the block responds from Site A. Sometimes the public IP is reachable, but the gateway stops responding. Sometimes everything works, and then it suddenly doesn’t. The behavior is inconsistent and unpredictable.

At this point, I’ve spent many nights troubleshooting this and I’m honestly exhausted and out of ideas.

Thanks you

CGGXANNX · February 21, 2026, 4:59am

You should post the exported configuration of the two routers on both sites (with sensitive information redacted) for people on this forum to be able to assist you. At least you should provide the export output of /ip address, /interface wireguard, /ip route, /routing rule, as well as the output of /ip route print. You might want to censor the public IP addresses and the keys.