Phase 1 negotiation failed due to send error mikrotik

Fri Jan 12, 2018 11:06 am

Re: permanent «phase 1 negotiation failed»

Fri Jan 12, 2018 1:46 pm

Hi Sindy,
I have no access to a console but I managed to use Winbox to look at the IP IPsec configuration. Will it be the same?
This is the information that I collected. I have not replaced any address because it only has generic addresses:

• Policies
— *T
Src.Address ::/0
Src.Port Dst. Address ::/0
Protocol 0 (all)
Action encrypt
Level require
Tunnel no
• Groups
— *
Default
• Peers
—
Address 0.0.0.0
Port 500
Hash algoritm sha512
Encryption algorithm 3des aes-256
• Remote peers
—
Local address 127.0.0.1
Remote address 0.0.0.0
• Mode configs
— *
Name request-only
Address pool Address prefix Split-include Send DNS yes
• Proposals
— *
Name default
Auth algorithms sha1
Encr algorithms aes-128 cbc aes-192 cbc aes-256 cbc
Lifetime 00:30:00
PFS Group modp 1024
—
Name proposal1
Auth algorithms sha1 sha512
Encr algorithms 3des cbc aes-256 ctr
Lifetime 00:30:00
PFS Group none
• Installed SAs • Keys • Users

Re: permanent «phase 1 negotiation failed»

Fri Jan 12, 2018 5:36 pm

If you can connect using Winbox, you should be able to press the «console» button and get the command line window.

Now as you have just a single peer defined in the

Источник

Phase 1 negotiation failed due to send error mikrotik

Thu Nov 12, 2015 2:56 pm

Re: IPSec Phase 1 fails on restart, multiple IPs

Tue Nov 17, 2015 7:40 pm

Re: IPSec Phase 1 fails on restart, multiple IPs

Tue Nov 17, 2015 9:20 pm

Re: IPSec Phase 1 fails on restart, multiple IPs

Thu Nov 19, 2015 3:37 pm

I have more or less the same problem that cannot be solved at the moment . at least by me

Problem is in fact that MT tries to reach gateway from lowest IP number.
For ex. if you have .3, .2, .1 on WAN and ipsec is made from .2 then MT is trying to push all traffic through .1 address to gateway. It NATs your .2 outgoing traffic to .1 and sends it out from .1 to remote end of ipsec.
How to solve this i have no idea
Tried everything i could come up with. Including ipsec-peer-local ip = . 2, adding AS routes with preferred source etc . nothing seems to help in normal way.
To get it running disable/enable .1 ip on WAN (.2 becomes preferred output IP) and it is working till reboot when .1 comes to preferred output ip again

Re: IPSec Phase 1 fails on restart, multiple IPs

Thu Nov 19, 2015 3:57 pm

I have more or less the same problem that cannot be solved at the moment . at least by me

Источник

Phase 1 negotiation failed due to send error mikrotik

Wed Mar 03, 2021 3:50 pm

I created dual WAN (with PCC) configuration on my Mikrotik according to instructions:
https://wiki.mikrotik.com/wiki/Manual:PCC

