Ike peer reported error застава - Исправление ошибок и поиск оптимальных решений проблем

IPsec VPN через Strongswan: ошибка авторизации

Пробую поднять IPsec IKEv2 VPN, на обоих концах Strongswan, авторизация через сертификаты X.509. При подключении приходит отлуп с AUTH_FAILED на IKE_AUTH request 1. Со стороны сервера CA сертификат подгружается нормально, в логах нет явных сообщений про неизвестные сертификаты.

Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.

Ниже 1.2.3.4 – внешний IP сервера, 5.6.7.8 – внешний IP клиента, 192.168.0.2 – внутренний IP клиента, 192.168.0.100 – внутренний IP сервера.

edit: добавил лог с сервера

Хм, а так можно было оказывается.

Покажите лог с сервера.

Хм, а так можно было оказывается.

Забыл сразу добавить, отредактировал пост.

Та я как-то привык к ipsec.conf

От оно:
server charon[994]: 15[CFG] no matching peer config found

Не совсем понял, это для клиента указать? А куда тогда адрес сервера вбивать?

Если для клиента, то это вроде дефолт для swanctl-стиля (я так понимаю, что left и right соответствуют connections. .local_addrs и connections. .remote_addrs ). Я практически без изменений брал конфиг с официальной вики (Roadwarrior scenario → swanctl.conf).

Я предполагал, что это в порядке вещей, т.к. айпи клиента неизвестен, так что конфиг пира генерируется. Видимо, это не так. Как тогда быть? Получается, надо каким-то образом на сервере указать, чтобы принимался ID типа CN=client ?

Почти. Ему надо на основании «чего-то» решить, что вот этот кусок конфига относиться к этому клиенту. Но наискосок в мане чего-то аналогичного leftid | rightid в ipsec.conf и keyexchange не обнаружил. 🙁

Это для сервера.

В swanctl.conf можно указать connections. .remote.id , похоже, он работает как rightid для ipsec.conf . Пробовал указывать конкретный id клиента, но увы, всё та же ошибка.

Видимо, попробую переписать серверный конфиг в ipsec.conf-стиле: я как раз думал, что все уже много лет назад пересели на swanctl, а вот оно что.

попробую переписать серверный конфиг в ipsec.conf-стиле

На всякий случай кусок из моего ipsec.conf

я как раз думал, что все уже много лет назад пересели на swanctl

Точно не все 🙂 Я последний раз правил ipsec.conf всего два дня назад 🙂 И пока его не выпилят окончательно, менять конфиги желания ровно ноль. У меня там достаточно секций под разные соединения, пусть не всё уже нужно, но мало ли.

Спасибо! Правда, мне по идее смысла матчить так нет: CA тестовый, поэтому я заполнил только CN и SAN. А для продакшена, конечно, полезно по OU фильтровать.

Кроме того, я переписал почти один в один серверный конфиг:

И, о чудо, авторизация заработала. Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

А для продакшена, конечно, полезно по OU фильтровать.

Для себя любимого тоже полезно. Я в OU фильтрую по разным реализациям клиентов. Например для blackbery одно, для mac os x другое и т.д.

Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

Может и так. А может документацию не дописали. 😉

Я в OU фильтрую по разным реализациям клиентов.

Отличная идея, не думал о таком варианте.

Ага. Сама проблема в том, что это в лебеде вы можете настроить усе что угодно, а готовые реализации клиентов зачастую содержат захардкоженные наборы параметров. macOS одно, офтопик другое и т.д. Вот и приходиться под них подстраиваться.

Как оказалось, я просто невнимательно читал доки, а решение вполне есть. Разгадка в том, что при ipsec.conf-стиле с обоих сторон клиент отправляет ID сервера по дефолту в виде его IP, а сервер принимает всё. В случае с swanctl, сервер ожидает ID в виде DN его сертификата, что в чем-то более логично. swanctl-клиент также отправит ID сервера как DN серверного сертификата, полученного в результате предыдущего запроса.

Таким образом, если хочется оставить swanctl на сервере и ipsec.conf на клиенте (оригинальная задача), то достаточно на клиенте добавить rightid=»CN=1.2.3.4″ ( 1.2.3.4 – IP сервера). Или можно воспользоваться недокументированной особенностью и прописать local.id = %any на сервере. При использовании swanctl с обоих сторон специально прописывать local.id и remote.id не нужно.

Со своей стороны я решил использовать ipsec.conf с обоих сторон, т.к. swanctl выглядит гибче (мне это пока ненужно), но геморнее (например, убунтовый AppArmor по дефолту режет swanctl так, что он не загружает никаких соединений на старте системы, нужно руками делать —load-all ).

anc если вдруг интересно

Источник

Common IKE Error Messages

Some errors are quite common, and are often asked about on the mailing list. Chances are high that if you have a problem, it is listed in this section. Probably the most common and feared error is a variation of this one:

cannot respond to IPsec SA request because no connection is known for .

This error message is usually the first error you will see for a lot of problems that can be encountered. It basically says, «The incoming IKE request does not match any of my loaded connections, I cannot respond to this IKE request.» However, the reason behind the mismatch could be down to the local Openswan machine, but also it could be due to the remote machine. Read the line very carefully, and then read the connection definition in ipsec.conf looking for any difference.

May 18 16:33:54 isi pluto[1917]: «west-l2tp-unpatched-windows-psk»[2] 69.196.174.6 #1: cannot respond to IPsec SA request because no connection is known for 193.110.157.131:17/1701. 69.196.174.6[@testxp]:17/1701

This example is caused by trying to use Windows combined with L2TP, NAT, and PSK. After the ISAKMP SA (Phase 1), Windows suddenly switches to use its host name (in our case «testxp») as identifying ID for the IPsec SA (Phase 2). Openswan has no idea who «testxp» is supposed to be. It cannot find a matching loaded connection and fails with the above error. Another example of this error is this:

July 24 02:00:00 AntonySquared pluto: «roadwarrior»[2] 192.168.1.111 #1: cannot respond to IPsec SA request because no connection is known for 192.168.1.0/24===192.168.1.35[S=C]. 192.168.1.111[0.0.0.0,S=C]

The problem for this connection is that the other end is asking the equivalent of:

Of course, this is not going to work. You cannot tunnel a subnet (as defined by rightsubnet ) through a server (defined by right ) that is part of that subnet. In this case, someone attempted to encrypt the LAN for all connections (hence the leftsubnet=0.0.0.0/0 ). If you run into this type of mistake, check Chapter 10 about WaveSEC, or check Chapter 8 on how to make this work using L2TP.

Apr 21 23:02:41 ussa-hd pluto[7739]: «zywall» #3: cannot respond to IPsec SA request because no connection is known for 192.168.2.0/24===192.168.0.104[S=C]. 192.168.0.187[S=C] ==192.168.10.34/32

