Mikrotik vpn l2tp ipsec android

Бесплатный чек-лист
по настройке RouterOS
на 28 пунктов

L2TP/IPsec между mikrotik и Android/IOS

У меня работает. Вы видимо не правильный алгоритм шифрования указали. Телефон и рутер не могут пройти к согласию. У меня шифрование aes-265, а хэш считается через sha1. Там в логе поглядите, рутер пишет, что ему предлагает телефон и что у него есть.

Привет.
Вот моя конфига. Работает нормально android, windows.
Есть wan интерфейс на нём белый IP.
Есть local интерфейс 192.168.1.1
VPN L2TP IPSEC
/interface l2tp-server server set default-profile=default enabled=yes

/ip pool add name=l2tp_pool ranges=192.168.1.150-192.168.1.200

/ppp profile add name=l2tp change-tcp-mss=yes local-address=192.168.1.1 only-one=default remote-address=l2tp_pool use-compression=default use-encryption=yes use-mpls=default use-vj-compression=default

/ppp secret add name=user1 password=P@ssw0rd service=l2tp profile=l2tp

/ip ipsec peer add address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret=»SecretKey» exchange-mode=main-l2tp send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 generate-policy=port-override lifetime=»1d 00:00:00″ dpd-interval=120 dpd-maximum-failures=5
ip ipsec proposal set default auth-algorithms=sha1 enc-algorithms=3des,aes-256 lifetime=30m pfs-group=modp1024

/interface ethernet set local arp=proxy-arp

Источник

shaposhnikoff / gist:70bd00800546ed43cb2df1d7ceb20805

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

Title: Настройка сервера VPN L2TP/IPSec на Mikrotik RoutersOS

Date: 2013-05-31 17:25

Category: Mikrotik

Tags: mikrotik, vpn

Slug: mikrotik-lt2p-vpn

Summary: Краткое описание настройки сервера VPN L2TP/IPSec на Mikrotik RoutersOS c возможностью подключения с помощью встроенных VPN клиентов Windows 7, Mac OS X и IOS.

![Alt Text](|filename|/images/l2tp-ipsec_vpn_server.png)

**Замечение:** Если несколько клиентов находятся за NAT, то только одно L2TP/IPSec соединение может быть установлено.

## Базовая настройка

«`

/ip address

add address=91.219.55.10/24 interface=ether1

add address=10.20.0.1/24 interface=ether2

/ip route

add gateway=91.219.55.1

/ip firewall nat

add chain=srcnat action=masquerade out-interface=ether1

/ip dns

set allow-remote-requests=yes servers=91.219.55.1,8.8.8.8

/ip pool

add name=lan_dhcp ranges=10.20.0.100-10.20.0.199

/ip dhcp-server

add name=lan_dhcp address-pool=lan_dhcp interface=ether2 disabled=no

/ip dhcp-server network

add address=10.20.0.0/24 dns-server=10.20.0.1 gateway=10.20.0.1

«`

## Настройка L2TP

Создадим еще один пул IP адресов из той-же подсети, который будет использоваться для VPN клиентов:

«`

/ip pool add name=lan_vpn ranges=10.20.0.200-10.20.0.254

«`

Создайте новый PPP профиль:

«`

/ppp profile add name=l2tp-vpn-lan local-address=10.20.0.1 \

remote-address=lan-vpn dns-server=10.20.0.1

«`

Включите L2TP сервер. Для наших целей достаточно только метода аутентификации *mschap2*.

«`

/interface l2tp-server server set enabled=yes authentication=mschap2 \

default-profile=l2tp-vpn-lan

«`

Создайте пользователя:

«`

/ppp secret add name=userlogin password=userpassword service=l2tp \

profile=l2tp-vpn-lan

«`

## Настройка IPSec

Созадем ipsec peer:

«`

/ip ipsec peer add address=0.0.0.0/0 port=500 auth-method=pre-shared-key \

secret=»shared_password_key» exchange-mode=main-l2tp send-initial-contact=yes \

nat-traversal=yes proposal-check=obey hash-algorithm=sha1 \

enc-algorithm=3des dh-group=modp1024 generate-policy=yes \

lifetime=»1d 00:00:00″ dpd-interval=120 dpd-maximum-failures=5

«`

