[Solved] L2TP/IPSec with Android

RouterOS General
1

Greetings guys,

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:

/interface l2tp-server server
set default-profile=L2TP enabled=yes

/ppp profile
add name=L2TP

/ppp secret
add local-address=10.0.31.1 name=tomas password=testpass profile=L2TP remote-address=10.0.31.33 service=l2tp

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des,aes-128,aes-192,aes-256 lifetime=1h

/ip ipsec peer
add dpd-interval=15s dpd-maximum-failures=3 exchange-mode=main-l2tp \
    generate-policy=yes hash-algorithm=sha1 secret=VPNpass \
    send-initial-contact=no

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?

L2TP logs say:

15:00:22 l2tp,debug,packet sent control message to clientIP:35752 
15:00:22 l2tp,debug,packet     tunnel-id=27190, session-id=0, ns=0, nr=1 
15:00:22 l2tp,debug,packet     (M) Message-Type=SCCRP 
15:00:22 l2tp,debug,packet     (M) Protocol-Version=0x01:00 
15:00:22 l2tp,debug,packet     (M) Framing-Capabilities=0x1 
15:00:22 l2tp,debug,packet     (M) Bearer-Capabilities=0x0 
15:00:22 l2tp,debug,packet     Firmware-Revision=0x1 
15:00:22 l2tp,debug,packet     (M) Host-Name="host" 
15:00:22 l2tp,debug,packet     Vendor-Name="MikroTik" 
15:00:22 l2tp,debug,packet     (M) Assigned-Tunnel-ID=51 
15:00:22 l2tp,debug,packet     (M) Receive-Window-Size=4 
15:00:26 l2tp,debug,packet sent control message to clientIP:35752 
15:00:26 l2tp,debug,packet     tunnel-id=27190, session-id=0, ns=0, nr=1 
15:00:26 l2tp,debug,packet     (M) Message-Type=SCCRP 
15:00:26 l2tp,debug,packet     (M) Protocol-Version=0x01:00 
15:00:26 l2tp,debug,packet     (M) Framing-Capabilities=0x1 
15:00:26 l2tp,debug,packet     (M) Bearer-Capabilities=0x0 
15:00:26 l2tp,debug,packet     Firmware-Revision=0x1 
15:00:26 l2tp,debug,packet     (M) Host-Name="host" 
15:00:26 l2tp,debug,packet     Vendor-Name="MikroTik" 
15:00:26 l2tp,debug,packet     (M) Assigned-Tunnel-ID=51 
15:00:26 l2tp,debug,packet     (M) Receive-Window-Size=4 
15:00:34 l2tp,debug,packet sent control message to clientIP:35752 
15:00:34 l2tp,debug,packet     tunnel-id=27190, session-id=0, ns=0, nr=1 
15:00:34 l2tp,debug,packet     (M) Message-Type=SCCRP 
15:00:34 l2tp,debug,packet     (M) Protocol-Version=0x01:00 
15:00:34 l2tp,debug,packet     (M) Framing-Capabilities=0x1 
15:00:34 l2tp,debug,packet     (M) Bearer-Capabilities=0x0 
15:00:34 l2tp,debug,packet     Firmware-Revision=0x1 
15:00:34 l2tp,debug,packet     (M) Host-Name="host" 
15:00:34 l2tp,debug,packet     Vendor-Name="MikroTik" 
15:00:34 l2tp,debug,packet     (M) Assigned-Tunnel-ID=51 
15:00:34 l2tp,debug,packet     (M) Receive-Window-Size=4 
15:00:42 l2tp,debug tunnel 51 received no replies, disconnecting 
15:00:42 l2tp,debug tunnel 51 entering state: dead
L2TP VPN problem with Android Client
l2tp over ipsec connection from android
[Solved...finally] Is Mikrotik's Road Warrior L2TP/IPsec a Pipe Dream? No!
L2TP + IPSec outside access problem
Help on remote access to ROS-network from Andriod
2

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...

-Greg

3

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.

4

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.

-Greg

5

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 :slight_smile:

6

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.

7

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.

Sorry…

-Greg

8

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 :slight_smile:

9

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.

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.]

That aside…

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

-Greg

10

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 :slight_smile:

11

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.

-Greg

12

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.

13

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.

  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.

  1. 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.

-Greg

14

Obviously IPSec policy matcher would be a welcome addition and would make things easier. You can get by without it without sacrificing security, you just need to know how to. You can easily script its functionality with Mikrotik. I already posted above how to create dynamic firewall rules based on auto generated IPSec policies.

To quote my earlier post:

