IPSEC/L2TP discconect after one minute

RouterOS General
1

Hi,

I’m trying to set-up a VPN based on IpSec/L2TP. Everything works and I can use the VPN connection when connected. I see the L2TP tunnel listen under PPP ->Interfaces. But after one minute or so the L2TP tunnel drops. The IPSEC connection just stays connected. It looks like the L2TP does not get a reply on a HELO message and discconects then. See below the L2TP log where it ends. Does anyone have a clou? Tried already several things like from this topic: http://forum.mikrotik.com/t/ipsec-l2tp-vpn-on-mikrotik-behind-nat-but-with-fqdn/65755/1
Nov/15/2019 22:49:50 l2tp,debug,packet L2TPDBG===>: (M) Message-Type=HELLO
Nov/15/2019 22:49:52 l2tp,ppp,debug,packet L2TPDBG===>: <X.X.X.X>: sent LCP EchoReq id=0x7
Nov/15/2019 22:49:52 l2tp,ppp,debug,packet L2TPDBG===>: <magic 0xc25639d>
Nov/15/2019 22:49:52 l2tp,ppp,debug,packet L2TPDBG===>: <X.X.X.X>: rcvd LCP EchoRep id=0x7
Nov/15/2019 22:49:52 l2tp,ppp,debug,packet L2TPDBG===>: <magic 0x10400d01>
Nov/15/2019 22:49:54 l2tp,debug,packet L2TPDBG===>: sent control message to X.X.X.X:44758 from Y.Y.Y.Y:1701
Nov/15/2019 22:49:54 l2tp,debug,packet L2TPDBG===>: tunnel-id=37551, session-id=0, ns=2, nr=4
Nov/15/2019 22:49:54 l2tp,debug,packet L2TPDBG===>: (M) Message-Type=HELLO
Nov/15/2019 22:50:02 l2tp,debug,packet L2TPDBG===>: sent control message to X.X.X.X:44758 from Y.Y.Y.Y:1701
Nov/15/2019 22:50:02 l2tp,debug,packet L2TPDBG===>: tunnel-id=37551, session-id=0, ns=2, nr=4
Nov/15/2019 22:50:02 l2tp,debug,packet L2TPDBG===>: (M) Message-Type=HELLO
Nov/15/2019 22:50:10 l2tp,debug L2TPDBG===>: tunnel 12 received no replies, disconnecting
Nov/15/2019 22:50:10 l2tp,debug L2TPDBG===>: tunnel 12 entering state: dead
Nov/15/2019 22:50:10 l2tp,debug L2TPDBG===>: session 1 entering state: dead
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: LCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: LCP closed
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: CCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: BCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: BCP down event in starting state
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPCP closed
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPV6CP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPV6CP down event in starting state
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: MPLSCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: CCP close
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: BCP close
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPCP close
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: IPV6CP close
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: MPLSCP close
Nov/15/2019 22:50:10 l2tp,ppp,info L2TPDBG===>: : terminating… - hungup
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: LCP lowerdown
Nov/15/2019 22:50:10 l2tp,ppp,debug L2TPDBG===>: <X.X.X.X>: LCP down event in starting state
Nov/15/2019 22:50:10 l2tp,ppp,info,account L2TPDBG===>: User1 logged out, 84 12694 16678 89 82
Nov/15/2019 22:50:10 l2tp,ppp,info L2TPDBG===>: : disconnected

2

The symptoms resemble a default route conflict to me. If you let the /interface l2tp-client install a default route via itself when it comes up, the IPsec transport packets carrying the L2TP traffic towards the L2TP server may start getting routed using this new default route once the routing cache expires, which means that a routing loop occurs and the packets don’t actually get anywhere.

So show your full configuration export. There are multiple ways how to deal with this issue, the simplest one is to set up an individual route towards the L2TP server, but it may not be that simple if the latter is identified by a domain name and its actual address changes over time or if your WAN IP configuration is assigned dynamically.

3

Hi Sindy,
Thanks for your reply. The config is as follows:
/interface bridge
add arp=proxy-arp fast-forward=no igmp-snooping=yes name=bridge-local
add arp=proxy-arp fast-forward=no name=bridge-vlan pvid=40 vlan-filtering=yes

