FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
677 views 12 comments
by anonymous

Hello, the L2TP/IPSec vpn client on the RUT is broken. 

Below are the config setup we have on the RUT955.  I have also shown the setup that we have working on wince for the same server

I have also included the logs and screen captures of output from logread and "uci show ipsec"

After the

daemon.info ipsec: 15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]

daemon.info ipsec: 15[NET] sending packet: from 10.20.189.176[500] to 91.5.95.127[500] (900 bytes)

daemon.info ipsec: 07[IKE] retransmit 1 of request with message ID 0
daemon.info ipsec: 07[NET] sending packet: from 10.20.189.176[500] to 91.5.95.127[500] (900 bytes)
daemon.info ipsec: 16[IKE] retransmit 2 of request with message ID 0
daemon.info ipsec: 16[NET] sending packet: from 10.20.189.176[500] to 91.5.95.127[500] (900 bytes)
daemon.debug xl2tpd[4053]: No such tunnel 'l2tp-saphl2tp'

daemon.notice netifd: saphl2tp (30529): xl2tpd-control: Remove l2tp-saphl2tp failed
daemon.notice netifd: Interface 'saphl2tp' is now down
daemon.notice netifd: Interface 'saphl2tp' is setting up now
 daemon.info ipsec: 13[IKE] retransmit 3 of request with message ID 0
daemon.info ipsec: 13[NET] sending packet: from 10.20.189.176[500] to 91.5.95.127[500] (900 bytes)

daemon.debug xl2tpd[4053]: No such tunnel 'l2tp-saphl2tp'

As you can see after several transmits this process fails and then restarts again.  I have uploaded the troubleshooting file and raw logread output. 

Please help here

Brad

1 Answer

0 votes
by anonymous

Hi, 

I briefly checked your logs, issue seems to be caused by hostname saphffm.no-ip.org not being resolved. 

Double check if your DDNS service is working correctly and if connection will still fail then please generate new troubleshoot file.

Best regards,
Martynas

by anonymous
I just triple checked, with win ce devices that are actively sending data to that server via ftp, the IP that the RUT has for saphffm.no-ip.org.  It is the correct IP address.

I also tried to reduce the MTU and MRU size on the RUT(1400 to 1200) with no effect either.  (in case the headers on the ike packets were too big and could not be broken up)
by anonymous

In your network config there are 3 L2TP interfaces configured, two which use public IP's to connect to server and saphl2tp tunnel which uses hostname saphffm.no-ip.org. Logs show netifd errors that DNS lookup fails, could you enter your device's CLI and execute command bellow to check if hostname is being resolved to IP? 

nslookup saphffm.no-ip.org

Also you can try to configure 'saphl2tp' interface with IP address with hostname and check if problem persists. If it does then please generate new troubleshoot.

by anonymous

