WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
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.

TRB140 port forward not working

0 votes
981 views 28 comments
by anonymous
So I finally have a sim with public static IP and I can ping the router on this IP.

The whole rational for the router is to allow port forward on port (say) 45123 to a PC on the lan (say) 192.168.1.7.  I have implemented the port forward rule:

Name: MyPortForward

Protocol: TCP

Source zone: wan

... any ...

External port: 45123

Internal zone: lan

Internal IP address: 192.168.1.7

Internal port: 45123

Saved and enabled.

There is no specific protocol, it is just a plain TCP socket connection.  I have implemented this rule many times on terrestrial routers of all types without any problems.  I get the feeling something in the firewall is blocking the connection out to the lan but I cannot be sure.  Surely just setting up the port forward will do whatever else is necessary ? or have I missed something ?  Spent all day on it now !

Many thanks for any help.  I am now going for a walk to clear my head !
by anonymous
So I gave up late last night; this morning I reset the TRB140 to factory defaults, then set the LAN IP and disabled DHCP in the initial log-in.  I configured my port-forward as described above.  Still no luck.

I have banged off an e-mail to the sim card people to check that they are not blocking anything, but I think not..

I set up a route on my PC to the WAN public address via the TRB140 lan ip so that traffic to the public IP would get bounced back (a technique I have used a lot) but STILL no joy.  What can I be doing wrong ??
by anonymous
Still no luck.  Although the modem said it had the latest firmware installed, it seems it didn't, so I updated it (to TRB1_R_00.07.02.1).  Reset to factory default and set up as above.  Still no port forwarding.

I have a test setup in the workshop consisting of the TRB140 with sim with public static IP (which I can ping), with static lan address 192.168.1.98.  I have a PC on 192.168.1.7 which is running SSH server on port 45123 (port 22 disabled).  I have another PC at 192.168.1.100 with the modem as the default gateway.  To recap, the modem has port-forward on port 45123 to 192.168.1.7 port 45123, and Enable NAT Loopback is ON.  (Not that it should make any difference but for info the only default setting on the modem that I changed is to turn DHCP off, as all assignments on the lan are static.)

I can SSH from modem CLI to the SSH server on 192.168.1.7.  But I cannot get to same from the other PC, using the public IP (which in any other router is 'NAT loopbacked' internally), nor from an unconnected PC via the Internet.

Port forwarding is such a basic operation that I have carried out countless times that I find it difficult to understand what might be wrong.  I can accept that there might be a problem with the SIM provider blocking ports and I have not yet had a reply (although there is no other evidence of this), but even if this were the case, the attempt from the PC via internal routing should (and in any other router would) work.

I cannot believe there is such a fundamental problem with the TRB140, but I am struggling to find an alternative explanation.

All help welcomed - I championed the TRB140 for an upcoming project based on its spec and my initial impression, but now I am beginning to look silly.
by anonymous
Still no luck.  Today I installed ZeroTier which is working.  But I cannot port-forward, I followed the instruction in the manual meticulously.

So port forwarding doesn't work for public IP, and doesn't work for ZeroTier.

Can someone reassure me that port forwarding does actually work in the TRB140 ?

1 Answer

0 votes
by anonymous

Hi Denville,

Can you try disabling the PC's firewall?
Did you change the internal port for SSH on PC to 45123? By default the port is 22 for SSH.
For testing purposes, firstly try to port forward the 3389 (RDP) protocol. For that, you need to enable RDP on the Windows PC itself.

Assign the router's IP 192.168.1.1 as a gateway in the PC's network adapter settings. Make sure that you are able to ping PC from the router and vice-versa.
Once you are done with testing, create the same scenario for SSH as well with the required port and share the results.
Please share the screenshot of the port forwarding rule that you have configured.
Here is an example of port forwarding to the Windows OpenSSH server:

Either disable the firewall of the PC for testing purposes or configure the inbound rule on it to allow traffic on port 22.

Regards,
Ramandeep

by anonymous