IPSec will always be established from an unknown dynamic IP> . But that is protected with a PSK and all the configs have to match on both sides. So IPSec will be available 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 dynamic 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> .

All you need is a 10 line script which modifies ONE address-list with the IP addresses of IPSec clients. So L2TP server is secured in firewall with this address-list. The script adds IPs of IPSec clients to this address-list.

15

L2TP will only be availible to IPSec connected clients.

That’s simply incorrect.

I emailed support, and here’s the query and response.

I’ve setup L2TP on my RB450G - I want to tighten security down some…

  1. Prevent people from logging on via L2TP and their PPP credentials without
    first
    connecting via IPSec.
    I assume that blocking [or not allowing depending on your POV] port
    1701 UDP on the WAN/external interface [or any interface you don’t want someone
    making a regular L2TP connect from] should be sufficient.

However - since IPSec traffic is going to look like it’s coming directly from
the WAN ethernet port - how to do this? [This is why we desperately need a
“normal” IPSec implementation to allow us to match it in filter rules by an
interface like IPTables on Linux does!]

So,
I can’t filter on interface.
I can’t filter based on IP [since it’s going to be the publicly routed
IP address of the connecting client. Road-warrior]
I can’t filter on Port [Obviously I can’t just block UDP 1701 - that will block
everything.]

So, how to generate a rule that allows L2TP over IPSec, but not alone?

Hello,

Currently it is not possible. We will consider adding ipsec policy matcher in the
future versions.

Regards,
Maris

16

“Simply incorrect” doesnt work as a reasonable agrument. All the things you suggested in your email to support are indeed not possible. Policy matching is also NOT possible.

However, doing it the way I described is possible. Read it again, and tell me why it would not work.

17

However, doing it the way I described is possible. Read it again, and tell me why it would not work.

You have a script [or can fashion one] that will allow an IPSec connect, and then modify the “/ip firewall filter” rules to allow L2TP for ONLY that associated SA IP source address? Is that what you’re claiming?

…and you can do that so fast as not to interfere with the L2TP process which will occur in milliseconds after the SA association?

Really?

How are you going to kick off the script when the SA association occurs?
How are you going to accomplish this in less than a few dozen milliseconds?

I’m really interested to see how you do that - frankly it would be pretty incredible.

I’m the first in line to see it.

Let me know.

As far as claiming “it’s simply incorrect.” I’m only telling you what Mikrotik says is true. Perhaps they’re wrong. It wouldn’t exactly surprise me. But I asked them specifically about it, and Mikrotik themselves said there’s no way to prevent users from connecting to L2TP directly and attempting to build a L2TP session outside IPSec.

So, if you want to argue, go argue with Maris, not me.

-Greg

18

Alright, got it working completly now. Works with the Android, iPhone and Win 7 L2TP/IPSec clients flawlessly.

In case someone finds this thread later on, here is the working config:

/ppp profile
add name=L2TP local-address=10.0.31.1 remote-address=l2tp-pool address-list=L2TP_Clients
/ip pool
add name=l2tp-pool ranges=10.0.31.101-10.0.31.199
/ppp secret
add name=username password=password profile=L2TP service=l2tp

/interface l2tp-server server
set default-profile=L2TP enabled=yes

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des,aes-128,aes-192,aes-256 lifetime=1h
/ip ipsec peer
add address=0.0.0.0/0 exchange-mode=main-l2tp generate-policy=yes hash-algorithm=sha1 secret=vpnsecret send-initial-contact=no

If your clients are behind NAT, you have to set nat-traversal=yes in IPSec Peer, and allow UDP 4500 in firewall.

As for securing the L2TP server to IPSec clients only, I will post tommorow.

19

I’m also interested in getting L2TP work for my Apple devices. But I had no luck with this configuration.
I’m getting the following output in the logs while trying to connect..

10:18:35 ipsec,debug,packet 500 bytes message received from XXX.XXX.XXX.XXX[10104] to XXX.XXX.XXX.XXX[500] 
10:18:35 ipsec,debug,packet 8b5e2b11 e5c48a85 00000000 00000000 01100200 00000000 000001f4 0d0000e4 
*removed similar lines*
10:18:35 ipsec,debug,packet 00000014 afcad713 68a1f1c9 6b8696fc 77570100 
10:18:35 ipsec,debug couldn't find configuration.

So your working config doesn’t seem to be complete? Does anybody know what i’m missing here?

20

Is your Ipsec peer correct with 0.0.0.0/0 address? That error means that the corresponding peer can’t be found.

Also, sometimes after importing an Ipsec config, for it to start working you need to reboot the router.