Fri Oct 28 14:26:36 2022 daemon.info ipsec: 07[IKE] initiating IKE_SA saphffm-saphffm_c[1] to 91.5.95.127
Fri Oct 28 14:26:36 2022 daemon.info ipsec: 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Fri Oct 28 14:26:36 2022 daemon.info ipsec: 07[NET] sending packet: from 10.17.61.201[500] to 91.5.95.127[500] (900 bytes)
Fri Oct 28 14:26:40 2022 daemon.info ipsec: 11[IKE] retransmit 1 of request with message ID 0
Fri Oct 28 14:26:40 2022 daemon.info ipsec: 11[NET] sending packet: from 10.17.61.201[500] to 91.5.95.127[500] (900 bytes)
Fri Oct 28 14:26:48 2022 daemon.info ipsec: 12[IKE] retransmit 2 of request with message ID 0
Fri Oct 28 14:26:48 2022 daemon.info ipsec: 12[NET] sending packet: from 10.17.61.201[500] to 91.5.95.127[500] (900 bytes)
Fri Oct 28 14:26:48 2022 daemon.debug xl2tpd[10847]: No such tunnel 'l2tp-saphl2tp'
Fri Oct 28 14:26:48 2022 daemon.notice netifd: saphl2tp (12099): xl2tpd-control: Remove l2tp-saphl2tp failed
Fri Oct 28 14:26:48 2022 daemon.notice netifd: Interface 'saphl2tp' is now down
Fri Oct 28 14:26:48 2022 daemon.notice netifd: Interface 'saphl2tp' is setting up now
Fri Oct 28 14:27:01 2022 daemon.info ipsec: 15[IKE] retransmit 3 of request with message ID 0
Fri Oct 28 14:27:01 2022 daemon.info ipsec: 15[NET] sending packet: from 10.17.61.201[500] to 91.5.95.127[500] (900 bytes)
Fri Oct 28 14:27:09 2022 daemon.debug xl2tpd[10847]: No such tunnel 'l2tp-saphl2tp'
Fri Oct 28 14:27:09 2022 daemon.notice netifd: saphl2tp (12294): xl2tpd-control: Remove l2tp-saphl2tp failed
Fri Oct 28 14:27:09 2022 daemon.notice netifd: Interface 'saphl2tp' is now down
Fri Oct 28 14:27:09 2022 daemon.notice netifd: Interface 'saphl2tp' is setting up now
Fri Oct 28 14:27:24 2022 daemon.info ipsec: 10[IKE] giving up after 3 retransmits
Fri Oct 28 14:27:24 2022 daemon.info ipsec: 10[IKE] peer not responding, trying again (2/3)
Fri Oct 28 14:27:24 2022 daemon.info ipsec: 10[IKE] initiating IKE_SA saphffm-saphffm_c[1] to 91.5.95.127
Fri Oct 28 14:27:24 2022 daemon.info ipsec: 10[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Fri Oct 28 14:27:24 2022 daemon.info ipsec: 10[NET] sending packet: from 10.17.61.201[500] to 91.5.95.127[500] (900 bytes)
root@Teltonika-RUT955:~# nslookup saphffm.no-ip.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:      saphffm.no-ip.org
Address 1: 91.5.95.127
*** Can't find saphffm.no-ip.org: No answer
root@Teltonika-RUT955:~# ping google.com
PING google.com (142.250.184.238): 56 data bytes
64 bytes from 142.250.184.238: seq=0 ttl=55 time=43.626 ms
64 bytes from 142.250.184.238: seq=1 ttl=55 time=62.406 ms
64 bytes from 142.250.184.238: seq=2 ttl=55 time=53.730 ms
64 bytes from 142.250.184.238: seq=3 ttl=55 time=50.737 ms
64 bytes from 142.250.184.238: seq=4 ttl=55 time=50.836 ms
64 bytes from 142.250.184.238: seq=5 ttl=55 time=51.515 ms
64 bytes from 142.250.184.238: seq=6 ttl=55 time=58.147 ms
64 bytes from 142.250.184.238: seq=7 ttl=55 time=50.710 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 43.626/52.713/62.406 ms
root@Teltonika-RUT955:~# ping saphffm.no-ip.org
PING saphffm.no-ip.org (91.5.95.127): 56 data bytes
^C
--- saphffm.no-ip.org ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

https://community.teltonika-networks.com/?qa=blob&qa_blobid=3716350266127114030

It doesn't work even with the correct ip instead of the URL.  I am really not sure about how nslookup results are supposed to look like but the Address 1 is the correct address, even though there is a return value of *** Can't find saphffm.no-ip.org: No answer

But if you look at the dump of the logread I originally attached to my question you could see that ipsec had the correct address of saphffm.no-ip.org already. 

by anonymous
From nmap -A 91.5.95.127 : the port 500 appears to be closed, so IPSEC won't start.

nslookup pretends there is no answer because there is no IPv6 record for that name.
by anonymous
Hi, I think you need to run a scan on UDP ports 500 and 4500 if you are running nmap to scan the IPSEC ports.  Here is the report from linux laptop

sudo nmap -sU -sV -A -v -sV -Pn -p500 saphffm.no-ip.org

Nmap scan report for saphffm.no-ip.org (91.5.95.127)
Host is up (0.016s latency).
rDNS record for 91.5.95.127: p5b055f7f.dip0.t-ipconnect.de

PORT    STATE SERVICE VERSION
500/udp open  isakmp?
|_ike-version: ERROR: Script execution failed (use -d to debug)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

We know that this VPN server is working, we have dozens of devices that can connect to this server from many different networks... including using the same mobile network that the RUT955 is using to try and connect in this case.  

Normally we use a client that runs on Windows CE and we know that works with this server.  So we really don't think that the problem is with the server.
by anonymous

From nmap -A 91.5.95.127 just now: port 500/UDP appear to be open this wasn't the case two days ago at the moment I checked ...

What do you have in the logs of the server when you try to connect from the RUT955 ? Do you filter on the incoming IP addresses ?

 

by anonymous
No we don't filter IP addresses.  I even switched the cell provide sim card and tried again on a cell network that I know works all of the time... nothing has changed

The server is really complicated to check.  I have turned on the tracing for the remote access service on windows server and that shows nothing.  there appears to be nothing that happens at the authentication level on the remote access server on windows.  I have tried to install wireshark...without success.   I can tell that the server is behind a NAT... and that was a problem on win ce to traverse.

I see no indication at all that the vpn client on the RUT is trying to traverse the NAT to get the correct destination address.  even though I have enabled forceencaps = yes.  I have tried to enable mobike = yes but that doesn't seem to be something that the /etc/init.d/ipsec script supports....

We are really lost here.
by anonymous
Can you do a tcpdump -i wwan0 -n -v 'port 500 or port 4500' on the RUT, this is to check the packet size ? And show the output of ifconfig wwan0 ?
by anonymous

tcpdump output

14:18:21.892365 IP (tos 0x0, ttl 64, id 36726, offset 0, flags [DF], proto UDP (17), length 928)
    10.22.226.122.500 > 91.5.95.127.500: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[I]:
    (sa: len=544
        (p: #1 protoid=isakmp transform=4 len=40
            (t: #1 type=encr id=3des )
            (t: #2 type=integ id=hmac-sha )
            (t: #3 type=prf id=hmac-sha )
            (t: #4 type=dh id=modp1536 ))
        (p: #2 protoid=isakmp transform=27 len=236
            (t: #1 type=encr id=aes (type=keylen value=0080))
            (t: #2 type=encr id=aes (type=keylen value=00c0))
            (t: #3 type=encr id=aes (type=keylen value=0100))
            (t: #4 type=encr id=3des )
            (t: #5 type=integ id=#12 )
            (t: #6 type=integ id=#13 )
            (t: #7 type=integ id=#14 )
            (t: #8 type=integ id=hmac-sha )
            (t: #9 type=integ id=aes-xcbc )
            (t: #10 type=prf id=#5 )
            (t: #11 type=prf id=#6 )
            (t: #12 type=prf id=#7 )
            (t: #13 type=prf id=aes128_xcbc )
            (t: #14 type=prf id=hmac-sha )
            (t: #15 type=dh id=#19 )
            (t: #16 type=dh id=#20 )
            (t: #17 type=dh id=#21 )
            (t: #18 type=dh id=#28 )
            (t: #19 type=dh id=#29 )
            (t: #20 type=dh id=#30 )
            (t: #21 type=dh id=#31 )
            (t: #22 type=dh id=#32 )
            (t: #23 type=dh id=modp3072 )
            (t: #24 type=dh id=modp4096 )
            (t: #25 type=dh id=modp6144 )
            (t: #26 type=dh id=modp8192 )
            (t: #27 type=dh id=modp2048 ))
        (p: #3 protoid=isakmp transform=28 len=268
            (t: #1 type=encr id=#20 (type=keylen value=0080))
            (t: #2 type=encr id=#20 (type=keylen value=00c0))
            (t: #3 type=encr id=#20 (type=keylen value=0100))
            (t: #4 type=encr id=#28 )
            (t: #5 type=encr id=#19 (type=keylen value=0080))
            (t: #6 type=encr id=#19 (type=keylen value=00c0))
            (t: #7 type=encr id=#19 (type=keylen value=0100))
            (t: #8 type=encr id=#18 (type=keylen value=0080))
            (t: #9 type=encr id=#18 (type=keylen value=00c0))
            (t: #10 type=encr id=#18 (type=keylen value=0100))
            (t: #11 type=prf id=#5 )
            (t: #12 type=prf id=#6 )
            (t: #13 type=prf id=#7 )
            (t: #14 type=prf id=aes128_xcbc )
            (t: #15 type=prf id=hmac-sha )
            (t: #16 type=dh id=#19 )
            (t: #17 type=dh id=#20 )
            (t: #18 type=dh id=#21 )
            (t: #19 type=dh id=#28 )
            (t: #20 type=dh id=#29 )
            (t: #21 type=dh id=#30 )
            (t: #22 type=dh id=#31 )
            (t: #23 type=dh id=#32 )
            (t: #24 type=dh id=modp3072 )
            (t: #25 type=dh id=modp4096 )
            (t: #26 type=dh id=modp6144 )
            (t: #27 type=dh id=modp8192 )
            (t: #28 type=dh id=modp2048 )))
    (v2ke: len=192 group=modp1536)
    (nonce: len=32 data=(241569078b9e9d40163c...0000402f00020003000400050000000800004016))
    (n: prot_id=#0 type=16388(nat_detection_source_ip))
    (n: prot_id=#0 type=16389(nat_detection_destination_ip))
    (n: prot_id=#0 type=16430(status))
    (n: prot_id=#0 type=16431(status))
    (n: prot_id=#0 type=16406(status))

ifconfig wwan0 output

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.22.226.122  P-t-P:10.22.226.122  Mask:255.255.255.255
          inet6 addr: fe80::c31f:ec1b:cafe:db0d/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1218 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1284390 (1.2 MiB)  TX bytes:206202 (201.3 KiB)

by anonymous

I have tried to reach 91.5.95.127:500 just to see if I get a reject or an ICMP error of some kind in return. Absolutely nothing, and I am sure the device is working (I use it to reach a strongswan server, just changed the endpoint's IP).

There must be some issue with the NAT at the other end, or something really subtle is at play. Do you have a way to trace the 500/udp packet at the first router level ?

by anonymous
You won't get anything back from ICMP from that server.  They have disabled any response to ICMP on the server.

I will check and see if I can get access to any other packets.

I will also see if I can pull the logs from our embedded linux image as well, we use strongswan as well in our yocto linux build.  I had problems with l2tp/ipsec setup in yocto as well with strongswan/xl2tpd when I setup our linux distro.  

as far as something really subtle goes, it is possible...  before we had problems with the MTU size (the MTU was slightly too large under windows ce) and would cause the server to simply ignore the first request by the client to setup an ipsec tunnel.  I am not sure if that is going on here.  I will see if I can pull some of the other logs on the server to see if that is happening again.
by anonymous

 before we had problems with the MTU size

An old friend !

> I am not sure if that is going on here

Doesn't seem so. From your tcpdump, the length is 928 bytes and the MTU 1500. If you have an MTU less than 928 at the server's side you'll have issues. Idem if the size of the reply is larger than the server's MTU.

Without the logs and/or tcpdump/wireshark it will be hard to debug.

Another idea (I don't think much of it but who knows ...) on the RUT, what is the output of

iptables -t nat -n -L | grep ipsec | grep pol