Thanks for the detailed answer.  I have tried everything you suggested (yes the SSH server port was changed to 45123 and 22 was disabled.  However I have re-enabled 22 and restarted the SSH server).

So the setup now is:

A Ubuntu box (UPC) running SSH server (port 22 enabled) on lan static 192.168.1.7

The TRB140 (TRB) again reset to factory defaults then to 192.168.1.1 (DHCP disabled) and sim with public IP 86.106.x.y

A Windows PC (WPC) with Remote Desktop enabled and firewall disabled on lan static 192.168.1.100 default gateway 192.168.1.1

A mac book (MAC) with RDP client which I can use either on the above 192.168.1 lan or on a completely separate internet connection - on Internet unless I note otherwise.

Ping: I can ping both ways between (TRB and WPC) and between (TRB and UPC).  I can ping TRB from MAC on Internet on its public IP 86.106.x.y. 

SSH: I can SSH both ways between (TRB and UPC) and I can SSH (Putty) from WPC to TRB (and from WPC to UPC).  I can NOT ssh in to TRB from its public IP even if I have Enable_SSH_WAN set ON.

Port Forwards:

So now I first try using RDP as you suggest.  I use RDP a lot to access the office when I am away; the MAC has RDP client set up and known to be working well in this context.  I have enabled RD on WPC and am able to RDP in to it from the MAC on the lan.

I set up a Port Forward:

(My_3389) IPv4-tcp, udp From any host in wan Via any router IP at port 3389 Forward To IP 192.168.1.100, port 3389 in lan (this being WPC). I try to access using MAC on Internet directed to Public IP - connection times out.  I note your illustration above to set External IP Address to public IP of router (86.106.x.y) and try this but with no success.

I repeat the exercise for SSH:

(My_22) IPv4-tcp, udp From any host in wan Via any router IP at port 22  Forward To IP 192.168.1.7, port 22 in lan (this being UPC SSH Server).  I try to SSH in from the MAC on the Internet (SSH denville@86.106.x.y) - times out.

At this point I suspected not the TRB140 but the SIM/Public IP provider.  So, on WPC (with its default gateway set to the TRB) I Putty to denville@86.106.x.y.  In any other router, this would be reflected back from the public interface, through the PF, to the target.  But again no reply.

Now I am suspecting not the SIM but the TRB140

This is getting a bit long so I will carry over to another comment session...

(Screenshots attached hopefully - note all tests tried with only one rule (the appropriate one) active (On) at a time.  All tests tried with External IP Address set to its default (Any) and set to the public IP as suggested.)

by anonymous
So to continue, at this point last week when doing a similar set of tests, I discovered ZeroTier; this would allow me to set up a P2P tunnel between TRB and the office without needing a public IP.  This would suit me even better than having to have a public IP.

So following the instructions in the TRB140 manual I set up a ZeroTier (ZT) account and tested its capabilities between various PC's.  I then installed and configured ZT on the TRB140 and set up the Port Forwarding rule (My_22_ZT) exactly as instructed in the TRB140 manual.

From the MAC (ZT installed and configured) (MAC on Internet), using the ZT tunnel:

I could ping the TRB

I could ssh from the MAC into the TRB

But I could still not access the SSH server on UPC using the new Port Forward.

And that is where it is completely stalled.  It is as if Port Forwarding has somehow been disabled in the TRB.

Thanks again for the interest.
by anonymous

If you use a firmware version of 07.02 or above on the TRB you may have hit a rule issue, could you try the following command:

  • ip -4 rule delete $(ip -4 rule show | grep 2062 | cut -d":" -f 2)

If that doesn't work could you check with tcpdump -i any -n -v 'port 45123' that the SYN packet appears twice in the output ?

by anonymous 



root@Teltonika-TRB140:~# ip -4 rule delete $(ip -4 rule show | grep 2062 | cut -d":" -f 2) 



"ip rule del" requires arguments. 



root@Teltonika-TRB140:~# 


























 












by 
anonymous













What is the output of ip -4 rule show ?




















 












by 
anonymous