In this example, the other end is asking for 192.168.10.34/32 instead of 192.168.10.0/24 . This can be caused by an improper netmask on the rightsubnet= parameter (such as /32 instead of /24 ). In this case, the remote end was a ZyXEL ZyWALL, configured with:

Local: Addr Type= SINGLE

Local: Addr Type= SUBNET

Debugging and Troubleshooting

We were not kidding when we said this type of error is the most common one.

pluto[26541]: «es-to»[2] 192.168.0.146 #2: cannot respond to IPsec SA request because no connection is known for 0.0.0.0/0===192.168.0.254[C=US, ST=CA, L=Los Angeles, O=None, OU=None, CN=gateway, E=yaro@xs4all.nl]. 192.168.0.146[C=US, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Tao White, E=tao@xs4all.nl]

There could be two reasons for this failure. You can see the request includes 0.0.0.0/0 , which means the client might be asking to tunnel all its traffic through the VPN connection, while the server offers only its own subnet through the VPN. Windows and Mac OS X have well-hidden options to switch this off. See Chapter 8. In this example, however, both endpoints are in the same network, and it is actually more likely that this was meant as a VPN tunnel to encrypt the local LAN, probably a wireless network. In that case, the Openswan connection definition is missing a leftsubnet=0.0.0.0/0 . The other reason could be an error in the certificate names. For instance, in this example the Location fields are different, which might not be what it says in the certificates.

022 «conname»: We cannot identify ourselves with either end of this connection.

When you start Openswan, or ipsec auto —up a connection, Openswan will automatically try to determine whether it is left= or right= . If it cannot determine which end it should be, you will see this error in the log. This could be something as simple as a typo in the IP address of this end of the connection. It could also be that you have dynamic IP addresses that have changed. Openswan does not (yet) support using multiple IP addresses that are configured using advanced routing. If you want multiple IP addresses on a single interface, you should use IP aliases. This can be done with the following commands:

# ifconfig eth0:1 1.2.3.4

# ifconfig eth0:2 5.6.7.8

If using KLIPS, you should add these new interfaces to the interfaces= line as well:

interfaces=»ipsec0=eth0 ipsec1=eth0:1 ipsec2=eth0:2″

A related error where there is no proper connection found is indicated by the following log entry:

Mar 19 22:09:00 peace pluto[7946]: «west-raodwarriors»[1] 193.110.157.17 #6: Main mode peer ID is ID_DER_ASN1_DN: ‘C=CA, ST=Ontario, O=Xelerance, OU=Support Staff, CN=east.xelerance.com, E=east@xelerance.com’

Mar 19 22:09:00 peace pluto[7946]: «west-raodwarriors»[1] 193.110.157.17 #6: no suitable connection for peer ‘C=CA, ST=Ontario, O=Xelerance, OU=Support Staff, CN=east.xelerance.com, E=east@xelerance.com’

This could possibly be a conflict in the number of RDNs. This can be verified with openssl :

# openssl x509 -in /etc/ipsec.d/certs/westCert.pem -subject -noout

subject= /C=CA/ST=Ontario/O=Xelerance/OU=Support Staff/ CN=west.xelerance.com/ emailAddress=postmaster@xelerance.com

# openssl x509 -in /etc/ipsec.d/cacerts/caCert.pem -subject -noout

subject= /C=CA/ST=Ontario/L=Toronto/O=Xelerance/OU=Support Staff/CN=Xelerance Root CA/ emailAddress=ca@xelerance.com

Note that one has the RDN of L=Toronto and the other does not. This can happen when openssl.cnf is edited after creating the root CA, but before creating the host certificate.

On the subject of openssl , another common mistake when generating more certificates results in the following output:

Certificate is to be certified until Jan 13 21:31:37 2006 GMT (365 days) Sign the certificate? [y/n]:y

failed to update database TXT_DB error number 2

In this case the administrator is trying to sign a certificate with a CN that already exists and which has already been signed by that CA. You cannot sign multiple certificates with identical Common Names.

May 9 21:31:51 jansen pluto[32188]: «west-l2tp»[2] 194.228.117.3 #1: cannot respond to IPsec SA request because no connection is known for 193.110.157.131:17/1701. 213.84.21.108[193.110.157.60]:17/%any

This error is again one where one of the left / right parameters was wrong. In this case the local network was using a non-private IP space as private IP space. It will be NATed, but it is not part of the standard virtual_private line. In this case 193.110.157.58/29, the network containing 193.110.157.60, should have been added to the virtual_private= parameter, since it was used behind a NAT router. More often though, 10.0.0.0/8 or 192.168.0.0/16, or the entire

virtual_private= line, is missing from the config setup section of ipsec.conf .

003 «cat2311» #1: we require peer to have ID ‘193.110.157.131’, but peer declares ‘C=CA, ST=Ontario, O=Xelerance, OU=Support Staff, CN=newwest.xelerance.com, E=newwest@xelerance.com’

In this case either there was no rightid= declared, or the right side of the connection on this server is not set up to use certificates, while the incoming connection has been set up to use them. Some gateways, such as Cisco and NetScreen, also use their IPv4 address as their ID, often with a subjectAltName of ipAddress=a.b.c.d . Openswan does not support currently this, since it provides no way to find a certificate from an IPv4 address. You can interop with these devices by just specifying an ID, and then Openswan will not use the DN= of the certificate.

Jan 13 22:21:02 GlowingWhispers pluto[7946]: X.509 certificate is not valid until Mar 19 21:34:55 UTC 2005 (it is now=Mar 19 21:21:02 UTC 2005)

The machine using the certificate and the machine used to generate the certificate are not using the same time. At least one of these machines is not using NTP, with the result that, in this case, the certificate is not yet valid for another 13 minutes.

ipsec_auto: fatal error in «»: (/etc/ipsec.conf, line 104) did not find conn section(s) «nana-vesna»

Unfortunately, the ipsec.conf parser is not very advanced. You must start a new connection definition at the start of a new line, and all subsequent options for that conn must be indented with a tab character. Sometimes, using a mouse with cut and paste can turn tabs into spaces, causing this error. Similar things can happen when a file uses MS-DOS end-of-line sequences, for instance if it has been copied through a Windows machine.

Jul 27 19:45:00 pa pluto[9365]: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM no acceptable Oakley Transform

Debugging and Troubleshooting

The remote end is proposing 1DES only, which is rejected by Openswan unless it has been compiled with USE_WEAKSTUFF (see Makefile.inc ). If no other proposals are sent, the connection is rejected with the no acceptable Oakley transform message. This happens on some hardware routers and on Windows 2000 without Service Pack 1 (or higher). Either install the High Encryption Pack, or the latest service packs.

Sep 10 00:00:37 silvia pluto[1968]: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION

Another example that seems to happen regularly is disagreement about PFS. This might be obvious when you initiate a connection that does not work, but Openswan will allow PFS even with pfs=no , because it is much safer. However, this can lead to the strange situation where if you have a connection between two Openswan machines with different PFS settings, things will work as long as the pfs=no endpoint is responding. However, if the pfs=no endpoint initiates the connection, it will be refused by the other end, which insists on pfs=yes . As stated above, responders can turn into initiators after a number of rekeys, so this could happen hours later without any apparent reason, due to rekey fuzz (randomness in the rekey times). This PFS confusion can also happen when connecting to other IPsec software.

