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.

RUT240 blocking outbound ?

0 votes
1,876 views 8 comments
by
I'm setting up a RPi behind RUT240 on LTE with wireguard on the RPi.

It all works well until my RUT240 gets a new external IP. Then no package is received at my other peer.

Then I have to manually restart the wg service on RPi and it works again.

Can my package be blocked in RUT240 ? I have run tcpdump on ssh in my RUT and it seems that both eth0 and wwan0 is reporting packages being sent to the right destination.

6 Answers

0 votes
by anonymous
Hello,

If I understood you correctly, your RPi does not loose connection when the IP changes, but Wireguard stops working. And you said that you can see those packages being delivered. That makes me believe that there might be an issue with the Wireguard software you are using. It would be great if you could download troubleshoot file from the router when it is fully working, when you are having issues and then send me those via private message. You can find it at SYSTEM > ADMINISTRATION > TROUBLESHOOT section.
0 votes
by anonymous

Now I´ve been digging deeper and have more patience explaining smiley

I'm infact using a RPi behind RUT240, the RPi is connected to LAN and the RUT240 via cellular/LTE. Everything operating as it should.

On the RPi I'm desperately trying to set up Wireguard and have a simple working setup with this. Trouble arises whenever the router get's a new IP from the operator. Regardless of me turning off/on mobiledata or the router reboots. Then the Wireguard handshake via UDP fails.

So I have been troubleshooting myself as this should be something Wireguard can handle without problem (a loss of connection behind NAT).

Doing tcpdump -i wwan0 'port MY_PORT'  on my router via CLI when everything is good gives me:

08:05:09.816507 IP EXTERNAL_IP_OF_ROUTER.34041 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328: UDP, length 32

Then when it fails, the same tcpdump command (verified at AWS end, no package is arriving):

08:10:09.671507 IP RPI_HOSTNAME.lan.45167 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328: UDP, length 148

What can this tell me ? Why is the origin in the packet now suddenly the hostname of my RPi and ".lan" instead of the external IP of router as seen above in first example ? Is this a routing issue in the router, or is it wireguard using the wrong interface or routing ? Could it be a firmware issue in the router about handling routing between eth0 and wwan0 interfaces ?

The only thing I can do to resolve this is manually restart the wireguard service and then it kicks in instantly. Wireguard seems to work by UDP hole punching which I have yet to understand fully.

by anonymous

Try using Bridge mode at least for testing purposes. This way all the traffic is going to travel directly to your RPi and you will see whether the issue persists or not.

You can find more information here: https://wiki.teltonika-networks.com/view/RUT240_Mobile#Bridge_mode

Let me know how it goes!

by anonymous

Works perfectly in bridgemode. Reboot, new IP and Wireguard is instant up.

So basically, wireguard other end (other peer, the one at AWS) is indeed accepting a new connection from new IP.

And yes, I have verified before when it was failing that no packet was arriving at AWS even though tcpdump showed packets being sent from behind/within (?) my RUT240 network. I'm no expert so I dont know if there is some other way to see if a package really is exiting my RUT240.

I've been searching for logs to see if RUT OS is blocking some traffic but been unable to find such logs, even in CLI.

Something is happening in my router, NAT tables, SNAT ? DNAT ? UDP block ? suspected/invalid packets being dropped ? LAN/WAN interfaces not being updated as they should on IP change ?

by
I've managed to view iptables in router and found out that there is a pre and postrouting being done on my RPi with reference to wireguard ? It says wireguard in the end of the line in iptables.

The prerouting seems to add hostname as masquerade and the postrouting seems to masquerade lan outgoing from RPi to external IP number.

Not that it explains things but I thougth I would let you know at least. Going back to my previous post it might shine some light on things as there was two different tcpdump results when it was working or not (hostname to aws or external ip to aws)
by anonymous
We are planning to release Wireguard support on our devices soon. Would you be interested in that, or you really want to use RPi?
by
I´ve read that. But isn´t it supposed to be supported only on devices with packagemanager ? Like more expensive routers, not the RUT2 series ?

I'd probably go with using Wireguard on the router instead of behind the router but I'd really like to troubleshoot and understand the mechanism in why it is failing.

Is this not possible ? Read logs of the firewall for example ?
0 votes
by

I've been thinking.

Scenario:

