Inconsistent L2TP/IPSEC success with Android 4.3 [RESOLVED?]

RouterOS Beginner Basics
1

I am attempting to configure IPSEC/L2TP VPNs to various sites on a new Nexus 7, using a cellular connection. I have gotten it working successfully to one site, but when the exact same configuration is copied to another site, the connection will not establish. Both sites have static IPs, no NAT between router. Tablet is on Tmobile LTE and has a good connection. Below is the configuration for the site that works:

ip ipsec peer/

address=0.0.0.0/0 passive=yes port=500 auth-method=pre-shared-key secret="1234" generate-policy=port-override exchange-mode=main-l2tp send-initial-contact=yes nat-traversal=yes hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 lifetime=1d dpd-interval=disable-dpd dpd-maximum-failures=5

ip ipsec proposal/

name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-256 lifetime=30m pfs-group=modp1024

ppp profile/

name="default_l2tp-mobile" local-address=10.0.0.1 remote-address=data_pool remote-ipv6-prefix-pool=(unknown) use-ipv6=no use-mpls=default use-compression=default use-vj-compression=default use-encryption=default only-one=default change-tcp-mss=yes address-list="" dns-server=10.0.0.1

ppp secret/

name="nexus" service=l2tp caller-id="" password="1234" profile=default_l2tp-mobile routes="" limit-bytes-in=0 limit-bytes-out=0

And here is the configuration for the non-working site:

ip ipsec peer/

address=0.0.0.0/0 passive=yes port=500 auth-method=pre-shared-key secret="1234" generate-policy=port-override exchange-mode=main-l2tp send-initial-contact=yes nat-traversal=yes hash-algorithm=sha1 enc-algorithm=3des dh-group=modp1024 lifetime=1d dpd-interval=disable-dpd dpd-maximum-failures=5

ip ipsec proposal/

name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-256 lifetime=30m pfs-group=modp1024

ppp profile/

name="default_l2tp-mobile" local-address=10.1.1.1 remote-address=oip-voice_pool remote-ipv6-prefix-pool=(unknown) use-ipv6=no use-mpls=default use-compression=default use-vj-compression=default use-encryption=default only-one=default change-tcp-mss=yes address-list="" dns-server=10.1.1.1

ppp secret/

name="nexus" service=l2tp caller-id="" password="1234" profile=default_l2tp-mobile routes="" limit-bytes-in=0 limit-bytes-out=0

Below is a sample of where the tunnel fails in the log:

15:56:06 l2tp,debug,packet L2TP =>: sent control message (ack) to 12.34.56.78:33420 
15:56:06 l2tp,debug,packet L2TP =>:     tunnel-id=33430, session-id=0, ns=1, nr=1 
15:56:07 l2tp,debug,packet L2TP =>: rcvd control message from 12.34.56.78:33420 
15:56:07 l2tp,debug,packet L2TP =>:     tunnel-id=0, session-id=0, ns=0, nr=0 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Message-Type=SCCRQ 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Protocol-Version=0x01:00 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Host-Name="anonymous" 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Framing-Capabilities=0x3 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Assigned-Tunnel-ID=33430 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Receive-Window-Size=1 
15:56:07 l2tp,debug,packet L2TP =>: sent control message (ack) to 12.34.56.78:33420 
15:56:07 l2tp,debug,packet L2TP =>:     tunnel-id=33430, session-id=0, ns=1, nr=1 
15:56:07 l2tp,debug,packet L2TP =>: rcvd control message from 12.34.56.78:33420 
15:56:07 l2tp,debug,packet L2TP =>:     tunnel-id=0, session-id=0, ns=1, nr=0 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Message-Type=StopCCN 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Assigned-Tunnel-ID=33430 
15:56:07 l2tp,debug,packet L2TP =>:     (M) Result-Code=6 
15:56:07 l2tp,debug L2TP =>: received message with wrong tunnel id, ignoring 
15:56:08 ipsec,debug,packet ipsec =>: KA: 76.54.34.23[4500]->12.34.56.78[48210] 
15:56:08 ipsec,debug,packet ipsec =>: sockname 76.54.34.23[4500] 
15:56:08 ipsec,debug,packet ipsec =>: send packet from 76.54.34.23[4500] 
15:56:08 ipsec,debug,packet ipsec =>: send packet to 12.34.56.78[48210] 
15:56:08 ipsec,debug,packet ipsec =>: src4 76.54.34.23[4500] 76.54.34.
15:56:08 ipsec,debug,packet ipsec =>: dst4 12.34.56.78[48210] 
15:56:08 ipsec,debug,packet ipsec =>: 1 times of 1 bytes message will be sent to 12.34.56.78[48210] 
15:56:08 ipsec,debug,packet ipsec =>: ff 
15:56:10 l2tp,debug,packet L2TP =>: sent control message to 12.34.56.78:33420 
15:56:10 l2tp,debug,packet L2TP =>:     tunnel-id=33430, session-id=0, ns=0, nr=1 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Message-Type=SCCRP 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Protocol-Version=0x01:00 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Framing-Capabilities=0x1 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Bearer-Capabilities=0x0 
15:56:10 l2tp,debug,packet L2TP =>:     Firmware-Revision=0x1 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Host-Name="datacenter.2011" 
15:56:10 l2tp,debug,packet L2TP =>:     Vendor-Name="MikroTik" 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Assigned-Tunnel-ID=141 
15:56:10 l2tp,debug,packet L2TP =>:     (M) Receive-Window-Size=4 
15:56:18 l2tp,debug L2TP =>: tunnel 141 received no replies, disconnecting 
15:56:18 l2tp,debug L2TP =>: tunnel 141 entering state: dead

IPSEC negotiates correctly; it fails when it gets to L2TP. Firewall has ports 1701, 500, and 4500 open. Source NAT is configured to send all traffic out on the same IP as I am expecting traffic in on for L2TP. Both routers are running 6.4. Anyone have any ideas what I’m doing wrong? Been looking at this for so long I’m sure I’m missing something. Let me know if there’s anything else you’d like me to show. Thanks!

2

can you connect with a pc to that site?

3

I have 15+ other L2TP connections to this site. I generally use pptp for mobile connections, but need L2TP for always on van with android. I will test with osx this weekend.

4

Did just notice that the tablet replies with the “Result-Code” of 6, which according to http://www.iana.org/assignments/l2tp-parameters/l2tp-parameters.xhtml#l2tp-parameters-12 means invalid destination. I’ll be testing this tonight with osx/windows 7 to see if I can get a different result. Should also note that I have the same result while behind NAT on wifi.

5

The issue was that the traffic for the L2TP connection was not hitting the input chain. They were experiencing the same issue described here:
http://forum.mikrotik.com/t/policy-routing-l2tp-and-multiple-wans/36807/1

That was posted 3 years ago. Am I doing something wrong, or is this seriously still broken? Mikrotik? Anyone? Below is the rule I needed to add in order to get it working. It does work at this point, but damn does it feel that much more hacked together…

/ip firewall nat
add action=dst-nat chain=dstnat comment="Fix for an L2TP src-address bug" dst-address="76.54.34.23" dst-port=1701 protocol=udp to-addresses="76.54.34.18"

That makes sense, but still is really crap. Is there a better way to do this?

6

Got a reply from Mikrotik. It is indeed a bug, and they said it “will be fixed in the future”, which i’d guess is code for never.

7

Don’t say never. If it has only been 3 years, I would be surprised if this isn’t fixed within the next 5-8 years. Just be patient, give them a few more years.

8

Continue to hit this issue. Mikrotik, can you please respond with an answer as to how the problem should be properly solved?