Identity failures

After the address changed

Lesson 17 of 20 · 11 min · Module 5: Troubleshooting

Nothing was changed on either gateway, and the tunnel has been down since Tuesday. Something outside the configuration moved.

Start this lesson →

Free. No installation: you write and run the code in your browser, and it is checked automatically.

By the end, you’ll be able to…

Distinguish a key problem from an identity problem
Explain why a changed address breaks a default identity
Restore a tunnel by sending the identity the peer expects

The idea

A tunnel depends on facts that live outside it: the public address of each gateway and the identity each one presents. When the head office changes its internet provider, the gateway gets a new address, and by default a new identity along with it. The peer rejects a gateway it has never heard of with AUTHENTICATION_FAILED, even though the key is right.

# default identity = the gateway's current address
# after a provider change the address is new, and so is the identity

01Two causes, one error code

AUTHENTICATION_FAILED covers a wrong key and an unexpected identity. The log of the gateway that rejected the attempt says which; from the other end you see only the code. In this lab the message tells you what the peer expected.

02A bridge until both sides can change

The lasting solution is a name as identity on both gateways. Until the branch administrator can change that side, this gateway can present the identity the branch still expects, the old address. An identity is a label: it does not have to be an address the gateway currently holds.

03Identity and address on real devices

Check which identity is sent and which is expected before touching the key.

# FortiGate: send a fixed identity
config vpn ipsec phase1-interface
    edit "to-branch"
        set localid "203.0.113.10"
    next
end

# Cisco IOS
crypto ikev2 profile BRANCH
 identity local address 203.0.113.10

# The branch must also point at the new address:
#   FortiGate    set remote-gw 203.0.113.77
#   Huawei USG   remote-address 203.0.113.77

Your turn

The head office changed its internet provider. The gateway now has the address 203.0.113.77, and the branch has already updated the address it connects to. The tunnel fails in IKE_AUTH, because the branch still expects the identity 203.0.113.10. Make this gateway present that identity. Do not change the key.

What the checks look for

This gateway presents the identity the branch expects
Authentication succeeds
The key was not changed
The tunnel is up and stable

Try it in the editor →

Take this with you

Authentication is key plus identity. When a tunnel breaks without a configuration change, look for something outside it that changed, starting with the addresses.

Go a little further

Think about the permanent solution: which two lines would each administrator add so that the next provider change needs no identity change at all?