Некоторые разъяснения:

* «address=0.0.0.0/0« — разрешаем подключение с любого IP адреса;

* «auth-method=pre-shared-key« — аутентификация компьютера с помощью общего ключа;

* «secret=»shared_password_key»« — пароль общего ключа;

Созадем ipsec proposal

«`

/ip ipsec proposal set default auth-algorithms=sha1 \

enc-algorithms=3des,aes-256 lifetime=30m pfs-group=

«`

## Включение Proxy-ARP

Поскольку компьютеры в локальной сети и удаленные клиенты используют IP адреса из одной и той же подсети, необходимо включить proxy-arp на интерфейсе подключенном к локальной сети. В нашем примере это «ether2«:

«`

/interface ethernet

set ether2 arp=proxy-arp

«`

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

WizzycomNET

Just another WordPress site. But it’s mine !!

Mikrotik L2TP/IPsec VPN and android device as client

Mikrotik should have a real internet IP to a certain interface. If it is located behind nat, the modem that provides internet access should be able to forward ipsec-esp packages. If your mikrotik is behind an internet modem that does not forward ipsec-esp, then you should stop here.

Your android smart phone must be in version 4 or newer in order to support L2TP/IPsec. The android client supports the following :

Authentication algorithm : sha1
Encryption algorithm : 3des
Diffie-Hellman : Group2 (modp1024)

Let’s start by creating a PPP Profile on mikrotik.

On local-address= we assing an IP address that will appear as the default gateway for the VPN clients. A good hint is to find a network that it is not used. Then we have to activate the L2TP server of the mikrotik and bind it with a PPP Profile.

Once the the L2TP server is activated , we have to define the peering of IPSec and also the default ipsec policy. WARNING : On newer RouterOS versions, generate-policy set to yes is not supported. On this case just use generate-policy=port-override

On secret = you should define the pre-shared key that must match the pre-shared key of the client (android phone). After we defined the peering, we must make some changes on the default ipsec proposal.

To complete the configuration, we need to add a user.

On user= we define the user name and the user password on password=. On remote-address= we define the desired IP address that will be assigned to the client.

If our mikrotik has real internet IP to an interface and we have enabled firewalling, we must allow the UDP ports : 500, UDP: 1701, UDP: 4500 and Protocol 50: ipsec-esp

For the android client, we must set the following :

Name : Home VPN
Type : L2TP/IPSec PSK
Server address : real ip address of mikrotik
IPSec pre-shared key : the value that you set as secret=

(No Ratings Yet)

10 thoughts on “ Mikrotik L2TP/IPsec VPN and android device as client ”

Good manual, thaks for that. Can you please help, why when i run packet sniffer, I see only UDP packets, not ipsec? I have other ipsec site to site connection on the same mikrotik, on site2site I see ipsec. Are there any ideas?

set default auth-algorithms=sha1 enc-algorithms=3des pfs-group=modp1024

I get “syntax error (line 1 column 5)” and the “d” in default is highlighted. As I can see, there’s no such command. Version 6.41

The command was ip ipsec proposal set default auth-algorithms=sha1 enc-algorithms=3des pfs-group=modp1024. I just made the corrections needed on the guide

I did all that and in the log I have:

dec/05 00:36:46 ipsec,info respond new phase 1 (Identity Protection): 95.140.124.22
3[500]192.168.28.116[500]
dec/05 00:36:47 ipsec,info ISAKMP-SA established 95.140.124.223[500]-192.168.28.116
[500] spi:a1d96c2fe8700d38:4417360f28e8ed27
dec/05 00:36:48 l2tp,info first L2TP UDP packet received from 192.168.28.116

and after that… nothing. Phone just say unsuccessful

Which mikrotik version are you using . Is there any logging for phase 2 ?

My setup is freezeing in the same state.
But there additional 2 errors
192.167.90.132 (my remore ip) failed to pre-process ph2 packet
192.167.90.13 peer sent packet for dead phase2

There might a bug in ipsec. It was referred in the past in versions 6.38.5 and 6.39.3. I will need some time to make some tests. But you can try downgrading to 6.37

Ok I have made some changes on the guide. I have tested it with version 6.41.1.

Please apply the following commands and let me know of the outcome :