As above, when I type the command into CLI, I get '"ip rule del" requires arguments.'




















 












by 
anonymous
















No, just ip -4 rule show























 












by 
anonymous
















Sorry, forgive my understanding...






root@Teltonika-TRB140:~# ip -4 rule show 



0: from all lookup local 



32766: from all lookup main 



32767: from all lookup default 



root@Teltonika-TRB140:~# 





























 












by 
anonymous













So the ip -4 rule is not the issue. Start a tcpdump as described above and try a connection to port 45123. What is the output.




















 












by 
anonymous
















I got called away to another project earlier today.  Anyway:



Testing port forward port 45123 via sim public IP - no captures (is this a damning of the SIM provider ?)



Testing port forward port 45123 from lan side with public IP routed to the TRB140 lan (the situation where I would expect the route to be 'bounced back' and work) (it didn't):



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



16:59:25.222302 IP (tos 0x0, ttl 128, id 19556, offset 0, flags [DF], proto TCP (6), length 52)



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x3c4e (correct), seq 281631118, w



in 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0                                 



16:59:28.227465 IP (tos 0x0, ttl 128, id 19581, offset 0, flags [DF], proto TCP (6), length 52)   



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x3c4e (correct), seq 281631118, w



in 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0                                 



16:59:34.226566 IP (tos 0x0, ttl 128, id 19633, offset 0, flags [DF], proto TCP (6), length 48)   



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x5057 (correct), seq 281631118, w



in 8192, options [mss 1460,nop,nop,sackOK], length 0                                              



Now I enable ZeroTier VPN and change port forward rule (source now any host in zerotier) (still didn't work):



root@Teltonika-TRB140:~# tcpdump -i any -n -v 'port 45123'                                        



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



16:42:33.272043 IP (tos 0x0, ttl 128, id 261, offset 0, flags [DF], proto TCP (6), length 52)



    10.244.1.100.50494 > 10.244.10.98.45123: Flags [S], cksum 0x4025 (correct), seq 1639518452, wi



n 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                  



16:42:33.273112 IP (tos 0x0, ttl 127, id 261, offset 0, flags [DF], proto TCP (6), length 52)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0x93cb (correct), seq 1639518452, win



 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                   



16:42:33.273354 IP (tos 0x0, ttl 127, id 261, offset 0, flags [DF], proto TCP (6), length 52)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0x93cb (correct), seq 1639518452, win



 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                   



16:42:36.197751 IP (tos 0x0, ttl 128, id 262, offset 0, flags [DF], proto TCP (6), length 52)     



    10.244.1.100.50494 > 10.244.10.98.45123: Flags [S], cksum 0x4025 (correct), seq 1639518452, wi



n 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                  



16:42:36.198178 IP (tos 0x0, ttl 127, id 262, offset 0, flags [DF], proto TCP (6), length 52)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0x93cb (correct), seq 1639518452, win



 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                   



16:42:36.198452 IP (tos 0x0, ttl 127, id 262, offset 0, flags [DF], proto TCP (6), length 52)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0x93cb (correct), seq 1639518452, win



 8192, options [mss 2760,nop,wscale 2,nop,nop,sackOK], length 0                                   



16:42:42.222991 IP (tos 0x0, ttl 128, id 263, offset 0, flags [DF], proto TCP (6), length 48)     



    10.244.1.100.50494 > 10.244.10.98.45123: Flags [S], cksum 0x542e (correct), seq 1639518452, wi



n 8192, options [mss 2760,nop,nop,sackOK], length 0                                               



16:42:42.223398 IP (tos 0x0, ttl 127, id 263, offset 0, flags [DF], proto TCP (6), length 48)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0xa7d4 (correct), seq 1639518452, win



 8192, options [mss 2760,nop,nop,sackOK], length 0                                                



16:42:42.223662 IP (tos 0x0, ttl 127, id 263, offset 0, flags [DF], proto TCP (6), length 48)     



    10.244.1.100.50494 > 192.168.1.7.45123: Flags [S], cksum 0xa7d4 (correct), seq 1639518452, win



 8192, options [mss 2760,nop,nop,sackOK], length 0                                                



I realize there are a few repeats in there but I haven't deleted anything.



Hope this helps ?


























 












by 
anonymous













The RUT "sees" incoming SYN packets on port 45123. So far so good. Redo the test but with a tcpdump -i any -n -v 'host 192.168.1.7 and port 22'. Do you see similar SYN packets ?




















 












by 
anonymous
















(I changed the target port to 22 which I think the test requires.  Port 22 is enabled on the ssh server at 192.168.1.98.)



Via sim's public IP: As before, no data.



Testing port forward port 45123 from lan side with public IP routed to the TRB140 lan (the situation where I would expect the route to be 'bounced back' and work) (it didn't):



root@Teltonika-TRB140:~# tcpdump -i any -n -v 'port 45123'                                        



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



16:59:25.222302 IP (tos 0x0, ttl 128, id 19556, offset 0, flags [DF], proto TCP (6), length 52)



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x3c4e (correct), seq 281631118, w



in 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0                                 



16:59:28.227465 IP (tos 0x0, ttl 128, id 19581, offset 0, flags [DF], proto TCP (6), length 52)   



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x3c4e (correct), seq 281631118, w



in 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0                                 



16:59:34.226566 IP (tos 0x0, ttl 128, id 19633, offset 0, flags [DF], proto TCP (6), length 48)   



    192.168.1.100.53022 > 86.106.16.152.45123: Flags [S], cksum 0x5057 (correct), seq 281631118, w



in 8192, options [mss 1460,nop,nop,sackOK], length 0 




Now I enable ZeroTier VPN and change port forward rule (source now any host in zerotier) (still didn't work):







root@Teltonika-TRB140:~# tcpdump -i any -n -v 'host 192.168.1.7 and port 22'                      



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



09:18:12.896990 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [SEW], cksum 0xa2ce (correct), seq 2940807006, win



 65535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045384655 ecr 0,sackOK,eol], length 0      



09:18:12.897280 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [SEW], cksum 0xa2ce (correct), seq 2940807006, win



 65535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045384655 ecr 0,sackOK,eol], length 0      



09:18:13.725486 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [S], cksum 0x9fa6 (correct), seq 2940807006, win 6



5535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045385655 ecr 0,sackOK,eol], length 0        



09:18:13.725787 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [S], cksum 0x9fa6 (correct), seq 2940807006, win 6



5535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045385655 ecr 0,sackOK,eol], length 0        