Now I’m trying to run VPN (https://grzegorzkowalik.com/mikrotik-od . -ipsec-07/) with IPsec but I have error

Re: VPN IPsec — phase1 negotiation failed due to send error

Thu Mar 04, 2021 2:18 pm

So the Mikrotik with the PCC configuration acts as an L2TP server, is that correct?

Can you post the complete export of your configuration, after a «non-destructive anonymisation» as suggested in my automatic signature below?

Re: VPN IPsec — phase1 negotiation failed due to send error

Thu Mar 04, 2021 3:13 pm

Re: VPN IPsec — phase1 negotiation failed due to send error

Thu Mar 04, 2021 4:35 pm

The whole problem is that the use of policy routing for packets generated by the router itself is a bit counter-intuitive.

When some process running on the router itself sends a packet, the first step is to find a route for that packet using routing table main, which consists of routes with no routing-mark assigned. Then, a source address is assigned to that packet, according to the properties of that route (the local address indicated in the pref-src parameter or, if no pref-src is specified, the local address associated to the output interface), unless the packet is a response. And only after successful completion of these two steps, the packet is processed by mangle rules in chain output. If the mangle rules eventually assign a routing-mark, the packet is routed once again, taking the routing-mark value into account (but not changing the source address of the packet). This step is called «routing adjustment» at the packet flow diagram.

Since you weren’t aware of this, you haven’t configured any default route in the routing table main, hence the first round of routing of the response IKE packets sent by the router itself to the address of the L2TP client device fails as no route is available for their destination address.

Routes to connected subnets (XX.XX.19.152/29, XX.XX.16.24/29, 192.168.0.0/24) are added to routing table main dynamically, which explains why the L2TP/IPsec sessions establishes fine when the client is in your LAN subnet.

So for the incoming connections through WAN, the remedy is simple, add a default route pointing to any gateway. You can create a bridge interface with no ports, which will thus stay up no matter what, and use the interface name as the gateway parameter of that route if you don’t want to make one of the two WAN gateways a default one in routing table main.

Источник

Phase 1 negotiation failed due to send error mikrotik

Tue Apr 02, 2019 12:13 pm

The RB4011 is behind a router with Port-Forwarding. This seems to work, but i think something with the packet handling is failing. On Client side ive tried with different devices, everytime the same error. On Mikrotik i am using a NAT for all outgoing traffic to the internet router. So the actual Internet IP of the packet is different than the internal. This could cause the client to invalidate the connection due different IP encryption or something like this.

I hope anybody has an idea how to solve this?

Re: L2TP/IPSec — phase 1 negotiation failed due to send error

Tue Apr 02, 2019 1:57 pm

Re: L2TP/IPSec — phase 1 negotiation failed due to send error

Tue Apr 02, 2019 2:26 pm

Re: L2TP/IPSec — phase 1 negotiation failed due to send error

Tue Apr 02, 2019 4:55 pm

Re: L2TP/IPSec — phase 1 negotiation failed due to send error

Wed Apr 03, 2019 10:48 am

Re: L2TP/IPSec — phase 1 negotiation failed due to send error

Sat Apr 06, 2019 8:20 pm

Well, «only the default routing table» and «they are configured to use for the same connection always the same WAN interface» don’t fit well to the same paragraph The default routing table is the one called «main», and a routing-mark is essentialy a synonym to a routing table name, except that no routing-mark assigned means «use the routing table called ‘main’, i.e. the default one».

But that’s not the merit. The merit is that your mangle rules in chains input and output do ensure that what came in via one of the WANs will be responded via the same WAN, and that the other rules in chain prerouting do not break this. So up to the routing-mark assignment, we are fine here. What you haven’t shown, though, are the actual marked routes, can you please show your /ip route export ? Since your load balancing works, I assume this part is fine too, but better double-check.

I’m not sure I understand the part you wrote about NAT. If you had in mind that you do some NAT on Mikrotik itself, the rules you’ve shown say this is not the case for output packets of ROS itself. So I assume you had in mind that the Fritz!box NATs the Mikrotik’s source address 192.168.55.1 to its own WAN address (and vice versa in internet->Mikrotik direction).

And now yes, at least the Windows embedded VPN client does not handle well a NAT on the IPsec responder («server») side. I’m not sure how about other (iOS, Android) embedded clients; the NAT-T mechanism itself does handle both initiator-side NAT and responder-side NAT, so a Mikrotik as an IPsec initiator («client») can handle that fine. In some versions of Windows you can tweak the registry settings to make the embedded client accept responder-side NAT, but I think it is better not to depend on this.

So what you need to do is to use an «un-NAT» on Mikrotik side: you create an /interface bridge on the Mikrotik, not assign any member interfaces to it, and assign the public IP address of the Fritz to it (with a /32 mask). Then you tell the /ip ipsec peer used by the L2TP server to use that address by setting its local-address parameter. Next, you add a chain=dstnat action=dst-nat protocol=udp dst-port=500,4500 to-addresses=the.public.ip.of.Fritz to the nat table, so that incoming connections to the IPsec UDP ports would be redirected to that public address. So the initiator will see the same address (the public one of the Fritz!box) as both the source of the responder’s traffic and the responder’s actual address in the NAT-T payload.

This way, except a minor brain damage which heals quickly, the only trouble will be with the clients running on public IP addresses themselves if the Fritz!box is unable to forward and NAT the ESP. The NAT-T mechanism switches over to encapsulation of ESP into UDP only if it detects NAT on at least one end of the connection, so if it doesn’t detect it on the responder side (which was our goal) nor on the client side, it won’t activate the ESP over UDP mode. So if you expect to have clients on public IPs, you have to make sure that the Fritz!box delivers ESP packets to the 4011 and to add another chain=dstnat rule which is the same like the one above except that you replace protocol=udp dst-port=500,4500 by protocol=esp .

Another stage of the quest is that the L2TP server normally auto-creates its own /ip ipsec peer and you cannot instruct it what parameters to use for that, except the secret . So to be able to set the local-address the way you need, you have to clone the auto-created peer (using /ip ipsec peer add copy-from=[find where dynamic and secret=your-secret] or something similar), and then do /interface l2tp-server server set use-ipsec=no to remove the dynamically created peer.

Источник

Как настроить L2TP/IPSec VPN на Mikrotik?

Пытаюсь поднять на Mikrotik RB951G-2HnD VPN тунель L2TP/IPSec, что бы подключаться с помощью iPhone 4.
Но не чего не получается.
Соединение отваливается вот на этом.
Jun/04/2015 21:49:54 ipsec,error phase1 negotiation failed due to time up «Мой внешний статический IP адрес»[500] «Произвольный IP адрес с устройства которым пытаюсь подключится»[1197] 86dd3e3d2affc4f8:67c23982425b761b
Время на роутере и на iPhone одинаковое. В статистике IPSec Peer Connected видно что есть какое то соединение, т.е. на мой внешний адрес с другого адреса(мегафон 3G). Пароли на L2TP и на IPSec сделал простые, что бы проверить. В правилах Firewall пакеты бегают на правиле где 500 порт UDP. Пакеты на правиле с UDP 1701 и 4500, и ipsec-esp не бегают, по нулям.

Где может быть проблема и куда копать? Всё делал по гайдам и вики, и ни как не удаётся добиться положительного результата 🙁

Вопрос задан более трёх лет назад
33901 просмотр

У вас так?
/ip ipsec proposal
set default enc-algorithms=aes-128-cbc,aes-256-cbc lifetime=8h \
pfs-group=none

Покажите остальные настройки.

TNT: Итак, коллега, вот что я сделал чтобы мой айфон4 на 8 ios подключился к MK L2TP + IPSec через NAT
1. Разрешаем входящий трафф для портов 500, 1701, 4500 UDP. Так же разрешаем исходящий наружу
2. Настраиваем профиль L2TP копируя стандартный default-encryption и внося единственное изменение в шифрование трафика = Yes (в остальном всё штатно как и для других устройств)
3. Включаем L2TP сервер ставя галку IPSec — Peer для входящих подключений создастся автоматом
4. В IPSec Proposal вносим изменения добивая недостающие галки до состояния
auth-algorithms=md5,sha1,sha256,sha512 enc-algorithms=null,des,3des,aes-128-cbc,aes-256-cbc
5. Политики туннелей и темплейтов я не трогал, всё заработало на дефолтных.

Тестировал при подключении через интернет из под моего домашнего вайфая за NAT всё работало без проблем, а вот через Мегафон подключатся не захотело никак (возможно мой тариф или что-то ещё блокирует l2tp) и не только с айфона

Спасибо всем за помощь. Проблема — банальна. Мегафон 3G рубит VPN, думаю рубит L2TP 1701 порт. Так как рабочий VPN чисто Cisco IPsec работает нормально.
С другой сети, получилось выйти через iPhone нормально.

UPDATE: Проблема даже не в мегафоне, а в кривых настройках Firewall. У меня было 4 правила, отдельных правила. Т.е. 500 UDP; 1701 UDP; 4500UDP; и 50 (ipsec-esp). А объединил все три UPD правила в одно, 500,1701,4500 и всё заработало. И на 3G тоже 🙂

Появился следующий вопрос, может поможете пожалуйста:
Через VPN подключение не вижу локальные ресурсы.
192.168.1.1 — это шлюз Mikrotik и DNS.
192.168.1.100 — это выдается IP адрес устройству которое подключается по VPN. Т.е. iPhone.
192.168.1.254 — хз для чего нужно указывать Local Address. Указал свободный. (Так же указывал и 192.168.1.1)
В локальной сетки есть девайсы 192.168.1.3 и 192.168.1.4
Вот с микротика через терминал пинги идут, а с iPhone когда он подключен по VPN пингов нету и веб интерфейс устройства не открывается. Хотя, шлюз 192.168.1.1 пингуется и инет работает, например yandex.ru.
Что нужно сделать, что бы локальные ресурсы были видны? arp-proxy делал как на LAN1(master) так и на bridge-local. Не помогает. Хотя подсеть одна же.

Источник