Duplex Mismatch on a VPN Gateway Port: Read Both Ends

A file copy through the tunnel stalls for a second, resumes, and the VPN logs show nothing. The application blames the network, the network blames the application, and the switch port has been up for eleven months. This walkthrough starts at the pause and works outward to the physical link: what the port is actually doing, what the far end is doing, and what the counters did while you were watching. It is worth doing before anyone touches a duplex setting.

Start from the pause, not the port

Describe the symptom in a way that can be tested. A stall that lasts about a second during bulk transfer is a different problem from a connection that resets, and a pause that happens once an hour is different from one that happens every few seconds. Write down the workload, the direction and the approximate interval.

Then reproduce it while you watch the interface. A physical problem shows up as movement in the counters during the affected workload, and a problem that produces no counter movement at all is probably above the link layer. Watch for a minute, not a second, because these faults often need sustained traffic before they appear. Idle monitoring proves nothing about a link that only misbehaves under load.

This matters because duplex mismatches have a signature: errors that appear only under load, in the direction of the traffic, while small pings and interactive sessions stay perfect. If idle traffic is also failing, look somewhere else first.

Read the operational mode on both ends

The saved configuration is not the operational state. A port can be configured for autonegotiation and end up at half duplex, or be configured for a fixed speed that the other end never agreed to. Read what the link is currently doing on both sides.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Record speed, duplex and whether autonegotiation is on, then get the same three facts from the adjacent switch or provider port. One end alone tells you nothing, because the mismatch is a relationship rather than a setting. Put both rows in the ticket side by side, with the time you read them. Half the value of the exercise is having the two readings in one place.

If you cannot read the far end, you cannot diagnose this. Ask the owner for the operational mode and the counters, or arrange access before you start changing your side.

What the 10/100 half-duplex case looks like

On 10/100 copper links, an autonegotiating endpoint can detect a forced peer's speed without learning its duplex setting. Parallel detection determines the speed from the signal, and duplex is assumed rather than negotiated, so one side can end up half duplex while the other runs full.

Cisco's autonegotiation guidance explains that specific case. It is not an argument for disabling negotiation everywhere, and it says nothing useful about gigabit copper, where duplex is fixed and autonegotiation is required for the link to come up at all.

The observable evidence is a mix of errors that only exist in one direction: FCS or CRC errors on the full-duplex side, collisions or late collisions on the half-duplex side, and throughput that collapses under load while latency stays normal when idle. That asymmetry is the signature. A link that is simply oversubscribed degrades in both directions and at all times.

Change both ends together, with a way back

A duplex correction is a coordinated change, not a local one. Forcing your side without the far end agreeing is how a working link becomes a broken one, and the CLI accepting the command proves only that the syntax was valid.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Before you run anything like that, confirm the platform supports the combination and that the far end will be changed in the same window. Preserve an independent way to administer the device, because the port you are about to change may be the one carrying your management session.

On many modern links the correct answer is to leave autonegotiation enabled at both ends rather than to force anything. Forcing is a remedy for a specific mismatch on a specific technology, not a general improvement. Gigabit copper in particular needs autonegotiation to bring the link up at all, so the 10/100 advice does not transfer.

Confirm the counters moved for the better

After the change, re-read the operational state on both ends and confirm they agree. Then run the same workload that produced the pause and compare counter deltas rather than lifetime totals, because a total that has been accumulating for a year cannot tell you what happened in the last ten minutes.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

A link with no new errors under the same load is the evidence you were missing. A link that still errors, or one where the counters never moved in the first place, sends you to the next boundary instead of deeper into the duplex argument. Either outcome is progress, which is more than the configuration file can give you. Do not skip the second reading because the first one looked right.

Write the before and after numbers into the ticket with timestamps. That record is what turns "the VPN feels better" into something the next engineer can build on.