/ip ipsec policy set [ find default=yes ] src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=default template=yes

/ip ipsec proposal set default auth-algorithms=sha1 enc-algorithms=3des pfs-group=modp1024

Don’t forget to change the field secret on the following command. this field must match with the value preshared key (PSK) on your client device

/ip ipsec peer add address=0.0.0.0/0 port=500 auth-method=pre-shared-key secret=123456 exchange-mode=main-l2tp send-initial-contact=no nat-traversal=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 generate-policy=port-override

Источник

Mikrotik vpn l2tp ipsec android

Thu Nov 29, 2012 4:05 pm

I tried to get L2TP/IPSec working today with an android client. I have everything set up correctly I think, and it seems to be L2TP problem. Any help would be appreciated. Here is the config:

Firewall is open for UDP500, UDP 1701, IPSec esp.

I have searched around and wasnt able to find an issue with the config. The IPSec seems to establish correctly with SAs and the dynamic generated policy. Any way I can troubleshoot this?

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 6:06 pm

Not sure, but I suspect you have a firewall rule that’s a problem.

Those IPSec packets are going to simply «show up» on the WAN interface with a source IP of whatever public IP they have.

If you sanitize input on the WAN side, you’re going to find you need a rule like this on the WAN.

Allow any Source IP to any Destination IP.

Crazy and insecure to boot. [Lovely how Mikrotik implemented IPSec isn’t it!]

The only way this isn’t insane, security-wise, is if you’re using NAT, otherwise you can’t allow IPSec connections from any unknown IP. Since most anyone uses L2TP as a road-warrior connection type, this [not allowing connects from unknown IP’s] obviously won’t fly.

Try marking all your firewall rules as inactive and see if the traffic passes. I’d guess it does and then you’ll need to decide if you can live with the botched train-wreck that is IPSec on Mikrotik. [Personally, I won’t implement L2TP anywhere with MikroTik gear — I’m using OpenVPN — which is nearly as botched as IPSec, but is marginally better for RoadWarrior support.]

Mikrorik: Here’s a hammer and an awl — would you like to smash your thumb or gouge your eyes out?
Me: How about I don’t pick either.
Mikrotik: Nope — either the eyes or the thumb.
Me: [Grimace] Well, I guess the thumb then.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 6:55 pm

Sorry man, but I really dont understand what you are talking about. The input or the forward chain?

On the input chain I have everything going through firewall correctly allowing UDP 500, UDP 1701, IPSec ESP. Packets are correctly increasing in the counter.
As for forward chain, since the L2TP tunnel wont establish, the forward chain isnt getting applied to packets yet.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:21 pm

The forward chain.

Just try what I said.
Either disable all the Forward rules, or put an allow all rule at the very top.

The packets ARE hitting the forward chain.

Your logs show the L2TP session not getting replied to, and I’m pretty sure that’s the problem — it’s getting killed.

—
Here’s what happens.
-IPSec packet arrives.
[This is on input]
-ROS handles IPSec stuff, and dumps the unwrapped packed in the WAN interface. [Now you have an L2TP packet alone, instead of a IPSec wrapped L2TP packet.]
-Now you have a packet on the WAN that has a source address of say 4.3.2.1 — whatever the IP address of the L2TP client is.

-It’s the L2TP session. It has to traverse the WAN interface and get to the L2TP server in ROS to get handled.

If you have a rule that blocks all unknown WAN IP’s from traversing the WAN then the L2TP packets are getting killed.

—
Side-effect [This doesn’t really have anything to do with your problem, but is a result of no IPSec policy match options.]

Since there’s no IPSec policy match supported in ROS, you also can’t make sure that all L2TP sessions actually came over IPSec. Thus someone could make mass runs against your L2TP server and attempt to break one of the PPP user credentials.

With an IPSec policy match you could make sure you don’t allow unknown source IP’s onto the LAN unless they ALSO came over the IPSec tunnel.

—
Just try what I’ve suggested, I think you’ll find it fixes the problem, and then when you see what’s going on, you’ll understand better and can come back and discuss more if you need.

If it doesn’t fix it, then it only cost you 3 minutes or so.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:28 pm

Just tested it and nope it doesnt help.