/interface ethernet
set [ find default-name=ether1 ] arp=proxy-arp name=ether1-gateway
set [ find default-name=ether3 ] speed=100Mbps
set [ find default-name=ether4 ] speed=100Mbps
set [ find default-name=ether5 ] speed=100Mbps
set [ find default-name=ether6 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether7 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether8 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether9 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full
set [ find default-name=ether10 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full

/interface vlan
add interface=ether1-gateway name=vlan1.4 vlan-id=4
add interface=ether1-gateway name=vlan1.6 vlan-id=6
add interface=ether5 name=vlan30 vlan-id=30
add interface=bridge-vlan name=vlan40 vlan-id=1
add interface=ether5 name=vlan50 vlan-id=50
add interface=ether5 name=vlan60 vlan-id=60
add interface=ether4 name=vlan220 vlan-id=220
add interface=ether4 name=vlan221 vlan-id=221
add interface=ether4 name=vlan222 vlan-id=222
add interface=ether5 name=vlan223 vlan-id=223

/interface pppoe-client
add add-default-route=yes allow=pap,mschap2 disabled=no interface=vlan1.6
keepalive-timeout=20 max-mru=1480 max-mtu=1480 name=ppoe password=PPOE_PASSWORD
user=PPOE_USERNAME

/ip ipsec profile
set [ find default=yes ] nat-traversal=no
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc lifetime=8h

/interface l2tp-server server
set authentication=mschap2 default-profile=profile1-L2TP_users enabled=yes
ipsec-secret=PSK keepalive-timeout=5
max-mru=1460 max-mtu=1460 use-ipsec=required

/ip pool
add name=pool1-L2TP_users ranges=192.168.125.100-192.168.125.200

/ppp profile
add local-address=192.168.125.1 name=profile1-L2TP_users remote-address=
pool1-L2TP_users use-encryption=yes

/routing bgp instance
set default disabled=yes

/interface bridge port
add bridge=bridge-local hw=no interface=ether2
add bridge=bridge-local hw=no interface=ether3
add bridge=bridge-local hw=no interface=ether4
add bridge=bridge-local interface=ether6

/ip neighbor discovery-settings
set discover-interface-list=discover

/interface l2tp-server server
set authentication=mschap2 default-profile=profile1-L2TP_users enabled=yes
ipsec-secret=PSK keepalive-timeout=5
max-mru=1460 max-mtu=1460 use-ipsec=required

/interface list member
add interface=ether2 list=discover
add interface=ether3 list=discover
add interface=ether4 list=discover
add interface=ether5 list=discover
add interface=ether6 list=discover
add interface=ether7 list=discover
add interface=ether8 list=discover
add interface=ether9 list=discover
add interface=ether10 list=discover
add interface=bridge-local list=discover
add interface=vlan1.4 list=discover
add interface=vlan30 list=discover

/ip firewall filter
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input protocol=ipsec-esp

/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes

/ip upnp
set enabled=yes show-dummy-rule=no

/ip upnp interfaces
add interface=bridge-local type=internal
add interface=pppoe type=external

/ppp secret
add name=USERNAME
password=
PASSWORD
profile=profile1-L2TP_users service=l2tp

/routing igmp-proxy
set quick-leave=yes

/routing igmp-proxy interface
add alternative-subnets=X.X.X.X/16,Y.Y.Y.Y/16 interface=vlan1.4
threshold=0 upstream=yes
add alternative-subnets=0.0.0.0/0 interface=bridge-local

4

I’m a step further I think. I added the L2TP server but not the interface.
I added now the L2TP interface and now I’m able to create a route. But it still disconnects after a minute. But now with another message:

5

On the server side, adding the interface is optional, if you need to make it exist even when the user is not connected because you want to refer to it in firewall rules. I’ll have a look at your configuration in an hour or so.

6

Forget my last reply, it is still the same. Also with adding that interface. SO that is indeed no resolution.

The connection dies everytime exactly after 83/84 seconds, and I’m using an Android phone. There is already a similair topic about (you replied also on this). But without solution:

http://forum.mikrotik.com/t/l2tp-ipsec-and-android-disconnect-after-83-seconds/131257/1

7

Okay. From your OP I did not understand that the Mikrotik is on the server side. In this case, the stealing of default route would be possible as well, but you have to spend much more effort to do that :slight_smile: And it's not your case. Just two more questions from this area, do you get a public IP from the PPPoE server? And what's the IP of the default gateway you get assigned, doesn't it fit into 192.168.0.0/16?

Now the most important thing: your current firewall rules protect nothing. The default action in each chain is accept, so after you selectively accept matching packets by their dedicated rules, the rest is accepted by default anyway. So copy-pasting the default firewall rules from 6.45.7 (obtained using system default configuration print on a SOHO grade device) here:
_/ip firewall nat add chain=srcnat out-interface-list=WAN ipsec-policy=out,none action=masquerade comment="defconf: masquerade"
/ip firewall {
filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"

filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
}_
But if the system was exposed to the internet with firewall set like this for a while, I'd recommend to netinstall it just for the case and use different passwords than ever before for all user accounts.
After netinstall, the rules from the default configuration will be there (unless you have a CCR or something like that), and you'll place the ones necessary for L2TP/IPsec instead of the ##### line above.
If you take the risk of not netinstalling it, make sure that you populate the /interface list LAN and WAN with the corresponding member interfaces, otherwise you may lock yourself out except access via MAC address (winbox & mac-telnet from another Tik), and even the access via MAC adrdress depends on what's configured in the allowed-interface-list under /tool mac-server

To your initial problem, the only things which come to my mind except a faulty client are:

  • a hyperactive firewall somewhere on the path between the client and your Tik server that closes the pinhole so quickly that the L2TP keepalives sent by the server don't get through (I'm not sure whether the auto-generated IPsec peer uses IPSec keepalives, these are usually sent every 20s, use /ip ipsec peer print detail to see this)
  • a frequently changing dynamic address assignment to the client itself or to the NAT device behind which the client is, so the packets from the server don't reach it after the change of the address

You can confirm or deny whether one of those is the case by running Wireshark on the client with a live packet list update (filtering for the IP of the server) and watching whether the IPsec transport packet comes when the server sends the HELLO (on server, you'd be running /tool sniffer quick port=4500 or /tool sniffer quick ip-protocol=ipsec-esp, depending on whether the client is behind a NAT or not, respectively.

8

OK, that makes my suggestion to use Wireshark useless.


I did, but the feedback to my last post there never came. There, I was suspecting the complex way to steal the default route because @kevinsaye hasn’t shown the configuration; you did, and there is no routes item in the /ppp secret, so it cannot be the explanation.

So it could be the Android version, none of my Android phones has ever shown such behaviour but that doesn’t mean that some release cannot have this bug. Do you have a chance to test using another client? Is the Android connecting via mobile network or via WiFi network? And could it be that you are testing it on your home LAN (I cannot see any signs of LAN IP configuration so I suppose not but you may have filtered some information out from the export, deeming it irrelevant)?

9

I am having the exact same issue to my best understanding …
http://forum.mikrotik.com/t/l2tp-ipsec-on-mobile-drops-connection/134805/3

Just dropping this here for reference.

If I can provide anything additional from my end to help with this please let me know!

10

@JordanReich, can you run the /tool sniffer command I’ve given above while watching the dynamically created l2tp interface in another window? I’m interested in whether the IPsec transport packet carrying the second HELLO (which remains unresponded) is ever sent anywhere at all, and if it is, whether it is sent out the same interface like the previous traffic.

11

You may need to help me with exactly what output your looking to get. But I see the following for port 4500 on the IP address of the mobile phone.

 
OutToWAN                                                                                       26.611    306 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        REMOVED-PRIVATE:54294                 REMOVED-PRIVATE:4500                   ip:udp      174   1 no

In this case the phone was the source and my router was the destination.

12

If OutToWAN is the name of the interface, and it is the same like for the previous packets to&from the address of the phone, and if the last packet seen is from server to phone and no response comes back, we may safely conclude that either the packet doesn’t make it to the phone or the phone doesn’t respond.

If the last packet comes from the phone, something else is rotten. In that case, we need to modify the command to /tool sniffer quick ip-address=IP.of.the.phone port=4500,1701

The point is that in receiving direction, both the IPsec transport packet and the one decapsulated from it are visible, so we should see whether the phone’s last response was successfully decrypted.

13

Got it, I think.

I ran the following command [tool sniffer quick ip-address=PHONE.IP port=4500,1701]

Got a lot of traffic moving back and forth router side and mobile side upon initial connection. Once the connection stalled on the phone the traffic changes to this…

Yes OutToWAN is the interface in/out.

OutToWAN                                                                                      114.781   4615 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C       PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      158   1 no 
OutToWAN                                                                                       115.23   4616 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      190   1 no 
OutToWAN                                                                                       115.45   4617 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      190   1 no 
OutToWAN                                                                                      115.687   4618 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      190   1 no 
OutToWAN                                                                                      116.139   4619 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      190   1 no 
OutToWAN                                                                                      116.809   4620 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      158   1 no 
OutToWAN                                                                                       117.02   4621 <-  F0:F7:55:48:52:BF 74:4D:28:2F:4E:2C        PHONE-IP:54294                ROUTER-IP:4500                   ip:udp      190   1 no

99% of the traffic is now PHONE-IP to ROUTER-IP. Though every once and awhile the router seems to kick a response.

OutToWAN                                                                                      267.144   4819 ->  74:4D:28:2F:4E:2C F0:F7:55:48:52:BF        ROUTER-IP:4500                   PHONE-IP:54294                ip:udp       43   0 no

Hopefully this helps!

14

I get a public IP from the PPPoE server. You mean the default gateway from the PPPoE server? I need to check that. Al other addresses I use internally are 192.168.XXX.0/24. I did not post all firewall rules, because I have a lot of VLAN’s with firewall rules. And also some NAT rules. But placed the VPN rules right at the top, so nothing should be blocked?

I will try with other Android devices and mobile networks. I did only try mobile networks, but not WiFi (cannot connect to itself). Also I will do the suggested troubleshooting you replied and let it know.

15

It’s actually not the result I’ve expected - things must have changed since I tried last time. Now I’ve checked it on my setup running 6.45.7, and the packets decapsulated from IPsec are not shown by the embedded sniffer even in the receiving direction any more, which isn’t helpful for diagnostics. Given that the firewall can see the decapsulated packets, I’ll try to put together firewall rules copying those packets to an external sniffer later today, so I hope someone of you affected gentlemen has a Windows or Linux PC which can serve as the external sniffer.

I mean, it’s hard to guess whether the many packets coming from the phone in @JordanReich’s sniff result are payload ones or control ones, so the infrequent responses from the Tik may or may not be OK. I wanted you to see whether the decapsulation of L2TP packets from the IPsec ones works at all, and if it does, what’s the type of the L2TP ones (control or transport).

16

I have an accessible server farm. So we can run whatever tests you need to run. Not a problem.

17

OK then. Assume p.p.p.p is the remote IP from (behind) which the phone establishes the L2TP/IPsec connection, and s.s.s.s is the address of the server which will do the sniffing. So place the following four rules to the very beginning of their respective chains in /ip firewall mangle:

action=sniff-tzsp chain=prerouting dst-port=500,1701,4500 protocol=udp sniff-target=s.s.s.s sniff-target-port=37008 src-address=p.p.p.p
action=sniff-tzsp chain=prerouting protocol=ipsec-esp sniff-target=s.s.s.s sniff-target-port=37008 src-address=p.p.p.p

action=sniff-tzsp chain=postrouting dst-address=p.p.p.p protocol=udp sniff-target=s.s.s.s sniff-target-port=37008 src-port=500,1701,4500
action=sniff-tzsp chain=postrouting dst-address=p.p.p.p protocol=ipsec-esp sniff-target=s.s.s.s sniff-target-port=37008

Then, run Wireshark on the server, or run tcpdump saving the packets into a file with -s 0 there, with capture filter udp port 37008, of course capturing on the interface with address s.s.s.s, and do the laboratory exercise (let the phone connect and wait until the connection breaks).

The capture will contain IPsec control packets, IPsec transport packets, and the plaintext L2TP packets, both outgoing (before encryption) and incoming (after decryption). So we (actually, you, as you probably don’t want to disclose your public IP) should see everything in Wireshark, i.e. what the L2TP server and the phone actually send to each other inside the IPsec transport packets. Except for the address, everything else should be harmless if you use a temporary username and password at the L2TP level. The IPsec PSK cannot be retrieved unless it’s really short and/or unless you work for NSA. So if you prefer, you may use TraceWrangler to anonymize the IP addresses in the pcap file and post it here. Or you may decide you trust me a bit more than an ordinary visitor of this forum and we may exchange contacts in a secure way so that I could see the original trace. It’s up to you. But if you choose to send the capture to me, say so soon, as otherwise the contact exchange will take place tomorrow :slight_smile:

18

So I just created a hotspot with my Android and connected a laptop to it. Configured the VPN connection on the laptop and connected to the hotspot. And wonder well the VPN just stays connected! So I think it is maybe a buggy Android implementation. What kind of Android device do you use JordanReich?

Do you know any standalone VPN app? I tried several, but cannot find a good one that is just a VPN client that you can use to connect to your own router…

Also tried the sniffer cmdlets but I do net get any output. How is that possible?

19

I use the Pixel 3 - Running Android 10 - Nov 5 Patch

I have not been able to find any good VPN clients outside of that which is configured in the phone. I am also using MDM in my environment so I have a need to publish with the VPN options that are built into the device specifically.

20

I think I follow you. Give me a bit to see what I can compile for you and will touch base soon. I am also going to flag MikroTik support on this forum topic as well. Depending upon what we find this appears to be an issue that expands just beyond these case scenarios.