Jan 6 03:015:43 Idaho001 pluto[3497]: only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION

Here, the other end only proposes DH groups that are not supported by Openswan. Usually this means the other end only proposes 1DES. This can also happen later at rekey when talking to an IPsec host that accepts all DH groups, but only proposes one, the wrong one. Some Symantec machines show this behavior.

Jun 16 09:00:00 ams-yyz pluto[2005]: peer requested 64800 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION

Older versions of Openswan set a hardcoded upper limit for the IPsec SA lifetime that was lower than that proposed by other vendors, such as Cisco, Symantec, and Check Point. Current versions of Openswan accept lifetimes up to 64800 seconds, so if you see this error, you should upgrade Openswan.

Dec 31 23:59:59 PHkade pluto[1999]: packet from 193.110.157.17:500: Quick Mode message is for a non-existent (expired?) ISAKMP SA

This end of the IPsec connection (in this case Phase 1, ISAKMP) has been restarted, but the other end does not know about this and is attempting to use a Phase 1 that no longer exists on this end. Either the remote end ignored a Delete/Notify packet, or more likely, this end crashed and never sent it. Either restart the remote end, or just initiate again from this end to replace the Phase 1 on the other end.

May 18 18:13:44 LinuxChildren pluto[7113]: «testme» #1: Signature check (on 193.110.157.17) failed (wrong key?); tried *AQOkF1Ggd

This error means that the RSA key loaded with leftrsasigkey= or rightrsasigkey= is not correct. This usually happens when you mistakenly use the right key as left and the leftkey as right. Sometimes this information is sent by email, or cut and pasted, and newlines or whitespace have accidentally been introduced. Sometimes it is missing the » 0s » part when the key is copied from a DNS record. Once you have repaired the key statements on both ends, reload the connection and try again.

