Failed to get valid proposal android

Mikrotik L2TP/IPSec за NAT: ipsec,error failed to pre-process ph2 packet

При использовании Mikrotik за NAT (в частности за всякими USB GSM модемами) в режиме клиента L2TP/IPSec, у некоторых операторов в определенных режимах, получал проблему с ошибкой ipsec,error failed to pre-process ph2 packet.
Но с появлением RoS 6.38 появилась возможность справиться с ошибкой.

Итак, ошибка появляется в обычной конфигурации клиента L2TP как на картинке:

Основная проблема в том, что политика IPSec, применяемая в такой настройке, прибита гвозьдями и использует ike1. Ike1 в свою очередь, в реализации RoS, имеет проблему при прохождении NAT без проброса портов и как отягчающие обстоятельство: множественные туннели с l2tp тоже не проходят из-а одного NAT (а количество клиентов на модеме огромное).
Решить проблему можно при использование IKE2 (а для кучи клиентов за одним NAT нужно отказаться от авторизации PSK в пользу RSA Signature), который невозможно настроить из меню выше, но можно сделать трюк: заходим в меню IP -> IPSec

Копируем динамически создаваемый пир, и меняем в нем настройки как показано ниже:

А именно меняем Exchange Mode на IKE2, в закладке Encryption настраиваем необходимые параметры шифрования.

Осталось отключить в настройках L2TP/IPSec использование IPSec.

Вот собственно и все, соединение поднимается, шифрование работает.

Источник

Failed to get valid proposal android

Tue Jul 11, 2017 9:54 am

I’m running an L2TP/IPSec VPN, and see different IP’s try to connect in my log.

respond new phase 1 (Identity Protection): Mikrotik_IP[500] x.x.x.x[12345]
x.x.x.x failed to get valid proposal.
x.x.x.x failed to pre-process ph1 packet (side: 1, status 1).
x.x.x.x phase1 negotiation failed.

I do have a filter rule that add’s all IP’s to a list connecting to poort 500 and 4500, but the above connection attempt is not added to the list.

the only thing I could think of was to parse the log and search for the error message, but this seems like unnecessary load on the router.

How do I add the failed connection attempt IP address to a blocklist without parsing the log every minute?

Re: Block VPN connection when failed to get valid proposal

Tue Jul 11, 2017 10:12 am

Re: Block VPN connection when failed to get valid proposal

Tue Jul 11, 2017 10:04 pm

Re: Block VPN connection when failed to get valid proposal

Tue Jul 11, 2017 10:52 pm

True, but the tries come from a specific range 1.2.3.x so I can identify it that way.

I’m still thinking of another way, without port knocking or parsing. will be continued

Re: Block VPN connection when failed to get valid proposal

Wed Jul 12, 2017 7:48 pm

Re: Block VPN connection when failed to get valid proposal

Sun Jul 30, 2017 3:07 am

Re: Block VPN connection when failed to get valid proposal

Thu Aug 03, 2017 12:59 pm

It seems they connect from a range of Ipaddresses like 1.2.3.X so I’ve added a rule to drop all connections on UDP ports 500 and 4500 from 1.2.3.0/24

Also added a Knock on door rule. It works like this; When you connect on the publicIP on a specific port e.g. 12345. Your IP is added to an address list for 10 seconds. If you connect again on port 54321 within does 10 seconds and your ip is on list 1, you’ll be added to list 2. Only list 2 is allowed to connect to ports 500 and 4500.

Re: Block VPN connection when failed to get valid proposal

Fri Aug 04, 2017 12:20 am

It seems they connect from a range of Ipaddresses like 1.2.3.X so I’ve added a rule to drop all connections on UDP ports 500 and 4500 from 1.2.3.0/24

Also added a Knock on door rule. It works like this; When you connect on the publicIP on a specific port e.g. 12345. Your IP is added to an address list for 10 seconds. If you connect again on port 54321 within does 10 seconds and your ip is on list 1, you’ll be added to list 2. Only list 2 is allowed to connect to ports 500 and 4500.

Many thanks for your answer KitMikro, I will try to apply this type of rule in my Router.

Re: Block VPN connection when failed to get valid proposal

Fri Aug 04, 2017 5:16 pm

It seems they connect from a range of Ipaddresses like 1.2.3.X so I’ve added a rule to drop all connections on UDP ports 500 and 4500 from 1.2.3.0/24

Also added a Knock on door rule. It works like this; When you connect on the publicIP on a specific port e.g. 12345. Your IP is added to an address list for 10 seconds. If you connect again on port 54321 within does 10 seconds and your ip is on list 1, you’ll be added to list 2. Only list 2 is allowed to connect to ports 500 and 4500.

Many thanks for your answer KitMikro, I will try to apply this type of rule in my Router.

your welcome! If you want to, you can use layer 7 to include some sort of password. If your on a Mac or other Linux based OS you can send a «Knock on door», with the following command

notice, I’m sending the request to an UDP port, not TCP.

Источник

Failed to get valid proposal android

Fri Mar 29, 2019 11:31 am