09:18:14.687072 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [S], cksum 0x9bbd (correct), seq 2940807006, win 6



5535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045386656 ecr 0,sackOK,eol], length 0        



09:18:14.687364 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



    10.244.100.10.62772 > 192.168.1.7.22: Flags [S], cksum 0x9bbd (correct), seq 2940807006, win 6



5535, options [mss 2760,nop,wscale 6,nop,nop,TS val 2045386656 ecr 0,sackOK,eol], length 0        



09:18:15.965331 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 64)        



                                     




















 












by 
anonymous
















> 10.244.100.10.62772 > 192.168.1.7.22: Flags [S], cksum 0x9bbd (correct), seq 2940807006, win 6



192.168.1.7 doesn't reply to the SYN packet, expecting a SYN ACK coming back.



The direct access via SIM issue is different. What is the output of:



    


  • iptables -n -L | grep 45123
    • 


  • iptables -t nat -n -L | grep 45123



on the RUT ?























 












by 
anonymous



















root@Teltonika-TRB140:~# iptables -n -L | grep 45123 






root@Teltonika-TRB140:~# iptables -t nat -n -L | grep 45123 



SNAT tcp -- 192.168.1.0/24 192.168.1.7 tcp dpt:22 /* !fw3: My_45123 (reflec



tion) */ to:192.168.1.98 



SNAT udp -- 192.168.1.0/24 192.168.1.7 udp dpt:22 /* !fw3: My_45123 (reflec



tion) */ to:192.168.1.98 