1. Working Wireguard VPN connection from client behind RUT240 to cloudserver
2. Router get's a new external IP during reboot or mobileoff/mobileon.
3. Wireguard stops being able to do handshake to cloudserver from client behind RUT240 NAT.
4. tcpdump on RUT240 CLI shows packets being sent like this: RPI_HOSTNAME.lan.45167 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328: UDP, length 148
5. tcpdump on cloudserver is silent, no packet arriving from client behind NAT on Teltonika RUT240 router.
6. Examination of iptables in router from CLI shows PREROUTING 192.168.0.1/24 > RPi_hostname and POSTROUTING 192.168.0.1/24 to EXTERNAL_IP_OF_ROUTER (which is correctly set to the new ext ip)
7. Restart of Wireguard software on RPi.
8. tcpdump on RUT240 CLI shows packets being sent like this: EXTERNAL_IP_OF_ROUTER.34041 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328: UDP, length 32
9. Handshake is successful.

Correct me if I'm wrong but a packet being sent out with source set to "RPI_HOSTNAME.lan" will never be delivered on public adress space ?

So my conclusion is that something is wrong around my point #4 above in the implementation of iptable in the router as it is not applying the POSTROUTING chain that infact is present in iptables during the tcpdump.

by anonymous
Hello,

I will need you to download the troubleshoot file from the router when everything is fully working and when it stops working. Also I will need you to create TCP dump files when everything is fully working and when it stops working. You will find TCP dump settings/file and Troubleshoot file at  SYSTEM > ADMINISTRATION > TROUBLESHOOT section.

In order to create TCP dump file, you will need to enable it (interface: any; protocol: all; direction IN/OUT; storage: internal). Then initiate connection and only then download it.

When you are done, switch TCP dump feature off.

Send me all of those files via private message.

P.S. Wireguard will be available on RUT2xx devices.
by
Very good news that support is coming to RUT2XX devices!

So, I just booted up my device again after some days spent in rest, the device was still in BRIDGE mode so I turned it off.

After this event, I have not been able to reproduce the error any more, reboot, new external IP etc, it seems to put the IP right on outgoing traffic from Interface WWAN0 and when this happens, handshake is successful.

I can not understand what has changed...other than me putting the RUT router in bridgemode and then back to NAT.

I have sent you the troubleshoot and tcpdump file anyway.
0 votes
by anonymous

Very good news that support is coming to RUT2XX devices!

So, I just booted up my device again after some days spent in rest, the device was still in BRIDGE mode so I enabled NAT mode again.

After this event, I have not been able to reproduce the error any more, reboot, new external IP etc, it seems to put the IP right on outgoing traffic from Interface WWAN0 and when this happens, handshake is successful.

I can not understand what has changed...other than me putting the RUT router in bridgemode and then back to NAT.

I have sent you the troubleshoot and tcpdump file anyway.

0 votes
by

Hi again, I'm still having this issue and it is most certainly pointing towards the RUT240's handling oft NAT translation och NAT table. Whenever the LTE modem/router renews the external IP or gets turned off for a while the handshake to my WireGuard server on a virtual machine from behind the LTE router with an RaspberryPi over UDP fails. Can you please help me troubleshoot this.

As I can recall, doing tcpdump on WWAN0 it transmits this "IP RPI_HOSTNAME.lan.45167 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328: UDP, length 148"

But nothing is delivered to my virtual machine on the AWS cloud.

0 votes
by

Hi Justinasm! I just bought a brand new RUT240 because the one we put away in remote area stopped reporting back to us. I bought this to be able to get to the bottom of this firewall issue.

So now I have reproduced the issue and it has indeed to do with the Teltonika firewall. I would say (as not an export though) that it is failing to do the MASQUERADE correctly after a reboot of the router while keeping the client (computer) behind the router running. I will try to summarize what happens.

1. Brand new Teltonika RUT240 with FW ver. RUT2XX_R_00.01.12.3
2. SIM with Mobiledata inserted.
3. No user settings.
4. Firewall is active as per default.
5. PC (with Ubuntu) connected to LAN with WireGuard installed and simple configure to connect to VM server in the cloud on fixed IP.
6. All good and well, WireGuard is doing handshakes and working as it should.
7. tcpdump -i wwan0 'port 54328' gives me: EXTERNAL_IP_OF_ROUTER.34041 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328
8. Reboot of Teltonika.

9. Suddenly connection to WireGuard stops.
10. Same tcpdump command gives me: HOSTNAME_OF_COMPUTER.lan.45167 > ec2-MY_AWS_IP.eu-central-1.compute.amazonaws.com.54328

11. Sure this gets dropped or at least will not return on the public internet.
12. Doing /etc/init.d/firewall stop and later /etc/init.d/firewall start over Teltonika CLI as root turns everything back to normal.

I hope this is a software problem in the Teltonika which can be adressed ?

I have sent you the troubleshoot and tcpdump files when working and when not working. Hoping for a quick answer.

by anonymous
Clarification about #10 above: HOSTNAME_OF_COMPUTER is like the internal ip of the computer behind the router 192.168.1.109.