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
334 views 5 comments
by
I have some confusion with setup L2TP, please help my.


I will try to explain concisely about my problem:

Device                        TL-ER604W                  RUT230

------------------------------------------------------------------------------------------------------------------------

WAN:                          Public IP                        Share-public

LAN Address              192.168.0.1                  192.168.1.1

LAN Subnet Mask       255.255.255.0             255.255.255.0

DHCP                         192.168.0.100             192.168.1.100

                                   192.168.0.120             192.168.1.119

STATIC                       192.168.1.10

Mode                           Server                              Client

Tunnel                          LAN-to-LAN

Protocols                      L2TP  only                     L2TP only

Pre-Shared Key            n/a                                  n/a 

IP pool                         192.168.0.50

                                     192.168.0.60

Remote Subnet:         192.168.1.0/24

1. From client side(RUT230) I have full access to server's LAN network.

---------------------------SERVER Default Gateway---------------------------

>tracert 192.168.0.1

Tracing route to 192.168.0.1 over a maximum of 30 hops

  1    <1 ms     1 ms     1 ms  Teltonika-RUT230.com.lan [192.168.1.1]

  2    59 ms    57 ms    56 ms  192.168.0.1   

OK

-------------------------------SERVER LAN IP------------------------------------

>tracert 192.168.0.100

Tracing route to KAMBANKA [192.168.0.100] over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  Teltonika-RUT230.com.lan [192.168.1.1]

  2    59 ms    55 ms    55 ms  xxxxx.xxxxx.xxxxxx.xxxxxx.com [Public IP server]

  3    79 ms    65 ms    56 ms  KAMBANKA [192.168.0.100] 

OK

----------------------------------VPN interface---------------------------------

>tracert 192.168.0.50

Tracing route to 192.168.0.50 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.0.50 

OK

2. THE PROBLEM:

Server side have only access to client LAN DG and VPN interface ?

---------------------------Client Default Gateway---------------------------

>tracert 192.168.1.1

Tracing route to 192.168.1.1 over a maximum of 30 hops

  1     2 ms     2 ms     3 ms 192.168.0.1

  2    81 ms    53 ms    68 ms  192.168.1.1     

OK

----------------------------------VPN interface---------------------------------

>tracert 192.168.0.50

Tracing route to 192.168.0.50 over a maximum of 30 hops

  1     2 ms     2 ms     1 ms  192.168.0.1

  2    56 ms    54 ms    70 ms  192.168.0.50  

OK

------------------------------Other client LAN-------------------------------------

>tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

  1     4 ms     2 ms     2 ms  192.168.0.1

  2     *        *        *     Request timed out.

  3     *        *        *     Request timed out. 

  4.    *     ....    

LOST CONNECTION

I need full access in client's LAN. At the moment is limited, why ?

1 Answer

0 votes
by anonymous
Hello,

You'll have to enable L2TP->LAN forwarding in the Firewall section of the RUT230.

Regards,
Best answer
by

I tried, but it doesn't help

by anonymous
On the RUT230, could you do a "tcpdump -i any -nn -v 'host 192.168.1.10'" from a ssh or CLI console  and try again a tracert 192.168.1.10 ?
by

SERVER side (192.168.0.104)  >tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

  1    13 ms    11 ms    15 ms  192.168.0.1

  2     *        *        *     Request timed out.

  3 ^C

THE RESULT >>>>>>>>>>>>>>>>>>>

root@Teltonika-RUT230:~# tcpdump -i any -nn -v 'host 192.168.1.10'                                      

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes                

00:13:59.027124 IP (tos 0x0, ttl 127, id 40781, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:13:59.027344 IP (tos 0x0, ttl 126, id 40781, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:13:59.027388 IP (tos 0x0, ttl 126, id 40781, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:00.527094 IP (tos 0x0, ttl 127, id 40782, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:00.527226 IP (tos 0x0, ttl 126, id 40782, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:00.527268 IP (tos 0x0, ttl 126, id 40782, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:02.026716 IP (tos 0x0, ttl 127, id 40783, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:02.026818 IP (tos 0x0, ttl 126, id 40783, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:02.026860 IP (tos 0x0, ttl 126, id 40783, offset 0, flags [none], proto UDP (17), length 78)      

    192.168.0.104.137 > 192.168.1.10.137: UDP, length 50                                                

00:14:04.032684 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.10 tell 192.168.1.1, leng

th 28                                                                                                   

00:14:04.032730 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.10 tell 192.168.1.1, leng

th 28                                                                                                   

00:14:04.034204 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.10 is-at e0:dc:a0:b4:a7:9f, length

46                                                                                                      

00:14:04.034291 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.10 is-at e0:dc:a0:b4:a7:9f, length

46                                                                                                      

00:14:20.166089 IP (tos 0x0, ttl 1, id 40787, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5931, length 72                          

00:14:23.965998 IP (tos 0x0, ttl 1, id 40788, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5932, length 72                          

00:14:27.965729 IP (tos 0x0, ttl 1, id 40789, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5933, length 72                          

00:14:31.975596 IP (tos 0x0, ttl 2, id 40790, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5934, length 72                          

00:14:31.975819 IP (tos 0x0, ttl 1, id 40790, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5934, length 72                          

00:14:31.975865 IP (tos 0x0, ttl 1, id 40790, offset 0, flags [none], proto ICMP (1), length 92)        

    192.168.0.104 > 192.168.1.10: ICMP echo request, id 1, seq 5934, length 72



==========================================================================
P.S.  In ICMP lines missing "echo reply" from client side.
by anonymous
It seems that your device at 192.168.1.10 doesn't reply to UDP traceroute messages nor reject them either... Do you have one which could be a little more cooperative, ie returns at least an ICMP reject ?
by anonymous

1. I did it and found mistake. This IP 192.168.1.10/24 doesn't have Default Gateway within device. When I added DG 192.168.1.1 ping/tracert from CLIENT side was came.

2. Strange in this situation is: 

I connect same device to server side, but like before(without DG):

 IP 192.168.0.10,

 DG n/a. 

From Client side I have full access (ping/trace/connection from TIA Portal). May be some route is non correct.

Thanks :)

P.S.

route from CLIENT side is:                            route from SERVER side is:                         

1. Client DG                                                  Server DG

2. Server Public IP                                         Client LAN destination

3. Server LAN destination