May 18 09:53:34 gnu-toad pluto[3012]: «mikes-paul»: route-host output: /usr/local/lib/ipsec/_updown: doroute `ip route add 193.110.157.131/32 via 193.110.157.131 dev ipsec0 ‘ failed (RTNETLINK answers: Network is unreachable)

This is usually the result of a bug in Openswan when it does not recognize what your default gateway is. This mostly happens with NETKEY, and a lack of an interfaces=»%defaulroute» line. In this case it incorrectly tries to route traffic for the remote through the remote. Openswan adds this route for KLIPS, as KLIPS will only process packets when they are routed into the ipsecX interfaces. These routes should not be attempted on NETKEY though.

A workaround for this is to specify a leftnexthop= setting of your default gateway. You might also have mixed up the leftnexthop= and righnexthop= setting, or you might have specified it, but your ISP changed default gateways on you, so now the nexthop entry has become incorrect.

May 18 19:11:41 BrianFBI pluto[7922]: packet from 70.196.174.6:500: initial Main Mode message received on 193.110.157.131:500 but no connection has been authorized

Either the connection did not load at all, and an error was logged, or there is another reason why it is refusing the conn you thought should match. Double-check that both ends have NAT traversal enabled or disabled, depending on whether this connection goes through a NAT router. This error can also occur if the incoming connection requires PSK instead of RSA, or if there is no connection with either PFS or Aggressive/Main mode. Or it could mean that you do not have any loaded connection at all.

ipsec_auto: fatal error in «south-park»: ID «%any» cannot have RSA key

If you use RSA keys for both left and right, then Openswan can not distinguish between multiple instances of these connections from the first message exchange. You will explicitly need to specify a leftid= and/or a rightid= . If you use certificates, this error should not happen, as the certificate’s DN is automatically used as the ID.

ipsec_auto: fatal error in «mikes-paul»: unknown authby value «rsasigkey»

The authby= option should be either secret or rsasig .

Nov 11 00:13:40 west pluto[2748]: «road-warrior» #14: up-client command exited with status 1

The last thing run by the _updown script probably failed, so that the exit code of _updown indicated failure. This could possibly be a bug in a custom _updown script that has an incorrect return code.

Some versions of Openswan showed this behavior if they could not properly determine the default gateway. In such cases, explicitly setting the leftnexthop= setting to the default gateway works around this bug. This error can also happen when using old versions of Openswan that still support the firewall= option. This option was only necessary for Linux 2.0 kernels, and has been since removed from Openswan.

Mar 12 13:23:17 Manojlovic l2tpd[30898]: getPtyMaster: No more free pseudotty’s

You are using a kernel without ‘legacy (BSD) PTY support’ ( CONFIG_LEGACY_PTYS=y ). Fedora Core 2 and 3 ship without this support. The L2TP daemon generating this error needs these legacy-type PTYs. Either recompile the kernel, or use a more modern version of l2tpd with support for modern Unix PTYs.

Debugging and Troubleshooting

protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but are 17/0

You are trying to connect a Windows client without the latest service packs, or to connect an old broken Cisco PIX to an old version of Openswan. Upgrade the Windows clients or replace the old unsupported Cisco PIX, or upgrade Openswan and add rightprotoport=17/%any .

Question: I want to use AH+ESP, with Racoon/setkey I can, but with Openswan it does not work?

NETKEY (and Kame) are quite happy to permit you to configure completely bogus encapsulation combinations, and seem quite happy to accept them as well. So your odd stacked encapsulations will work with an interop with Kame/NETKEY/Racoon only. Note that these are both silly (it wastes 20 more bytes for AH + ESP) but worse, they are quite insecure too—ESP without AH/AUTH in the same layer of encapsulation is insecure and vulnerable to known attacks.

Question: I have troubles with the VPN-passthrough feature of my modem. It de-capsulates the ESP traffic encapsulated in UDP 4500 packets and sends ESP packets with its own SPI number.

Some modems and routers exhibit this behavior. In this case, it was a Conexant modem, but many small devices offer «IPsec passthrough support» that cannot be disabled. There is no solution for this problem other than throwing the hardware away.

Oct 7 05:23:17 ooievaar pluto[23652]: «fenrir-managers» #5: ERROR: asynchronous network error report on eth0 for message to 193.110.157.17 port 500, complainant 193.110.157.131: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

A firewall (193.110.157.131) is rejecting UDP 500 for the machine behind it (193.110.15.17).

Apr 1 12:54:32 4u-e pluto: «wlan»[2] 192.168.1.111 #1: cannot respond to IPsec SA request because no connection is known for 192.168.1.0/24===192.168.1.35[S=C]. 192.168.1.111[0.0.0.0,S=C]

Indeed, this configuration is impossible. You cannot have a left= that is part of leftsubnet= . How could you reach left without having a connection to the leftsubnet, which requires left? You can’t, just as you cannot run a firewall on 193.111.228.254 to protect the entire 193.111.228.0/24 network. This person is probably trying to secure a local wireless LAN. Instead, a configuration similar to the following should have been used on the server:

conn wlan left=192.168.1.35 leftsubnet=0.0.0.0/0 right=%any

and on the client:

conn lwan left=%defaultroute right=192.168.1.35 rightsubnet=0.0.0.0/0 [. ]

See the WaveSEC section of Chapter 10 for a detailed description on how to accomplish this.

Another reason why people sometimes make this ‘left in leftsubnet’ mistake is that their ISP has given them a subnet without a single point of entry. In other words, the entire customer subnet is reached directly from the ISP’s router. In this situation, how could you set up a VPN tunnel to a single machine from that subnet to reach the entire subnet?

You could set up an IP alias on 1.2.3.1, for example:

# ifconfig eth0:1 192.168.1.244

Now you can build a tunnel from the remote end to 1.2.3.1 for the subnet 192.168.1.0/24. If you add aliases to your machines in the /24, you could reach them directly on their internal IP addresses over IPsec. Do not use the ip command to add IP addresses to the interface, since Openswan cannot handle that way of IP addressing. You could also run some NAT rule using the latest iptables , which supports the NETMAP target to allow you to NAT a whole subnet onto another subnet.

Nov 25 12:00:13 Reina «cert»[1] 169.254.0.100 #21: encrypted Informational Exchange message is invalid because it is for incomplete ISAKMP SA

It seems that Windows is the only client that somehow thinks it can encrypt information messages before the Phase 1 is complete. This always means that the configuration on Openswan and the Windows machines does not match. What happens is that one end (Windows) thinks it has successfully started an ISAKMP SA, but Openswan does not agree with that. One end sends a message, and the other end will drop it because either it is encrypted when it should not be, or it should be encrypted but is not. This error often happens when there is no valid certificate on the Windows machine. In this case, it was due to a bad clock setting, causing the certificate to become invalid.

030 ignoring message from whack with bad magic 1869114144; should be 1869114140; probably wrong version

The Openswan programs whack and pluto do not come from the same compile. Re-install the package or compile yourself from source. Also make sure there are not two versions of Openswan installed, one in /usr and one in /usr/local .

Question: My gateway-subnet ping does not work on debian

The Debian netkit package, which contains the ping command, is broken and does not properly support the -I option. It accepts this option, but then ignores it. This results in pinging from the default outgoing address, likely not covered in the IPsec tunnel definition (unless leftsourceip= is used). A solution is to install a better ping program using apt-get install iputil-ping .

May 18 11:38:04 domoor pluto[23206]: «roadwarrior-l2tp»[21] 193.110.157.17 #20: end certificate with identical subject and issuer not accepted

May 18 11:38:04 domoor pluto[23206]: «roadwarrior-l2tp»[21] 193.110.157.17 #20: X.509 certificate rejected

The root CA that signed the X.509 Certificate of the incoming connection has the same Common Name ( CN= ) as the root CA itself. This is a security problem and is not allowed, and the certificate will be rejected. You can prevent this by adding the string «Root CA» in the CA’s CN.

Mar 27 14:11:32 reggestraat pluto[16339]: ERROR: asynchronous network error report on ppp0 for message to 193.251.9.130 port 500, complainant 62.4.10.15: Message too long [errno 90, origin ICMP type 3 code 4 (not authenticated)]

When sniffing the interface with tcpdump , you see something like:

14:11:32.076807 193.251.9.130.500 > 80.65.1.2.500: isakmp: phase 1 I ident[E]: [encrypted id] (frag 5721:1472@0+)

14:11:32.079680 193.251.9.130 > 80.65.1.2: (frag 5721:236@1472)

Источник

chastener
подпись на выбор, в личку sklifу

Зарегистрирован: 29.06.2011
Пользователь #: 132,104
Сообщения: 10906

Источник

IPsec VPN через Strongswan: ошибка авторизации

Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.

edit: добавил лог с сервера

Хм, а так можно было оказывается.

Покажите лог с сервера.

Хм, а так можно было оказывается.

Забыл сразу добавить, отредактировал пост.

Та я как-то привык к ipsec.conf

От оно:
server charon[994]: 15[CFG] no matching peer config found

Не совсем понял, это для клиента указать? А куда тогда адрес сервера вбивать?

Это для сервера.

попробую переписать серверный конфиг в ipsec.conf-стиле

На всякий случай кусок из моего ipsec.conf

я как раз думал, что все уже много лет назад пересели на swanctl

Кроме того, я переписал почти один в один серверный конфиг:

А для продакшена, конечно, полезно по OU фильтровать.

Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

Может и так. А может документацию не дописали. 😉

Я в OU фильтрую по разным реализациям клиентов.

Отличная идея, не думал о таком варианте.

anc если вдруг интересно

Источник

Adblock
detector

Источник

Виртуальная частная сеть (VPN) в основном используется для защиты конфиденциальности пользователей в онлайн-мире и определения их физического местоположения. Хотя в большинстве случаев они работают хорошо, в некоторых случаях пользователь может столкнуться с ошибками, сбоями или другими проблемами с подключением в своей программе VPN. Если ваша VPN не работает, не подключается или заблокирована, вы можете попробовать несколько быстрых решений. Хотя существует множество возможных ошибок, с которыми пользователь может столкнуться при использовании VPN, некоторые из них получают большее признание, чем другие; один из таких кодов ошибки Ошибка VPN 13801.

Ошибка 13801

Ошибка VPN 13801 в Windows 10

Ошибка 13801 выражает сообщение — Учетные данные для аутентификации IKE недопустимы.

Эти ошибки Internet Key Exchange версии 2 (IKEv2) связаны с проблемами с сертификатом проверки подлинности сервера. По сути, сертификат компьютера, необходимый для аутентификации, либо недействителен, либо отсутствует на вашем клиентском компьютере, на сервере или на обоих.

Учетные данные для аутентификации IKE недопустимы

Вот краткое описание возможных причин ошибки 13801:

Срок действия сертификата компьютера на сервере удаленного доступа истек.
Доверенный корневой сертификат для проверки сертификата сервера удаленного доступа отсутствует на клиенте.
Имя VPN-сервера, указанное на клиенте, не соответствует имени субъекта сертификата сервера.
Сертификат компьютера, используемый для проверки IKEv2 на сервере удаленного доступа, не имеет «проверки подлинности сервера» в качестве EKU (расширенного использования ключа).

Поскольку пользователи не имеют никакого контроля над сервером, мало что можно сделать для решения этой проблемы. И в большинстве случаев пользователю, возможно, придется обратиться в службу поддержки провайдера VPN и попросить их исправить ошибку 13801.

Ошибка VPN 13801 явно ссылается на протоколы, используемые службой VPN, поэтому вам не нужно тратить время на выяснение того, что такое IKEv2 для ошибки 1380 VPN. Найдите правильный сертификат IKEv2 в документации, предоставленной администратором VPN. Есть несколько способов подтвердить эту проблему:

Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
Срок действия сертификата компьютера на сервере удаленного доступа истек.
Доверенный корень сертификата отсутствует на клиенте.
Имя субъекта сертификата не соответствует удаленному компьютеру

Давайте рассмотрим эти варианты подробнее:

Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).

Вы можете проверить это, выполнив следующие действия:

1]На сервере VPN запустите ммс, добавить оснастку ‘сертификаты. ‘

2]Разверните сертификаты-личные-сертификаты, дважды щелкните установленный сертификат

3]Щелкните подробное описание для «улучшенное использование ключа ‘, проверьте, есть ли ‘проверка подлинности сервера‘ ниже

Срок действия сертификата компьютера на сервере удаленного доступа истек.

Если проблема вызвана этой причиной, подключите Администратор ЦС и зарегистрируйте новый сертификат, срок действия которого не истекает.

Доверенный корень сертификата отсутствует на клиенте.

Если клиент и сервер являются членами домена, корневой сертификат будет автоматически установлен в ‘доверенные корневые центры сертификации.’ Проверить наличие сертификата на клиенте можно здесь.

Имя субъекта сертификата не соответствует удаленному компьютеру

Вы можете подтвердить, используя следующие шаги:

1]На клиенте открыть ‘Свойства VPN-подключения‘, щелкните’Общий. ‘

2]В ‘имя хоста или IP-адрес назначения‘вам нужно будет ввести’имя субъекта‘сертификата, используемого сервером VPN вместо IP-адреса сервера VPN.

Примечание: Имя субъекта сертификата сервера обычно настраивается как полное доменное имя VPN-сервера.

Когда звонить администратору VPN-сервера

Необходимость иметь дело с ошибками VPN может быть чрезвычайно неприятным, а когда вы не можете устранить их самостоятельно, разочарование еще больше. Это именно тот случай с ошибкой VPN 13801, поэтому не теряйте времени и обратитесь к администратору VPN, чтобы убедиться, что на вашем ПК настроен правильный сертификат, который подтвержден удаленным сервером.

Источник

Добрый день!

Собственно, как и следует из названия темы, устройство начинает пробрасывать тоннель, причём, по какой-то непостижимой причине, производится сразу несколько попыток. В результате, соединение успешно устанавливается в рамках одного из согласований, а затем благополучно дропается, т.к. другое не получает ответа от Циски и рубит по тайм-ауту. Что характерно, с самим соединений никаких проблем нет: пакеты ходят, компы друг друга видят, пингуют…

Версия прошивки: v2.08(AAUU.4)C2

Версия Циски: 15.4

Логи Кинетика:

Nov 10 13:15:01ipsec
06[MGR] ignoring request with ID 0, already processing 
Nov 10 13:15:08ipsec
16[IKE] remote host is behind NAT 
Nov 10 13:15:08ipsec
14[CFG] looking for peer configs matching ZYXEL_IP[%any]...CISCO_IP[192.168.0.2] 
Nov 10 13:15:08ipsec
14[CFG] selected peer config 'Test' 
Nov 10 13:15:08ipsec
14[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:15:08ipsec
14[IKE] authentication of '192.168.0.2' with pre-shared key successful 
Nov 10 13:15:08ipsec
14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Nov 10 13:15:08ipsec
14[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:15:08ipsec
14[IKE] authentication of 'ZYXEL_IP' (myself) with pre-shared key 
Nov 10 13:15:08ipsec
14[IKE] IKE_SA Test[4] established between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:15:08ipsec
14[IKE] scheduling reauthentication in 3573s 
Nov 10 13:15:08ipsec
14[IKE] maximum IKE_SA lifetime 3593s 
Nov 10 13:15:08ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 0.
Nov 10 13:15:08ipsec
14[CFG] received proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:15:08ipsec
14[CFG] configured proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/MODP_4096/NO_EXT_SEQ 
Nov 10 13:15:08ipsec
14[CFG] selected proposal: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:15:08ipsec
14[IKE] CHILD_SA Test{2} established with SPIs c12ee9c8_i c20b83b1_o and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:15:08ndm
IpSec::Configurator: crypto map "Test" is up.
Nov 10 13:15:08ndm
IpSec::Configurator: reconnection for crypto map "Test" was cancelled.
Nov 10 13:15:08ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 1.
Nov 10 13:15:08ndm
IpSec::IpSecNetfilter: start reloading netfilter configuration...
Nov 10 13:15:08ndm
IpSec::IpSecNetfilter: netfilter configuration reloading is done.
Nov 10 13:15:11ipsec
10[IKE] retransmit 1 of request with message ID 0 
Nov 10 13:15:20ipsec
08[IKE] retransmit 2 of request with message ID 0 
Nov 10 13:15:30ipsec
10[IKE] retransmit 3 of request with message ID 0 
Nov 10 13:15:41ipsec
09[IKE] retransmit 4 of request with message ID 0 
Nov 10 13:15:52ipsec
05[IKE] retransmit 5 of request with message ID 0 
Nov 10 13:16:05ipsec
10[IKE] retransmit 6 of request with message ID 0 
Nov 10 13:16:20ipsec
09[IKE] retransmit 7 of request with message ID 0 
Nov 10 13:16:35ipsec
16[IKE] retransmit 8 of request with message ID 0 
Nov 10 13:16:52ipsec
12[IKE] giving up after 8 retransmits 
Nov 10 13:16:52ndm
IpSec::Configurator: remote peer of crypto map "Test" is down.
Nov 10 13:16:52ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:16:52ndm
IpSec::Configurator: fallback peer is not defined for crypto map "Test", retry.
Nov 10 13:16:52ndm
IpSec::Configurator: schedule reconnect for crypto map "Test".
Nov 10 13:16:52ipsec
12[IKE] establishing IKE_SA failed, peer not responding 
Nov 10 13:17:08ndm
IpSec::Configurator: reconnecting crypto map "Test".
Nov 10 13:17:10ndm
IpSec::Configurator: crypto map "Test" shutdown started.
Nov 10 13:17:10ipsec
12[CFG] received stroke: unroute 'Test' 
Nov 10 13:17:10ipsec
13[CFG] received stroke: terminate 'Test{*}' 
Nov 10 13:17:10ipsec
16[IKE] closing CHILD_SA Test{2} with SPIs c12ee9c8_i (40144 bytes) c20b83b1_o (811908 bytes) and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:17:10ipsec
16[IKE] sending DELETE for ESP CHILD_SA with SPI c12ee9c8 
Nov 10 13:17:10ipsec
09[IKE] received DELETE for ESP CHILD_SA with SPI c20b83b1 
Nov 10 13:17:10ipsec
09[IKE] CHILD_SA closed 
Nov 10 13:17:10ipsec
14[CFG] received stroke: terminate 'Test[*]' 
Nov 10 13:17:10ndm
IpSec::Configurator: crypto map "Test" shutdown complete.
Nov 10 13:17:11ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:17:11ipsec
06[IKE] deleting IKE_SA Test[4] between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:17:11ipsec
06[IKE] sending DELETE for IKE_SA Test[4] 
Nov 10 13:17:11ipsec
11[IKE] IKE_SA deleted 
Nov 10 13:17:11ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:17:11ndm
IpSec::IpSecNetfilter: start reloading netfilter configuration...
Nov 10 13:17:11ndm
IpSec::IpSecNetfilter: netfilter configuration reloading is done.
Nov 10 13:17:11ipsec
15[IKE] received Cisco Delete Reason vendor ID 
Nov 10 13:17:11ipsec
15[IKE] CISCO_IP is initiating an IKE_SA 
Nov 10 13:17:11ipsec
15[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:17:11ipsec
15[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:17:11ipsec
15[CFG] selected proposal: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:17:11ipsec
12[CFG] received stroke: initiate 'Test' 
Nov 10 13:17:11ndm
IpSec::Configurator: crypto map "Test" initialized.
Nov 10 13:17:13ipsec
07[MGR] ignoring request with ID 0, already processing 
Nov 10 13:17:17ipsec
09[MGR] ignoring request with ID 0, already processing 
Nov 10 13:17:19ipsec
15[IKE] remote host is behind NAT 
Nov 10 13:17:19ipsec
16[IKE] initiating IKE_SA Test[6] to CISCO_IP 
Nov 10 13:17:20ipsec
14[CFG] looking for peer configs matching ZYXEL_IP[%any]...CISCO_IP[192.168.0.2] 
Nov 10 13:17:20ipsec
14[CFG] selected peer config 'Test' 
Nov 10 13:17:20ipsec
14[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:17:20ipsec
14[IKE] authentication of '192.168.0.2' with pre-shared key successful 
Nov 10 13:17:20ipsec
14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Nov 10 13:17:20ipsec
14[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:17:20ipsec
14[IKE] authentication of 'ZYXEL_IP' (myself) with pre-shared key 
Nov 10 13:17:20ipsec
14[IKE] IKE_SA Test[5] established between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:17:20ipsec
14[IKE] scheduling reauthentication in 3569s 
Nov 10 13:17:20ipsec
14[IKE] maximum IKE_SA lifetime 3589s 
Nov 10 13:17:20ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 0.
Nov 10 13:17:20ipsec
14[CFG] received proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:17:20ipsec
14[CFG] configured proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/MODP_4096/NO_EXT_SEQ 
Nov 10 13:17:20ipsec
14[CFG] selected proposal: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:17:20ipsec
14[IKE] CHILD_SA Test{3} established with SPIs c96d5999_i 8d98ca14_o and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:17:20ndm
IpSec::Configurator: crypto map "Test" is up.
Nov 10 13:17:20ndm
IpSec::Configurator: reconnection for crypto map "Test" was cancelled.
Nov 10 13:17:20ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 1.
Nov 10 13:17:20ndm
IpSec::IpSecNetfilter: start reloading netfilter configuration...
Nov 10 13:17:20ndm
IpSec::IpSecNetfilter: netfilter configuration reloading is done.
Nov 10 13:17:32ipsec
11[IKE] retransmit 1 of request with message ID 0 
Nov 10 13:17:41ipsec
07[IKE] retransmit 2 of request with message ID 0 
Nov 10 13:17:50ipsec
05[IKE] retransmit 3 of request with message ID 0 
Nov 10 13:18:01ipsec
13[IKE] retransmit 4 of request with message ID 0 
Nov 10 13:18:13ipsec
05[IKE] retransmit 5 of request with message ID 0 
Nov 10 13:18:26ipsec
15[IKE] retransmit 6 of request with message ID 0 
Nov 10 13:18:40ipsec
13[IKE] retransmit 7 of request with message ID 0 
Nov 10 13:18:55ipsec
16[IKE] retransmit 8 of request with message ID 0 
Nov 10 13:19:13ipsec
14[IKE] giving up after 8 retransmits 
Nov 10 13:19:13ndm
IpSec::Configurator: remote peer of crypto map "Test" is down.
Nov 10 13:19:13ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:19:13ndm
IpSec::Configurator: fallback peer is not defined for crypto map "Test", retry.
Nov 10 13:19:13ndm
IpSec::Configurator: schedule reconnect for crypto map "Test".
Nov 10 13:19:13ipsec
14[IKE] establishing IKE_SA failed, peer not responding 
Nov 10 13:19:29ndm
IpSec::Configurator: reconnecting crypto map "Test".
Nov 10 13:19:31ndm
IpSec::Configurator: crypto map "Test" shutdown started.
Nov 10 13:19:31ipsec
14[CFG] received stroke: unroute 'Test' 
Nov 10 13:19:31ipsec
08[CFG] received stroke: terminate 'Test{*}' 
Nov 10 13:19:31ipsec
16[IKE] closing CHILD_SA Test{3} with SPIs c96d5999_i (24735 bytes) 8d98ca14_o (68197 bytes) and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:19:31ipsec
16[IKE] sending DELETE for ESP CHILD_SA with SPI c96d5999 
Nov 10 13:19:31ipsec
13[IKE] received DELETE for ESP CHILD_SA with SPI 8d98ca14 
Nov 10 13:19:31ipsec
13[IKE] CHILD_SA closed 
Nov 10 13:19:31ipsec
09[CFG] received stroke: terminate 'Test[*]' 
Nov 10 13:19:31ndm
IpSec::Configurator: crypto map "Test" shutdown complete.
Nov 10 13:19:31ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:19:31ipsec
10[IKE] deleting IKE_SA Test[5] between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:19:31ipsec
10[IKE] sending DELETE for IKE_SA Test[5] 
Nov 10 13:19:31ndm
IpSec::IpSecNetfilter: start reloading netfilter configuration...
Nov 10 13:19:31ndm
IpSec::IpSecNetfilter: netfilter configuration reloading is done.
Nov 10 13:19:32ipsec
12[CFG] received stroke: initiate 'Test' 
Nov 10 13:19:32ndm
IpSec::Configurator: crypto map "Test" initialized.
Nov 10 13:19:39ipsec
15[IKE] unable to create CHILD_SA while deleting IKE_SA 
Nov 10 13:19:39ipsec
05[IKE] IKE_SA deleted 
Nov 10 13:19:39ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:19:39ipsec
07[IKE] initiating IKE_SA Test[7] to CISCO_IP 
Nov 10 13:19:51ipsec
08[IKE] retransmit 1 of request with message ID 0 
Nov 10 13:20:00ipsec
13[IKE] retransmit 2 of request with message ID 0 
Nov 10 13:20:01ipsec
10[IKE] received Cisco Delete Reason vendor ID 
Nov 10 13:20:01ipsec
10[IKE] CISCO_IP is initiating an IKE_SA 
Nov 10 13:20:01ipsec
10[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:20:01ipsec
10[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:20:01ipsec
10[CFG] selected proposal: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096/# 
Nov 10 13:20:03ipsec
14[MGR] ignoring request with ID 0, already processing 
Nov 10 13:20:06ipsec
16[MGR] ignoring request with ID 0, already processing 
Nov 10 13:20:09ipsec
10[IKE] remote host is behind NAT 
Nov 10 13:20:09ipsec
08[CFG] looking for peer configs matching ZYXEL_IP[%any]...CISCO_IP[192.168.0.2] 
Nov 10 13:20:09ipsec
08[CFG] selected peer config 'Test' 
Nov 10 13:20:09ipsec
08[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:20:09ipsec
08[IKE] authentication of '192.168.0.2' with pre-shared key successful 
Nov 10 13:20:09ipsec
08[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Nov 10 13:20:09ipsec
08[IKE] linked key for crypto map 'Test' is not found, still searching 
Nov 10 13:20:09ipsec
08[IKE] authentication of 'ZYXEL_IP' (myself) with pre-shared key 
Nov 10 13:20:09ipsec
08[IKE] IKE_SA Test[8] established between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:20:09ipsec
08[IKE] scheduling reauthentication in 3567s 
Nov 10 13:20:09ipsec
08[IKE] maximum IKE_SA lifetime 3587s 
Nov 10 13:20:09ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 0.
Nov 10 13:20:09ipsec
08[CFG] received proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:20:09ipsec
08[CFG] configured proposals: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/MODP_4096/NO_EXT_SEQ 
Nov 10 13:20:09ipsec
08[CFG] selected proposal: ESP:AES_CBC=256/HMAC_SHA2_256_128/#/#/NO_EXT_SEQ 
Nov 10 13:20:09ipsec
08[IKE] CHILD_SA Test{4} established with SPIs cdeb3b19_i 00d56f15_o and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:20:09ndm
IpSec::Configurator: crypto map "Test" is up.
Nov 10 13:20:09ndm
IpSec::Configurator: reconnection for crypto map "Test" was cancelled.
Nov 10 13:20:09ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 1, active CHILD SA: 1.
Nov 10 13:20:09ndm
IpSec::IpSecNetfilter: start reloading netfilter configuration...
Nov 10 13:20:10ndm
IpSec::IpSecNetfilter: netfilter configuration reloading is done.
Nov 10 13:20:10ipsec
05[IKE] retransmit 3 of request with message ID 0 
Nov 10 13:20:20ipsec
15[IKE] retransmit 4 of request with message ID 0 
Nov 10 13:20:32ipsec
05[IKE] retransmit 5 of request with message ID 0 
Nov 10 13:20:45ipsec
08[IKE] retransmit 6 of request with message ID 0 
Nov 10 13:20:48ndhcps
_WEBADMIN: DHCPREQUEST received (STATE_SELECTING) for 192.168.10.45 from 74:04:2b:84:60:e8.
Nov 10 13:20:48ndhcps
_WEBADMIN: sending ACK of 192.168.10.45 to 74:04:2b:84:60:e8.
Nov 10 13:20:59ipsec
16[IKE] retransmit 7 of request with message ID 0 
Nov 10 13:21:15ipsec
15[IKE] retransmit 8 of request with message ID 0 
Nov 10 13:21:32ipsec
13[IKE] giving up after 8 retransmits 
Nov 10 13:21:32ndm
IpSec::Configurator: remote peer of crypto map "Test" is down.
Nov 10 13:21:32ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:21:32ndm
IpSec::Configurator: fallback peer is not defined for crypto map "Test", retry.
Nov 10 13:21:32ndm
IpSec::Configurator: schedule reconnect for crypto map "Test".
Nov 10 13:21:32ipsec
13[IKE] establishing IKE_SA failed, peer not responding 
Nov 10 13:21:48ndm
IpSec::Configurator: reconnecting crypto map "Test".
Nov 10 13:21:50ndm
IpSec::Configurator: crypto map "Test" shutdown started.
Nov 10 13:21:50ipsec
13[CFG] received stroke: unroute 'Test' 
Nov 10 13:21:50ipsec
07[CFG] received stroke: terminate 'Test{*}' 
Nov 10 13:21:50ipsec
15[IKE] closing CHILD_SA Test{4} with SPIs cdeb3b19_i (24726 bytes) 00d56f15_o (85210 bytes) and TS 192.168.10.0/24 === 192.168.0.0/24 
Nov 10 13:21:50ipsec
15[IKE] sending DELETE for ESP CHILD_SA with SPI cdeb3b19 
Nov 10 13:21:50ipsec
16[IKE] received DELETE for ESP CHILD_SA with SPI 00d56f15 
Nov 10 13:21:50ipsec
16[IKE] CHILD_SA closed 
Nov 10 13:21:50ipsec
06[CFG] received stroke: terminate 'Test[*]' 
Nov 10 13:21:50ndm
IpSec::Configurator: crypto map "Test" shutdown complete.
Nov 10 13:21:50ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.
Nov 10 13:21:50ipsec
08[IKE] deleting IKE_SA Test[8] between ZYXEL_IP[ZYXEL_IP]...CISCO_IP[192.168.0.2] 
Nov 10 13:21:50ipsec
08[IKE] sending DELETE for IKE_SA Test[8] 
Nov 10 13:21:50ipsec
05[IKE] IKE_SA deleted 
Nov 10 13:21:50ndm
IpSec::Configurator: crypto map "Test" active IKE SA: 0, active CHILD SA: 0.

Спасибо!

Edited November 13, 2017 by Никита Болдин

Источник

Дорогие пользователи! У нас появился новый форум на платформе tp-link.community (Сообщество)

Форум доступен по ссылке https://community.tp-link.com/ru

Если при регистрации в Сообществе Вы укажете адрес электронный почты, который используете на данном форуме, то Ваши данные будут перенесены на форум Сообщества автоматически.
Также, если на форуме Сообщества Ваш никнейм будет занят, то Вам предложат сменить его или оставить, но с приставкой «_RU».

Подробнее Вы можете прочитать тут: https://community.tp-link.com/ru/home/f … pic/501542

Убедительная просьба не дублировать темы на старом/новом форуме.

modsamara: Сообщения: 1; Зарегистрирован: 24 май 2016, 19:10; Страна: Россия

WAN1: Phase 2 of IKE negotiation failed. Error=18

Название темы: WAN1: Phase 2 of IKE negotiation failed. Error=18
Аппаратная версия устройства: 3.0
Провайдер: ростелеком
Тип подключения: PPPoE

Логи оборудования:
WAN1: Enable DPD successfully. (DPD-Interval=10, Peers=90.150.87.134<->91.135.154.140)
WAN1: Phase 2 of IKE negotiation succeeded. (Peers=90.150.87.134<->91.135.154.140)
WAN1: Phase 2 of IKE negotiation failed. (Peers=90.150.87.134<->91.135.154.140, Error=18)
WAN1: Phase 1 of IKE negotiation succeeded. (Peers=90.150.87.134<->91.135.154.140)
WAN1: IKE negotiation began in responder mode. (Mode=Main Mode, Peers=90.150.87.134<->91.135.154.140)
WAN1: IPsec connection was disconnected passively. (Peers=90.150.87.134<->91.135.154.140)

Описание проблемы: Всем добра
LAN-2-LAN впн между MS TMG и 6120
периодически пропадает пинг из одной сети в другую
в логах вышеозначенная беда
куда копать ошибку 18 не совсем понятно

reaper: Модератор; Сообщения: 553; Зарегистрирован: 03 июн 2017, 20:11; Страна: Россия

Re: WAN1: Phase 2 of IKE negotiation failed. Error=18

Сообщение

reaper » 11 ноя 2020, 18:15

Добрый день.
По всей видимости Вы уже связались с нами по электронной почте, поэтому решение проблемы будем заниматься используя ее, результат можно будет указать здесь.

Источник

Sometimes while I install the site-to-site IPsec between VPN boxes, I’m getting some error that everyone generally come upon. I wanna write these errors. I hope this post is useful for new beginners.

I will examine the error messages according to the topology below.

ERROR-1:

Routing failed to locate next hop for udp from NP Identity Ifc:188.18.17.1/62465 to mpls:3.3.3.1/62465

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2

ERROR-2:

Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= mpls_map. Map Sequence Number = 2.

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.

THE SOLUTION OF ERROR-1,2:

These errors say that there is a big wrong in our configuration. This is a reachability problem between VPN boxes. if we have two exits points. Related routes might not be written to the correct point in our VPN boxes. Sometimes we are typing the wrong subnet mask. For my example; Now I’m writing route to the correct point. If the route is not written to the correct point, the IPsec tunnel will be tried to install over the internet interface because of the default route. For this is not to happen, we have to write the route to Mpls interface on both devices so they can access each other.

Add the IP address of the Fortinet to ASA’s routing table.

Or add the IP address of the ASA to Fortinet’s routing table.

Here is the result;

Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED

Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1. Map Tag = mpls_map. Map Sequence Number = 2.

Group = 3.3.3.1, IP = 3.3.3.1, IKE Initiator: New Phase 2, Intf mpls, IKE Peer 3.3.3.1 local Proxy Address 20.20.20.0, remote Proxy Address 192.168.60.0, Crypto map (mpls_map)

Group = 3.3.3.1, IP = 3.3.3.1, Security negotiation complete for LAN-to-LAN Group (3.3.3.1) Responder, Inbound SPI = 0xaa2c7b53, Outbound SPI = 0x67ee5d0a

IPSEC: An outbound LAN-to-LAN SA (SPI= 0x67EE5D0A) between 188.18.17.1 and 3.3.3.1 (user= 3.3.3.1) has been created.

IPSEC: An inbound LAN-to-LAN SA (SPI= 0xAA2C7B53) between 188.18.17.1 and 3.3.3.1 (user= 3.3.3.1) has been created.

Group = 3.3.3.1, IP = 3.3.3.1, PHASE 2 COMPLETED (msgid=22e90ccb)

IKEv1 was successful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.

ERROR-3:

Phase 1 failure: Mismatched attribute types for class Group Description: Rcv'd: Group 5 Cfg'd: Group 2

Group = 3.3.3.1, IP = 3.3.3.1, Duplicate Phase 1 packet detected. Retransmitting last packet.

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.

THE SOLUTION OF ERROR-3:

İf you are getting the error that is a mismatched attribute in PHASE 1. You first have to check the ike pre-share key. The pre-shared key may not be matched on both sides.

ERROR-4;

IP = 3.3.3.1, Error processing payload: Payload ID: 1

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.

THE SOLUTION OF ERROR-4:

A packet has been received with a payload that cannot be processed. Generally, This error comes up when the IKE policy does not match on both peers. So this is related to PHASE-1. We must fix policies on both sides.

Cisco ASA side;

Fortigate Fw side;

ERROR-5:

Group = 3.3.3.1, IP = 3.3.3.1, IKE Initiator: New Phase 2, Intf mpls, IKE Peer 3.3.3.1 local Proxy Address 20.20.20.0, remote Proxy Address 192.168.60.0, Crypto map (mpls_map)

Group = 3.3.3.1, IP = 3.3.3.1, Received non-routine Notify message: No proposal chosen (14)

Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffce4c3170, mess id 0x92bb8655)!

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.

Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED

THE SOLUTION OF ERROR-5;

The keywords are for us; Received non-routine Notify message: No proposal chosen. The error says where is wrong in our configuration. This error is in phase-2 because phase-1 is completed. The meaning of No proposal may be related IPSEC encryption list.

Cisco ASA side;

Fortinet FW side;

If you set the proper encryption algorithm in both VPN boxes. The problem will be solved.

ERROR-6:

Group = 3.3.3.1, IP = 3.3.3.1, Received non-routine Notify message: No proposal chosen (14)

Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffce4d4ac0, mess id 0xf37ec058)!

Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED

THE SOLUTION OF ERROR-6;

This error is almost the same as Error-5. Phase-1 is completed but Phase-2 is not completed. The PFS is enabled on Fortinet Fw but is disabled on Cisco ASA. I have to change as to enable on Cisco.

ERROR-7:

Group = 3.3.3.1, IP = 3.3.3.1, QM FSM error (P2 struct &0x00007fffcda24c00, mess id 0x3be33942)!

Group = 3.3.3.1, IP = 3.3.3.1, Removing peer from correlator table failed, no match!

IKEv1 was unsuccessful at setting up a tunnel. Map Tag = mpls_map. Map Sequence Number = 2.
Group = 3.3.3.1, IP = 3.3.3.1, PHASE 1 COMPLETED

THE SOLUTION OF ERROR-7;

There is no proposal like in error-5,6. This error is related to phase-2. You have to check the ISAKMP and crypto map configuration on both peers. My problem is the wrong local subnet on Fortinet Fw In my configuration.

ERROR-8:

Local:188.18.17.1:500 Remote:3.3.3.1:500 Username:Unknown IKEv2 Received a IKE_INIT_SA request

Local:188.18.17.1:500 Remote:3.3.3.1:500 Username:Unknown IKEv2 Negotiation aborted due to ERROR: Failed to find a matching policy

THE SOLUTION OF ERROR-8:

If we get this error. There is a conflict in IKE versions. We have to set the same IKE version.

ERROR-9:

3Jun 30 202109:03:39713061Group = 3.3.3.1, IP = 3.3.3.1, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.60.0/255.255.255.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface mpls

THE SOLUTION OF ERROR-9:

You know, the policies should be the same on both sides. When I look at the Fortigate side, I see that the remote network is marked as all. The only required network should be marked on both sides.

Fortinet;

The remote address should be changed with 20.20.20.0/24

Asa;

I hope that will be useful.

Thanks for Reading

Источник