Tunnels Built Between Firewalls That Disagree
FortiGate at one site, Palo Alto or MikroTik at the other, and two vendors describing the same standard with different words for every setting in it. We build the tunnel, match both ends properly, and then prove traffic is actually passing instead of trusting a status light that has gone green.
The expensive failures are rarely a tunnel that refuses to come up, because that one gets noticed in an hour. The costly version is the tunnel that stays up, keeps reporting healthy, and quietly stops carrying part of the traffic after a rule change, which is the kind of outage that runs for days before anyone connects it back to the change that caused it.
The Ones That Do Not Announce Themselves
A tunnel that will not establish is a bad afternoon. A tunnel that establishes, reports healthy on both dashboards and carries most of the traffic is the one that costs real money, because the thing that is broken and the thing being monitored are not the same thing.
A FortiGate at head office, a branch on the other end, and a change made on a Tuesday afternoon that had nothing to do with the VPN. A new policy went in above the tunnel rule to handle guest wireless, written broadly enough that it also matched traffic from the branch subnet on its way to one internal application.
Phase one stayed up. Phase two stayed up. The monitoring checked the peer and the peer answered, so every dashboard involved stayed green for the whole period. Users at the branch could reach the file server, they could reach the internal site, and the one system that stopped working was the one people used at the end of the month rather than every day.
It ran that way for nine days, and the ticket that eventually got raised described an application problem rather than a network one, which sent the first two days of investigation to the wrong team entirely. The fix took four minutes once somebody put the change log next to the policy list. Finding it took the rest.
A Rule Above The Tunnel Policy Swallows The Traffic
Policies are evaluated in order, so anything broad enough sitting higher up wins before the VPN rule is ever reached. The tunnel keeps negotiating happily because negotiation and user traffic are separate paths, and nothing in the interface points at the rule that changed.
One Subnet Pair Fails While The Rest Work
Where a tunnel carries several selectors, one mismatched pair fails on its own and the tunnel still shows as up because the others negotiated. The result is a branch where two networks work and the third does not, which almost always gets reported as a server fault.
The NAT Bypass Rule Goes Missing
Traffic that should enter the tunnel gets translated and sent to the internet instead, usually after somebody reorders the rules for an unrelated reason. Common on MikroTik, entirely possible everywhere else, and it looks identical to a routing problem from the desk of whoever reports it.
Return Traffic Takes A Different Path
After a failover or a second link is added, packets leave through one route and come back through another. Stateful inspection on the far side sees a reply belonging to no session it knows about and drops it silently, so one direction works and the conversation never completes.
Small Packets Pass, Large Ones Vanish
Ping succeeds, logins succeed, and anything that moves a real payload hangs. Encapsulation eats into the packet size and without clamping applied on both ends the oversized packets are dropped somewhere neither firewall reports. This one wastes more engineer hours than any other item on this list.
It Drops At The Same Time Every Day
Lifetimes set differently on the two ends means one side wants to rekey while the other is not ready, so the tunnel bounces on a schedule. Short enough that it recovers before anyone logs in to look, regular enough that people learn to work around it and stop reporting it.
Why Green Dashboards Keep Missing This
Almost every monitor watches whether the tunnel is established, and that is not the question you need answered. The useful check is whether a specific host on one side can still reach a specific service on the other, tested from inside the subnets that matter, on a schedule. That distinction is the difference between finding a problem in twenty minutes and finding it in nine days.
So when we hand a tunnel back, the deliverable includes the tests we ran across every subnet pair, in both directions, with a packet size large enough to prove clamping is working. If the tunnel breaks later, you have a record of what passing looked like, which turns the next investigation into a comparison instead of a search.
The Same Setting, Three Different Names
Most mixed vendor tunnels fail on vocabulary rather than capability. The standard is the same on both ends. What changes is what each interface calls the field, where it hides it, and what it quietly assumes when you leave it alone.
The Subnets The Tunnel Agrees To Carry
Both ends have to describe the same pairs of networks in the same order. Get one pair wrong and that pair alone stops working while the tunnel keeps reporting healthy, which is the first item on the failure list above.
The Negotiation Settings
Encryption, hashing, key group and lifetime, split across two stages. The values must match, and each vendor groups them into differently named containers, which is why comparing two screens side by side rarely settles an argument.
How Traffic Gets Steered Into It
Two different models. Route based puts a virtual interface on the firewall and sends traffic to it with a route, policy based decides per packet from the matching rule. Connecting one model to the other works, though it is the point where assumptions from one platform stop applying to the other.
Keeping Address Translation Out Of The Way
Traffic bound for the far site must not be translated on the way out, or it leaves through the internet connection looking perfectly normal and never reaches the tunnel at all.
Lifetimes, Perfect Forward Secrecy And Defaults
The values are often written in different units on each screen, and the defaults were never designed to agree with each other. This is where the tunnel that drops at the same time every day comes from, and it is invisible until you convert both sides into the same units and put them next to each other.
Where The Security Rules Actually Live
A tunnel being established does not mean traffic is permitted through it. Each platform enforces that in a different place, and traffic can be allowed at one layer and dropped at the next without any log line that says so plainly.
The Sheet That Prevents Most Of This
Before either device gets touched, both ends go on one page in the same units. Selectors, proposals, lifetimes, forward secrecy, the routing model and where the rules sit. Half an hour of writing it out finds the disagreements that would otherwise be found at two in the morning with a branch manager on the phone.
That sheet is part of what we hand back, kept as the record of how the tunnel is configured on both sides. When somebody upgrades a firewall next year and the settings quietly move, the comparison takes minutes instead of a fresh investigation from nothing.
How The Work Runs
Read first, change second, prove third. Most of the value is in the first and third parts, which is the opposite of how these jobs are usually quoted and the reason they get quoted again six months later.
We Read Both Ends Before Touching Either
Configuration from both firewalls, the subnets involved, and the change log for the period the trouble started. Read access is enough for this stage. On a broken tunnel the cause is usually already visible in that material, and knowing which change to look at removes most of the guessing that makes these jobs expensive.
Both Sides Go On One Sheet
Selectors, proposals, lifetimes, forward secrecy, the routing model and the rule placement, converted into the same units and set side by side. Disagreements become obvious at this point rather than during the window, and you get to see them before anyone approves a change.
The Change Happens In A Window You Choose
Configuration aligned on both ends, packet size handled properly, rules placed where they will not be shadowed by the next addition, and a rollback ready before anything is applied. Most of these changes are small once the reading is done, and small changes at an agreed hour are how this stays boring.
Traffic Gets Proven, Not Assumed
Every subnet pair, in both directions, with a payload large enough to show that clamping is working, tested from hosts inside the networks that matter rather than from the firewall itself. A tunnel that shows established has told you almost nothing, and this is the step that separates finished from probably fine.
What You Get At The End
- The settings sheet covering both ends, in one place and one set of units.
- The test record showing what passing looked like, per subnet pair and direction.
- Written steps for the changes you will actually make, such as adding a subnet or replacing a peer address.
- A note of anything we found that was working by accident and will break later.
What Sits Outside This
- Hardware replacement. If the firewall genuinely cannot do the job we say so, once, with the reason.
- Carrier faults. Where the provider is blocking the protocols the tunnel needs, that is a conversation with them and we will give you the evidence for it.
- Vendor support cases. We can prepare one properly, though it stays under your contract.
- Ongoing management, unless you want it as a separate arrangement rather than an assumption.
Tell Us What Is At Each End, And What Stopped Working
Two vendor names and a description of the symptom is enough to start a conversation. If something is broken right now, send the configuration from both sides and the change log for the week it began, and you will get our reading of it before there is any quote to consider.
Talk about your tunnel