Two days ago I configured 4 x GRE / IPSec tunnels on my CCR running 6.42.12. I use this exact same configuration elsewhere successfully on a CCR running 6.42.6. All 4 tunnels were up and stable and BGP neighbours connected and exchanging routes as expected.

Yesterday morning I noticed that the one tunnel is down. Log indicate ph2 cannot establish and the log is flooded with “ipsec failed to pre-process ph2 packet”. The policy for the tunnel was marked in red (I recall this was usually an indication that the policy was invalid).

Anyways I went through the process of clearing all SAs, enabling and disabling the peer, the policy, the associated addresses etc. multiple times without the ph2 re-establishing. Resetting the tunnel from the far end also had no effect. I deleted the peer and policy and recreated with the exact same result. I double checked all configs making 100% sure there were no overlapping subnets but I could not find any issue. None of the other 3 tunnels showed the same behavior.

At some stage I left the policy disabled for quite a while (guessing > 30 mins). After enabling it, to my surprise, the ph2 established. I was just wondering if this is perhaps know behavior that was introduced somewhere between 6.42.6 and 6.42.12? Or any other thoughts?

It still seems stable ever since.

Re: IPSec failed to pre-process ph2 packet

Fri Mar 29, 2019 2:35 pm

I’ve been seeing this (apparent data corruption in IPSec packets when changing configuration) on my home ac2.

It’s fixed in 6.43 or 6.44 — can’t remember exactly — but it was mentioned in change logs.

Re: IPSec failed to pre-process ph2 packet

Tue Apr 02, 2019 10:19 am

Re: IPSec failed to pre-process ph2 packet

Mon Apr 08, 2019 2:00 pm

Does anyone here perhaps have any specific information on why the ph2 policies would out of the blue go into an invalid state? This happens randomly and I cannot reproduce on demand so trying to roll forward version by version is going take forever.

Like I mentioned before, disabling the policy for an extended amount of time and then enabling it seems to resolve the problem. The problem is not on the device at the far end as I have other routers terminating tunnels with the same configuration on the same device that never show this behavior.

Re: IPSec failed to pre-process ph2 packet

Sat Apr 13, 2019 7:48 pm

As removing and re-creating the peers and policies didn’t help while «letting everything cool down for a while» did, I’d suspect some connection tracking issue somewhere, possibly in the network between the two devices, where an existing connection had to time out and disappear from the connection tracking tables in order to allow the peers to establish communication again. However, respond new phase 1 (Identity Protection) followed by no suitable proposal found suggest something more complex, like multiple local side peers being configured, with different Phase 1 proposals (aka peer profiles), and the wrong one to be hit by the incoming packet.

If you want a more detailed response, follow the hint in my automatic signature, configurations from both ends are necessary.

The phase 2 issue existed only for IKEv2 and it only happened once in many renegotiations while both ends showed everything to be just fine except that the data did not get through because the encryption keys differed between the ends. So I think your case is completely unrelated to that issue (and I don’t remember in which version it has been fixed a year ago or so although it was me who has reported it).

Re: IPSec failed to pre-process ph2 packet

Tue Apr 16, 2019 9:23 am

Thank you for your response.

I have another Mikrotik router in another location that terminates GRE/IPSec tunnels on the exact same device on the far end (VyOS running StrongSwan) and I have never seen this behavior. As a test I downgraded the ROS version of the «problematic» router to 6.42.6. 3 days in the issue occurred again — one policy marked as invalid. Without any intervention, 6 hours later it recovered. I think you are correct that it might be due to connection tracking somewhere. The strange thing is that the far end indicates ph1 and ph2 up. Resetting the tunnels from the far side has not effect. The only thing that I can thing of that is different is that the connection over which the policies change to invalid states, is via a PPPoE internet connection. In other locations where this configurations successfully used, the internet connections are direct fibre connections. What are your thoughts on this? One thing I have not tried yet is actually disabling and re-enabling the PPPoE client session to see if that makes a difference (previously I just tried to remove the relevant UDP 500 and ESP connections from connection tracking). Btw, connection tracking on my Mikrotik routers are configured as «auto».

One other thing that you have mentioned are the proposals. Even though all the IPSec tunnels on the router in question are configured to use the same proposal (add enc-algorithms=aes-128-cbc lifetime=1h name=vpn-core) there is another policy (the default one) used for inbound L2TP over IPSec connections from remote users (find default=yes ] enc-algorithms=aes-256-cbc pfs-group=modp2048) . If this policy is somehow used, then I can understand that there will be an issue but I cannot see how that would happen?

Again, you views would be greatly appreciated.

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 10:33 am

When I checked this morning, one policy marked as invalid once more.

• Enabling and disabling the PPPOE had not effect.

• Changing the crypto to the same settings as the ones used in the default policy had not effect.

The device on the far side indicated both ph1 and ph2 up. Bizarrely even though the policy on the Mikrotik is marked as invalid and clearly indicated as not established, the GRE interface is in a running state and the BGP neighbor connected. So this seems to me that even tough the policy is marked as invalid in the UI as well as the terminal, somewhere, somehow a valid policy is still installed. When I enable and disable the peer, the ph1 reestablished immediately but ph2 does not reestablish and obviously the BGP neighbor now looses comms as the GRE is not in a running state. No matter what I do, I cannot force the policy into a valid state again — after x hours, it just magically recovers. Diagnostic logs indicate: ipsec,debug no policy found for id:11473.