DNAT tcp -- 192.168.1.0/24 86.106.16.152 tcp dpt:45123 /* !fw3: My_45123 (ref



lection) */ to:192.168.1.7:22 



DNAT udp -- 192.168.1.0/24 86.106.16.152 udp dpt:45123 /* !fw3: My_45123 (ref



lection) */ to:192.168.1.7:22 



DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:45123 /* !fw3: My_45123 */ t



o:192.168.1.7:22 



DNAT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:45123 /* !fw3: My_45123 */ t



o:192.168.1.7:22 



root@Teltonika-TRB140:~# 


























 












by 
anonymous













This looks correct. Could you retry withe the following tcpdump:



tcpdump -i any -n -v 'icmp or port 45123'




















 












by 
anonymous



















root@Teltonika-TRB140:~# tcpdump -i any -n -v 'icmp or port 45123' 



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



12:56:19.701514 IP (tos 0x20, ttl 19, id 0, offset 0, flags [none], proto ICMP (1), length 84) 



69.235.184.18 > 86.106.16.152: ICMP echo request, id 18, seq 22957, length 64 



12:56:19.702019 IP (tos 0x20, ttl 64, id 9825, offset 0, flags [none], proto ICMP (1), length 84) 



86.106.16.152 > 69.235.184.18: ICMP echo reply, id 18, seq 22957, length 64 



12:56:35.372505 IP (tos 0x20, ttl 233, id 62709, offset 0, flags [DF], proto ICMP (1), length 36) 



35.180.43.14 > 86.106.16.152: ICMP echo request, id 26, seq 2120, length 16 