Also, any packet destined for the router itself is in the INPUT chain. You can try this yourself. Make a log rule on input for the L2TP server. Make a forward log rule for the L2TP. Connect to the L2TP server running on the router, and you will see only the input chain gets logged.

This is also explained in the packet flow diagram http://wiki.mikrotik.com/wiki/File:IP_final.png
As you can see from the packet flow, the packet simply goes through the INPUT chain twice, once while its IPSec encrypted, and second time when its unencrypted.

As for filtering the access to the L2TP server only for IPSec clients, yeah, I will have to look into how to secure that. First to get it working tho

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:32 pm

I was not thinking clearly. Also do the same for the input chain.

You’re right, the L2TP traffic will be talking to the RB, so it’s going to be on INPUT.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:35 pm

I was describing things related to IPSec more generically — and how that can cause issues when used as a Road-Warrior setup. Since the IPSec traffic isn’t flowing to the LAN side as the next step, but to the L2TP server on the RB, then it’s the INPUT chain that matters.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:40 pm

I made a log rule for the remote IP (much more secure then allowing all traffic on input) to see if any traffic from the remote IP is getting dropped. Its not. UDP 500, UDP 1701 and IPSec ESP are open to the remote IP, and nothing after that is getting logged as dropped.

Im pretty confident its not firewall that is making this not work.

On forward chain, even generally in IPSec and in this case too, you should always know the IP adress (range) of the other side, so securing it should not a problem either.
Here I know what IPs my L2TP server will assign to clients, so in forward, I have those IPs allowed to go into my LAN.

The mystery why L2TP is not building the tunnel with the Android client still remains tho

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 7:52 pm

So your L2TP clients will always connect from known networks? Never from a hotel or coffee shop? [Good if that works for you. It’s a lot more secure, but that certainly won’t work for most, and won’t for me.]

Is there any chance a NAT/Mangle rule is hitting?
Anything non-default in routing?

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 8:05 pm

Is there any chance a NAT/Mangle rule is hitting?
Anything non-default in routing?

No, IPSec will always be established from an unknown IP. But that is protected with a PSK and all the configs have to match on both sides. So IPSec will be availible on the router to the world. But that is secure, its IPSec. Besides, since I dont know the remote IP, there is no other way to do it.

L2TP will only be availible to IPSec connected clients. That can be scripted easily. Just get the peers IP with «:put [/ip ipsec remote-peers get [find] remote-address]» That will get you remote IPs of all clients that are properly connected with IPSec. So L2TP server will not be availible to the world, only to the clients which are properly connected through IPSec.

The L2TP server assigns an IP to its clients from a pool I specify in the L2TP profile. So in forward chain, the access to my LAN is secured with a firewall rule that only allows access to my LAN from the clients from this L2TP IP pool.

But yeah, I am currently looking at mangle and routing (have some of both) to see why it would make L2TP server not work. So far I cant see a reason why it doesnt work, but I will keep looking.

Any tips are welcome

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 8:23 pm

I don’t have time to spend, but you don’t understand how IPSec is handled by ROS.

Say someone connects from 4.3.2.1 via IPSec or L2TP [essentially the same] to your RB.

The IPSec traffic is handled and then a packet just appears on your WAN interface.

It’s source IP is 4.3.2.1. [But if you don’t know what IP addresses your IPSec/L2TP connections come from, use * instead of 4.3.2.1]

So, if you block ANY traffic from any publicly routed IP address on the WAN interface from FORWARD/INPUT you can’t guarantee that IPSec or L2TP will work.

Normally, I’d have a Rule on Forward/Input that blocks all traffic from unknown IP’s for any service I’m not opening to the public.
But with no IPSec policy match, I can’t do this if I allow IPSec from unknown IP’s.

Because I’m going to get a packet on the WAN from some unknown IP on a non-public service — say RDP.
If you capture and watch the traffic, you’ll see what I’m talking about.

Here’s what you’ll see for a Road-warrior connect via IPSEC from 4.3.2.1 to an LAN station for RDP.
On the WAN interface I’ll have a packet from
Scr-ip:4.3.2.1 with some source-port. [to] -> Some LAN IP, with RDP as the dst-port.

