First l2tp udp packet received from mikrotik что это

Fri Nov 01, 2019 10:02 pm

I have a problem and it’s driving me crazy.
I can’t connect linux and win10 clients with my basic L2TP+IpSeC VPN
android and windows 7 clients connect without problems
I was looking for a lot but I can’t make it work
double check the configuration
just in case, update to the latest version of routerOS

Here’s the config:

Mikrotik

Linux client config

Config NetworkManager:

Name: vpn
Gateway: x.x.x.x
User name: User1
Password: Password1

[*]Enable Ipsec tunnel to L2TP host
General:
Pre-shared key: xxxxxx
Advanced:
Phase 1 Algorithms: 3des-sha1-modp1024
Phase 2 Algorithms: 3des-sha1

The connection fails in phase 2

Thanks in advance.
Nicolas.

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Sat Nov 02, 2019 10:55 pm

Is your MikroTik router behind NAT or you have PPPoE client configured? In simple words, does your MikroTik router have a public IP ?

Are ports UDP 500, 4500, 1701 accepted in firewall ?

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Mon Nov 04, 2019 3:38 pm

Thanx for the reply!

and yes, I have a public ip and the rules allowed in the firewall

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Mon Nov 04, 2019 3:48 pm

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Wed Nov 06, 2019 3:36 pm

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Wed Nov 06, 2019 4:00 pm

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Wed Nov 06, 2019 5:15 pm

nop
why do you think the problem is the ipsec encryption algorithm?
in the case where the log show something it is with the android client but it works

In cases that do not connect, the l2tp does not start

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Thu Nov 07, 2019 11:40 pm

Because the log says that the encryption algorithm available at responder (Tik) side doesn’t match the one available at initiator (Win10) side:

10:46:08 ipsec trns_id mismatched: my:3DES peer:AES-CBC

Which is imposed by this setting (as it appears in the export, it is a non-default one):
/ip ipsec proposal
set [ find default=yes ] enc-algorithm=3des

So to make it work, add aes-cbc-128, aes-cbc-256 to the enc-algorithm list.

Each of the clients you’ve listed has a different set of supported encryption algorithms. 3DES is not considered a secure encryption method any more, so while Win7 embedded VPN client still supports it, the Win10 one doesn’t. The good news is that both Android and Win7 can use aes-cbc as well so there is no need to permit 3DES at the Tik. Always use the most advanced algorithm supported by all your devices and disable all the weaker ones; if the most advanced algorithm supported by some device is 3DES, it’s time to replace that device or not use it as a VPN client.

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN

Fri Nov 08, 2019 3:20 pm

Re: Problem with Linux and win10 roadwarriors L2TP+IPSeC VPN [SOLVED]

Fri Nov 08, 2019 4:46 pm

OK. Now your log shows the following:

09:48:20 ipsec IPsec-SA established: ESP/Transport X.X.X.X[500]->Y.Y.Y.Y[500] spi=0x2ce69f9
09:48:20 ipsec IPsec-SA established: ESP/Transport Y.Y.Y.Y[500]->X.X.X.X[500] spi=0x6633617e
. 35 seconds silence .
09:48:55 ipsec purged IPsec-SA proto_id=ESP spi=0x6633617e
09:48:55 ipsec purged IPsec-SA proto_id=ESP spi=0x2ce69f9

Hence establishment of the IPsec layer has been successful but a) either the L2TP didn’t negotiate properly or b) it was unable to negotiate properly because the communication did not get through.

So a bit of theory: if there is no NAT between the IPsec peers, the control communication between them uses UDP port 500 at both peers, and the actual payload is transported using a dedicated protocol called ESP (or another one called AH, doesn’t matter here). But ESP doesn’t have the notion of a «port», hence it cannot be NATed. So while establishing the control connection, the peers check for presence of NAT at both ends and if detected at either (or both), they switch over to using port UDP 4500 for both the control communication and the transport — in this mode, the ESP is encapsulated into UDP prior to sending, and the control (IKE) packets are distinguished from the transport (ESP) packets coming in the same UDP flow by means of a distinictive field at the beginning of the UDP’s payload.