12:56:35.372991 IP (tos 0x20, ttl 64, id 39347, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 35.180.43.14: ICMP echo reply, id 26, seq 2120, length 16 



12:56:50.449464 IP (tos 0x0, ttl 226, id 56941, offset 0, flags [DF], proto ICMP (1), length 36) 



18.181.241.9 > 86.106.16.152: ICMP echo request, id 1, seq 23334, length 16 



12:56:50.449944 IP (tos 0x0, ttl 64, id 26347, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 18.181.241.9: ICMP echo reply, id 1, seq 23334, length 16 



12:56:54.684818 IP (tos 0x20, ttl 227, id 60764, offset 0, flags [DF], proto ICMP (1), length 36) 



52.81.71.211 > 86.106.16.152: ICMP echo request, id 16, seq 20409, length 16 



12:56:54.685395 IP (tos 0x20, ttl 64, id 46591, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 52.81.71.211: ICMP echo reply, id 16, seq 20409, length 16 



12:56:58.844897 IP (tos 0x20, ttl 227, id 55479, offset 0, flags [DF], proto ICMP (1), length 36) 



54.223.180.215 > 86.106.16.152: ICMP echo request, id 1, seq 15838, length 16 



12:56:58.845497 IP (tos 0x20, ttl 64, id 15351, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 54.223.180.215: ICMP echo reply, id 1, seq 15838, length 16 



^C 






During this time I attempted to ssh in via the public IP and port 145123 as usual without success. 























 












by 
anonymous













I was expecting to see ICMP port unrechable or the like packets interwined with TCP SYN ones not echo requests/replies.



Please retry the connection to port 45123 only and the same tcpdump -i any -n -v 'icmp or port 45123'




















 












by 
anonymous













Sorry I don't understand what to retry - previously, with the port-forward (WAN:45123 to 192.168.1.7:22) I tried to connect over the internet from my MAC by ssh to 86.106.16.152 (this being the public IP of the sim).  Was / is that correct ?  Sorry to be slow, but what different would you like me to do ?



D.




















 












by 
anonymous
















The tcpdump and the ssh to 86.106.16.152.























 












by 
anonymous



















root@Teltonika-TRB140:~# tcpdump -i any -n -v 'icmp or port 45123' 



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



16:39:36.204027 IP (tos 0x0, ttl 233, id 50068, offset 0, flags [DF], proto ICMP (1), length 36)



54.252.130.8 > 86.106.16.152: ICMP echo request, id 6, seq 17415, length 16 



16:39:36.204600 IP (tos 0x0, ttl 64, id 9180, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 54.252.130.8: ICMP echo reply, id 6, seq 17415, length 16 



16:39:51.565704 IP (tos 0x20, ttl 225, id 30045, offset 0, flags [DF], proto ICMP (1), length 36) 



52.80.30.162 > 86.106.16.152: ICMP echo request, id 16, seq 4056, length 16 



16:39:51.566219 IP (tos 0x20, ttl 64, id 9967, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 52.80.30.162: ICMP echo reply, id 16, seq 4056, length 16 



16:39:51.650340 IP (tos 0x20, ttl 227, id 63417, offset 0, flags [DF], proto ICMP (1), length 36) 



52.81.226.140 > 86.106.16.152: ICMP echo request, id 4, seq 5316, length 16 



16:39:51.650794 IP (tos 0x20, ttl 64, id 9884, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 52.81.226.140: ICMP echo reply, id 4, seq 5316, length 16 



^C 



6 packets captured 



10 packets received by filter 



0 packets dropped by kernel 



root@Teltonika-TRB140:~# 























 












by 
anonymous
















Could you stop the ping at 54.252.130.8 and just execute the ssh -4 45123 86.106.16.152, and the tcpdump of course ?























 












by 
anonymous













I don't know where the ping is coming from - presumably the SIM provider ?  Nothing of mine is causing it.  (Both RMS and ZeroTier are switched off)




















 












by 
anonymous













Sorry for the typo in the ssh command it should be ssh -p 45123 86.106.16.152 ...




















 












by 
anonymous
















Understood.  But since I have no control over the ping, this will amount to the same as last time...






root@Teltonika-TRB140:~# tcpdump -i any -n -v 'icmp or port 45123' 



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



17:08:24.194651 IP (tos 0x0, ttl 229, id 22813, offset 0, flags [DF], proto ICMP (1), length 36) 



52.78.68.35 > 86.106.16.152: ICMP echo request, id 32, seq 4150, length 16 



17:08:24.195098 IP (tos 0x0, ttl 64, id 18008, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 52.78.68.35: ICMP echo reply, id 32, seq 4150, length 16 



17:08:28.122133 IP (tos 0x20, ttl 225, id 26392, offset 0, flags [DF], proto ICMP (1), length 36) 



161.189.176.176 > 86.106.16.152: ICMP echo request, id 5, seq 5110, length 16 



17:08:28.122620 IP (tos 0x20, ttl 64, id 6336, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 161.189.176.176: ICMP echo reply, id 5, seq 5110, length 16 



17:08:31.002873 IP (tos 0x20, ttl 225, id 5880, offset 0, flags [DF], proto ICMP (1), length 36) 



52.83.15.117 > 86.106.16.152: ICMP echo request, id 24, seq 18657, length 16 



17:08:31.003456 IP (tos 0x20, ttl 64, id 34251, offset 0, flags [none], proto ICMP (1), length 36)



86.106.16.152 > 52.83.15.117: ICMP echo reply, id 24, seq 18657, length 16 



17:09:09.641778 IP (tos 0x0, ttl 231, id 53620, offset 0, flags [DF], proto ICMP (1), length 36) 



15.152.212.86 > 86.106.16.152: ICMP echo request, id 7, seq 17172, length 16 



17:09:09.642246 IP (tos 0x0, ttl 64, id 13079, offset 0, flags [none], proto ICMP (1), length 36) 



86.106.16.152 > 15.152.212.86: ICMP echo reply, id 7, seq 17172, length 16 



^C 



8 packets captured 



10 packets received by filter 



0 packets dropped by kernel 



root@Teltonika-TRB140:~# 



































 












by 
anonymous













Hi Denville,



Please share troubleshoot file of the device in Private Message to me. To download troubleshoot file got to TRB140 WebUI, navigate to System->Administrator->Troubleshoot. Click on generate button to generate troubleshoot file.



Regards,

Ramandeep