Without NAT you’d be *insane* to accept such a packet. With NAT it can’t get to the LAN since there’s no routing table to direct it. But it’s only NAT that’s protecting you, not your firewall rules.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 8:42 pm

I don’t have time to spend, but you don’t understand how IPSec is handled by ROS.

Say someone connects from 4.3.2.1 via IPSec or L2TP [essentially the same] to your RB.

The IPSec traffic is handled and then a packet just appears on your WAN interface.

It’s source IP is 4.3.2.1. [But if you don’t know what IP addresses your IPSec/L2TP connections come from, use * instead of 4.3.2.1]

Читайте также: Lord the fallen android

So, if you block ANY traffic from any publicly routed IP address on the WAN interface from FORWARD/INPUT you can’t guarantee that IPSec or L2TP will work.

Because I’m going to get a packet on the WAN from some unknown IP on a non-public service — say RDP.
If you capture and watch the traffic, you’ll see what I’m talking about.

Sorry, but I have a feeling you actually dont know how IPSec (or L2TP) work. So lets get this straight.

1) IPSec is not essentially the same as L2TP. If IPSec is in transport mode, its very different.
L2TP can be considered the same as IPSec only for IPSec tunnel mode, and then its still different.

2) Packets dont just appear on WAN interface. Look on the packet flow diagram to see how they are handled.
Explained in the packet flow diagram http://wiki.mikrotik.com/wiki/File:IP_final.png

Lets consider a scenario without NAT as you mentioned:

Scenario 1)
Client 4.3.2.1 (or any random IP) connect to L2TP concentrator. Since we dont know the remote IP, the L2TP has to be publicaly accessible. L2TP is however protected by username and password. Inside of the L2TP tunnel, the client gets an IP address from a pool YOU configure. That is how L2TP works.

Now in firewall you can actually filter. You would NOT allow
Scr-ip:4.3.2.1 with some source-port. [to] -> Some LAN IP, with RDP as the dst-port.

But you WOULD allow
Scr-ip:»L2TP IP of the client» with some source-port. [to] -> Some LAN IP, with RDP as the dst-port.

Scenario 2)
For IPSec tunnel mode
In tunnel mode, you know the IP that is behind the tunnel, since you HAVE TO configure it in IPSec policy. If you use «generate policy», the policy will be generated with proper IPs that are on the other side of the tunnel. Therefore, you can filter in firewall based on these IPs.

Scenario 3)
For IPSec transport mode
Again, you either know the remote IP (becuase you have to configure it in policy), or the policy is generated and you can get the IP from there. So again, you know the remote IP, and you can filter with it in firewall.

Please actually re-read my post from before, and you really should look more into how all this works. Same as you were thinking that L2TP traffic is in forward chain and you were wrong, you are wrong here as well. IPSec and L2TP are handled very well in Mikrotik, it seems you just have a big mess out of how it works.

Re: L2TP/IPSec with Android

Thu Nov 29, 2012 9:34 pm

1) Why the heck does Linux give you an IPSec policy match if you really don’t need it? [Answer: You do, but you can get by without it, if you sacrifice security.]

2) Re: the above.
«Again, you either know the remote IP (becuase you have to configure it in policy), or the policy is generated and you can get the IP from there»

So, you’re generating dynamic firewall rules based on the IPSec generated policy? Really? Since I’m not aware of any event driven rule methods, I’m not sure how that works. Please tell.

Obviously if you know the connecting IP, which rules out road-warrior, then you don’t have to use generated policies.

3) Since they can connect to L2TP direct, you have reduced the security of your system to the PPP credential — you’ve thrown away any benefits of validation of identity that IPSec gave you. Not a good plan IMO.

But I have watched IPSec traffic flows, esp for Road-warrior connections and I know what’s coming in.
For
-road-warrier connects,
-where connecting IP isn’t known,
-without IPSec policy match,
-and a non-NAT WAN LAN,
. it’s suicide.
[Unless you can somehow make a dynamic firewall that works, based on generated IPSec policy IP source addresses.]

But I’m not going to argue. It’s your network, and however you want to run it, have at it. I won’t run mine that way, but that doesn’t impact you.

But if you have a working dynamic firewall that accounts for IPSec auto-generated SA’s — the I’d be glad to see it. It would perhaps be a start in securing RW IPSec connections.

Источник