How I Built a Production-Grade Enterprise Network in EVE-NG

— And Everything That Broke Along the Way…

Most network labs stop at “it works.” I wanted to understand why.

I recently completed a dual-site enterprise network project simulating a real client deployment for a fictional fintech company called Nexora Technologies Ltd. Two offices — Lagos HQ and Ikeja Branch — connected over an encrypted WAN tunnel, with full redundancy, centralised monitoring, and a consistent security baseline across 15 Cisco devices.

This article isn’t a tutorial. It’s the story of what broke, why it broke, and what I learned from each failure.

The Network

Before getting into the problems, here’s what was built:

• Two sites connected via IPsec over GRE (AES-256 encryption)
• OSPF for internal routing at both sites
• EIGRP running over the tunnel between edge routers
• Route redistribution between OSPF and EIGRP at both edge routers
• HSRP for redundant default gateways on all six VLANs
• STP with manually configured root bridges aligned to HSRP
• EtherChannel bundles between core switches
• IP SLA with object tracking for automated WAN failover
• Centralised syslog and NTP across all 15 devices
• Full device hardening on every switch and router

Full configs and documentation are on GitHub.

Problem 1 — NAT Was Killing My IPsec Tunnel

ISAKMP SA showing QM_IDLE — Phase 1 successfully established after fixing NAT conflict

After configuring IPsec on both edge routers, Phase 1 kept dying at MM_KEY_EXCH and never reached QM_IDLE.

The show crypto isakmp sa output showed the negotiation starting but never completing. I checked the pre-shared keys — they matched. I checked the transform sets — they matched. I checked the peer addresses — correct.

The problem turned out to be NAT.

My NAT ACL used permit any, which meant every packet leaving the router got translated before IPsec could process it — including IKE negotiation packets on UDP port 500. When NAT changed the source port, the receiving router rejected the packets because they didn’t match the expected peer.

The fix was adding an explicit deny for traffic between the two tunnel endpoint IPs at the top of the NAT ACL, before the permit any statement. This told NAT to leave IPsec traffic alone.

The lesson: when IPsec and NAT coexist on the same router, you must explicitly exclude tunnel endpoint traffic from NAT. The symptom is always MM_KEY_EXCH that never advances. The cause is almost always NAT.

Problem 2 — Stacked NAT Rules

Clean NAT config — only one rule active after removing the stacked duplicate

After fixing the first issue, I made it worse.

I created a new NAT ACL but forgot to remove the old one. IOS doesn’t replace NAT rules — it stacks them. Both were active simultaneously. The new ACL correctly denied IPsec traffic, but the old ACL caught it immediately after with permit any.

To remove the old rule I had to first clear all active NAT translations using clear ip nat translation * — IOS won’t let you remove a NAT rule that has active sessions. Only then could I remove the stacked rule.

The lesson: always verify with show run | include nat after any NAT change. And always explicitly remove old rules before adding new ones.

Problem 3 — HSRP and STP Were Fighting Each Other

HSRP active and STP root confirmed on the same switch

This one is subtle but it matters enormously in production.

Without deliberate configuration, HSRP elects its active gateway based on the highest IP address. STP elects its root bridge based on the lowest MAC address. These two elections happen completely independently — they have no awareness of each other.

The result is that your HSRP active gateway and your STP root bridge are frequently different switches. When this happens, traffic from access switches follows the STP-preferred path to the root bridge, then travels an extra hop to reach the actual HSRP gateway. Every single frame takes a suboptimal path.

The fix is intentional design. Manually set STP priorities so the HSRP active switch for each VLAN is also the STP root for that VLAN. Verify with show standby brief and show spanning-tree vlan side by side.

The lesson: HSRP and STP must be consciously aligned. The default configuration will almost never align them correctly.

Problem 4 — The IKY Site Had No Internet

Default route propagating correctly after adding default-information originate

After the full configuration was complete, the HQ site could ping 8.8.8.8 but the Ikeja branch could not. The IKY core switches had no default route in their routing tables at all.

The cause was a missing single line on NXR-IKY-EDGE-R1:

default-information originate

This command tells OSPF to advertise the default route to all OSPF neighbours. Without it, the IKY core switches had no gateway of last resort and dropped all internet-bound traffic silently.

HQ worked because NXR-HQ-EDGE-R1 had this command from the original build. IKY didn’t because the router was accidentally wiped during the project and the recovery config missed this one line.

The lesson: always have a recovery checklist. A single missing line can silently break an entire site’s internet access.

What I Would Do Differently

If this were a real production deployment:

• Replace the pre-shared key IPsec authentication with PKI certificates.
• Implement AAA with TACACS+ for centralised device access control.
• Deploy a proper syslog server with indexing and alerting instead of BusyBox.
• Set up automated config backups — the accidental device reset during this project demonstrated exactly why this matters.

What This Project Taught Me

Networking textbooks teach protocols in isolation. Labs teach you to configure them. But real networks are where protocols interact in ways nobody warned you about.

NAT and IPsec conflict. HSRP and STP misalign. A missing line silently breaks an entire site. These are the things you only learn by building something end to end and watching it break.

That’s why I build labs like this. Not because EVE-NG is production, but because the thinking is.

Full project documentation, all 15 device configs, and the network diagram are available on GitHub: github.com/Moyinoluwa-a/dual-site-enterprise-network

I hold CCNA and AWS Cloud Practitioner certifications and I am actively building toward a career as a field deployment network engineer.