I quite urgently need to get this resolved — again, any assistance would be greatly appreciated.

Below the invalid policy with traffic flowing correctly as if the tunnel is working 100% (prior to resetting the peer):

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 11:44 am

What makes my brain slide a bit is that you use the IP address attached to the GRE interface also as a local address to send the GRE transport packets from. Could you, just for testing, create an /interface bridge without any member ports and attach to it the IP address which is used as local-address of /interface gre (and thus the src-address of the /ip ipsec policy ) and use a different address for the GRE interface itself (I don’t mind which one of the two will remain the current one and for which purpose you’ll use a new one)? I have no idea how this would be done at VyOS side but it should be possible as well.

Also, I’m nor sure why you’ve assigned a /32 address to one GRE tunnel and a /30 address to another one.

As you seem not to mind publishing your public IP addresses, can you post the log which says «no policy found»? There should be more information in the log than just this.

Please show me also the output of /ip ipsec policy print and /ip ipsec installed-sa print when it runs but the policy is marked as inactive. The encryption and authentication keys shown in the installed-sa printouts are temporary ones so no need to edit them out, it is enough to wait up to 30 minutes before posting them.

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 12:53 pm

Once more thank you for the reply. Below the output of the peer and sa status. I have also attached the log, obfuscated the IPs as per the config provided and marked non-relevant IPs as x.x.x.x.

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 1:39 pm

First of all, all occurrences of ipsec policy not found in the log you’ve sent are preceded by a message ipsec searching for policy for selector: 169.254.200.49 ip-proto:47 169.254.200.50 ip-proto:47 which doesn’t match the parameters of the /ip ipsec policy you’ve shown in the quotation from your config in post #6 ( dst-address=169.254.200.66/32 src-address=169.254.200.65/32 ). Post #9 shows the policy matching the log, not the configuration. Is this because you’ve split the IPs as I’ve asked you before?

Second, showing just parts of the configuration and status outputs breaks the purpose, my intention was to check the existing policies (including dynamically created ones) for shadowing each other, which you’ve ruined by showing just the single policy and SA. So please post the complete printout as requested — as text, not as screenshot. You can always direct the output of a print to a file by adding file=some-name , download the file and edit it before posting to hide the IPs, but such editing has to preserve consistency — the same IP address must be substituted by the same replacement string in the whole file, and the traffic selector addresses of the policies ( src-address and dst-address ) must remain completely unchanged to show the eventual shadowing of policies by preceding ones.

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 4:35 pm

Hi, on your first question — no, as you can see in post #7, (dst-address=169.254.200.66/32 src-address=169.254.200.65/32) is another policy used by another tunnel. This tunnel also shows the same sporadic behaviour. The config for it was supplied in this thread as use the problematic tunnel as an example when the policies go into an invalid state — I cannot predict when this happens and I supplied the information that was available to me at the time.

I have subsequently moved the source address of the GRE tunnel to a bridge interface as per your suggestion.

My apologies that the configs were not supplied to your satisfaction. I have added it below as per your request. I have also substituted all the public addresses consistently.

Re: IPSec failed to pre-process ph2 packet

Wed Apr 17, 2019 6:36 pm

My personal opinion is that has nothing to do with configuration. None of your other policies can shadow the one mysteriously going inactive, even if we’d admit that the order of the policies wouldn’t matter. It normally does but when you add a new policy this used to fail in older ROS releases, e.g. on the 6.43.8 where I’ve just tested it.

So it is either a bug or, if the other Routerboard/CHR /x86 on which you’ve never seen the issue to happen is the same model like the problematic one, there can be a hardware (RAM) issue on the problematic one.

So you may try the following steps and hope that one of them works around the bug (the last one may «fix» rather than «workaround» it although none of the changelog items listed below is guaranteed to be related):

• separate the addresses used to send for the GRE transport (to be matched by the IPsec policy) from the addresses attached to the GRE interface, at least on Mikrotik side, the way I’ve suggested above; doing so will allow you to remove the protocol=gre from the traffic selector of the /ip ipsec policy
• set the sa-src-address of the policy to 0.0.0.0 . It may make things better (the policy won’t jump inactive) or worse (it won’t ever come up), the idea is just to force a different branch of the algorithm, not something precisely targeted to a known issue
• set the level to unique instead of the current require — same motivation like above
• upgrade to 6.43.12 (the last available one before 6.44 — to keep the structure of IPsec configuration you are used to)

The following items in the changelog may be related:

• 6.42.7: *) ipsec — improved invalid policy handling when a valid policy is uninstalled;
• 6.43:
  • *) ike2 — fixed initiator first policy selection;
  • *) ipsec — improved invalid policy handling when a valid policy is uninstalled;
  • *) ipsec — improved reliability on generated policy addition when IKEv1 or IKEv2 used;

The «improved invalid policy handling when a valid policy is uninstalled» is mentioned also in 6.44 changelog, so it seems to be a complex issue.

Источник