All_about_network

Ok so in my previous posts I described the most common config of IPsec with IKE. For troubleshooting this config there are few simple things one should check for basic troubleshoot.

No. 1 Check display IKE sa command in user view

Output of this command should show you two IKE entries. It is necessary to be two because if there is only one there is probably some misconfiguration. And it means either phases of negotiation failed or that the remote end is not responding (more about what exactly the phase number means what read this short explanation).
If the IKE phase is successful you should see the following output:

<quidway> dis ike sa
total phase-1 SAs: 1
connection-id   peer     flag   phase  doi
———————————————————————————————————————————————-
2729    192.168.1.1    RD|ST    1     IPSEC
2730    192.168.1.1    RD|ST    2     IPSEC
flag meaning
RD–READY ST–STAYALIVE RL–REPLACED FD–FADING TO–TIMEOUT

If your output is nothing like that your IKE is not working so no need to troubleshoot IPSec further.
Most commonly you’ll see either :

total phase-1 SAs: 0
connection-id peer flag phase doi
———————————————————-

meaning there is no IKE even trying to connect. Or something like this

connection-id   peer     flag   phase  doi
———————————————————————————————————————————————-
2730    192.168.1.2    RD|ST    1     IPSEC
2731    192.168.1.2    RD
flag meaning
RD–READY ST–STAYALIVE RL–REPLACED FD–FADING TO–TIMEOUT

which means some kind of misconfiguration as mentioned above.
There is one important thing – you need to issue “reset ike sa and reset ipsec sa in order to thy the changes. Because if you change your config and try without resetting the old SAs there could some errors occur. And those are very hard to find (it is usually the other endpoint with some restrictions of number of sa created or timeouts etc.)

No. 2 Check display IPSec sa in user view

If your IKE SAs are ok then there is the next step to much more complex debugging of IPSec itself. The basics are still the same as by the IKE. You really need to check the creation of IPSec SAs.
The command is as you can guess display ipsec sa in user view. And the output should look like this:

<quidway> dis ipsec sa
===============================
Interface: Ethernet0/0
path MTU: 1500
===============================

—————————–
IPsec policy name: “1″
sequence number: 20
mode: isakmp
—————————–
Created by: “Host”
connection id: 29
encapsulation mode: tunnel
perfect forward secrecy: None
tunnel:
local address: 192.168.1.1
remote address: 192.168.1.2
flow: (22 times matched)
sour addr: 111.111.111.1/255.255.255.255 port: 0 protocol: IP
dest addr: 222.222.222.2/255.255.255.255 port: 0 protocol: IP

[inbound ESP SAs]
spi: 3605833965 (0xd6eca8ed)
proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-MD5
sa remaining key duration (bytes/sec): 1887435876/3460
max received sequence-number: 11
udp encapsulation used for nat traversal: N

[outbound ESP SAs]
spi: 86278637 (0x52481ed)
proposal: ESP-ENCRYPT-AES-256 ESP-AUTH-MD5
sa remaining key duration (bytes/sec): 1887435876/3460
max sent sequence-number: 12
udp encapsulation used for nat traversal: N

There are two important things to remember. First : there must be and outbound and inbound ESP SAs (if using ESP of course). If working properly you should see this output twice (but it depends on multiple factors).

No. 3 Check the console displayed error messages

I know this seems to be an obvious thing but while solving problems with IPSec you can have so many messages you will start to ignore them. Other thing is that the remote connection is not displaying error messages. They are sent to console by default. So the first step is enabling the debug of the relevant messages which consist of these few commands:
terminal monitor
terminal debugging
debugging ike all
debugging ipsec all
The most common error message is this :

%Jan 1 01:09:35:173 2007 ADSL IKE/3/DROP:
IKE packet dropped: (src addr: 10.0.3.1, dst addr: 10.0.3.2) with I_Cookie 7af8c8d6921e6879 and R_Co
okie beb2c9927a43409a, because of ‘ No IPSec policy found ‘ from payload PROPOSAL.

which means that the process is ok ( you will see the IKE and IPSec SAs ) but there is no IPSec policy found for this exact peer. If you see this just check if there is a policy for your config and if it is bonded to the proper interface and if the other binding (ike ipsec proposals and peers)is also made properly.

If you checked all of these there should not be a problem in your IPSec configuration. If even this is not helping you you should consider trying the debug ip packet command but if there is real traffic routed through your device I would not recommend it as this command will display all passing packets and related messages which can easily overload your box and cause a reboot. There are of course various counters and some more debugging tools but they are not so useful as those above mentioned.

This is probably last post about IPSec on Huawei. The only remaining topic is th l2tp over IPSec which will be covered sometime next. If anyone is interested in this Ia can provide some more information. Just comment under the article.