Why I mention this is that when you look at log from the working case (Android), you can see that the log shows that this NAT-traversal mode has been chosen:
10:13:43 ipsec IPsec-SA established: ESP/Transport X.X.X.X[32774]->Y.Y.Y.Y[4500] spi=0x8718e8c
10:13:43 ipsec IPsec-SA established: ESP/Transport Y.Y.Y.Y[4500]->X.X.X.X[32774] spi=0xaaf563c

In the same log, you can also see 10:13:44 l2tp,info first L2TP UDP packet received from X.X.X.X , which suggests that L2TP events are being logged. Since an equivalent message is missing in the log from Windows after augmenting the encryption-algorithm list, I conclude that variant b) above is the reason why it doesn’t work. And the root cause is that the ESP packets are only sent if they have a payload to carry, so the Tik acting as L2TP server does not send them until it needs to transport a response to a received L2TP initial packet, and thus it does not drill a pinhole for the ESP packets coming from the remote peer in its firewall.

So check your /ip firewall filter rules in chain=input , and right before the rule permitting incoming connections to UDP ports 500 and 4500, add another rule permitting incoming connections using protocol ESP:
/ip firewall filter add chain=input protocol=ipsec-esp action=accept place-before=[find chain=input dst-port

Источник

First l2tp udp packet received from mikrotik что это

Thu Apr 11, 2019 7:45 pm

Having a weird issue with L2TP VPN I built on one of my mikrotiks and I’m not sure how to troubleshoot the issue.

VPN server — CCR
VPN Client — Another CCR at a remote locatoin.

The VPN works. I can connect to the VPN server via the client mikrotik, as well as a windows machine.

However, when the client mikortik tries to VPN into the server mikrotik, I get

On the client

12:37:17 ipsec,debug pfkey add sent

On the server (IP removed by me)

12:37:53 l2tp,info first L2TP UDP packet received from XXX.XXX.XXX.XXX

And this just repeats over and over for about 5 minutes until it eventually connects.

Any ideas? It’s super aggravating, as the client side has a crummy ISP that microdrops, causing them to be unable to reach the server at HQ for 5-10 minutes while the MIkrotiks settle their argument.

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 7:53 pm

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 8:00 pm

Makes sense. I have about a dozen clients with the same VPN setup, but only this one has issues. The other clients are using fiber at all their locations, this one uses crummy copper wire megacorp cable.

Guess I’ll need to experiment with setting up an SSTP! I use PSK (I really need to use certs) currently.

I should know this, but SSTP, secure socket tunneling protocol, if it doesn’t use certs, how do they authenticate? Hopefully not use a username/password right?

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 9:04 pm

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 9:22 pm

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 10:40 pm

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 11:20 pm

Yup, that will also work as OpenVPN on MT is TCP Based.

I just prefer SSTP over O-VPN as SSTP uses port 443, less chance of ISP’s blocking it.

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Thu Apr 11, 2019 11:29 pm

I really appreciate you taking time out of your day!

Honestly, I don’t know how to set up SSTP, but with OVPN working I have a critical ticket out of my way to dedicate time to figure it out.

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Sat Apr 13, 2019 6:20 pm

Sorry for dragging some clouds to the clear sky, but VPNs using TCP as transport can cause more pain than help on lossy networks. The point is that if the payload protocol is also TCP, both the TCP layers do the retransmission — google for «TCP meltdown» for details. So in short-term you may have won, but in long-term you may encounter some hard to explain issues. Also for VoIP and other applications where loss of a packet now and then is less important than the delay caused by TCP retransmission, no VPN using TCP as transport is a good choice.

When the VPN transport doesn’t take care of the lost packets (like those using UDP, ESP, GRE as transport), it doesn’t interfere with the loss handling strategies of the payload applications.

So I’d rather get rid of the L2TP layer with its own negotiation and timeouts, and stick with IPsec alone or use IPsec to encrypt GRE which has no own negotiation. The easiest way to run another IPsec peer on the same address and port like the one used for encryption of L2TP is to use exchange-mode=ike2 , which should also improve security a bit as compared to use of the IKE (v1).

Re: L2TP VPN «L2TP UDP packet received from» over and over again. [SOLVED]

Sun May 12, 2019 5:39 am

For people of the future googling this issue.

There is not fix if you want to do L2TP, none that I found anyway. L2TP is great for users (laptops/remote desktops) needing to VPN, but not super solid for a site-to-site.

I ended up getting an OVPN (native to Mikrotiks, both server and client) setup with certificates, and the VPN connection between my two locations has an uptime of over two weeks.

So, your solution for a Site-to-Site VPN using two Mikrotiks is to use PPTP (fast, stable, not secure) or OVPN (fast, stable, secure) instead of L2TP (slowest option, not stable, super secure)

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Sun May 12, 2019 8:56 am

For people of the future googling this issue.

There is not fix if you want to do L2TP, none that I found anyway. L2TP is great for users (laptops/remote desktops) needing to VPN, but not super solid for a site-to-site.

I ended up getting an OVPN (native to Mikrotiks, both server and client) setup with certificates, and the VPN connection between my two locations has an uptime of over two weeks.

So, your solution for a Site-to-Site VPN using two Mikrotiks is to use PPTP (fast, stable, not secure) or OVPN (fast, stable, secure) instead of L2TP (slowest option, not stable, super secure)

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Sun May 12, 2019 11:30 am

It depends on what you call solidness and what are your requirements and network quality. L2TP sends an LCP EchoReq packet every 30 seconds and expects an EchoRep to come; if it doesn’t, it takes 4 more attempts 1 second apart and if it still doesn’t receive a response, it tears down the tunnel (and the client starts connecting again, which is seen as the L2TP UDP packet received from . message on the server). So if the loss rate of the connectivity between your sites can be very high for 6 consecutive seconds in at least one direction and the LCP EchoReq campaingn hits that very interval, this happens with L2TP, whereas with a VPN Protocol which uses TCP as transport (such as OpenVPN or SSTP) or which is not so sensitive about transport network quality (such as, probably, PPTP although I haven’t analysed its availability checking methods and their timeouts) may seem «solid» on the same quality of link. I’m not saying that TCP has no issues with a 6 seconds of total stop of transmission, I’m just saying that as the VPN uses TCP, it may not bother checking whether the other end is alive when it has no payload to send, relying on TCP to find out, and that if it is not a total stop but just a high loss rate (which can be caused by mere overload of the link), TCP may keep the connection up due to variable timeout between retransmissions.

So «solid» as in «I don’t panic if I cannot hear from the other end for quite a while» and «solid» as in «I constantly monitor the availability of the remote end and take measures to re-establish the connection if something went wrong» are different understandings of the word. On reliable enough transport network, no one cares about the meaning of «solid»; when the transport network randomly stops delivering packets for seconds, the difference becomes essential.

That said I have to return to my previous statement — use of TCP for tunneling another TCP causes little harm where the drop rate is low, but in such cases, UDP, ESP, or GRE as VPN transports also have no problems. Where drop rate is high, TCP over TCP causes a headache and may not be enough to save the situation.

So if your transport network is that bad but you have no other option, you have to experiment with various VPN types and find out which one suits your particular situation and needs best. Of course, any real-time transmission (such as VoIP) on a network that bad is something not to even dream of. But your network may actually not be that bad, it may just be that some of your traffic exhausts the available bandwidth of your last mile link because there is no QoS handling used.

Re: L2TP VPN «L2TP UDP packet received from» over and over again.

Sun May 12, 2019 5:20 pm

This is a very informative answer that I will reference for the future.

The client side is located in a mall with a crummy ISP, but the only one that isn’t DSL. They’re not running VoIP, but they RDP into a Terminal server at the main site (maybe 3 miles away). I don’t like open RDP’s, and I was limited on software solutions due to client budget. So my compromise was to use their existing mikrotiks to establish a VPN so they can RDP via the TS’s local IP.

However, the client site has micro-outages with their ISP. Only for a few seconds, and it might be every 2 minutes, or every 2 hours. Long enough to break the L2TP tunnel, and they were down (unable to make sales) for about 2-3 minutes while the Mikrotik tried to rebuild the tunnel.

Both sides use a CCR. OVPN seems to be MUCH for fault tolerant.

Источник