1

I have a problem with the following setup: A friendly local business has a time stamp clock on site A. This clock provides data via an integrated ftp server. Also on site A: a Raspberry Pi 3 running Debian Wheezy acting as OpenVPN server. Port forwarding on the router was set to enable VPN and SSH connections from the internet via a dynamic DNS address. This enabled users from site B, where the payroll accounting magic is happening, to first establish a tunnel to site A's network and then fetch time stamp clock data with the help of a proprietary Windows software using the (active) FTP protocol.

It all worked fine until they switched their internet provider. The new router (to which I don't have access) was set up identical to the old one with all clients on the network having the same IPs – and the same port forwarding settings as well. After the switch, I still can SSH into the raspberry, open a tunnel to site A's network, and ping the time stamp clock. But whenever I try to fetch the data via FTP (no matter if I try it with the proprietary software from the manufacturer or with a standard FTP client), I errors like "LIST requested action not taken" or something similar.

My guess is that this somehow is an active FTP protocol problem where the answers from the time stamp clock are not routed back through the tunnel properly. But this is just a guess – and I have no idea how to debug and fix this. Maybe anyone here does? Anything that hints me in the right direction is highly appreciated!

Thank you and greetings from Germany!

6
  • 1
    The new router, contrary to the claims made, is almost certainly not setup identically to the old one. Have the ISP, or whoever did the setup and made the false claim, to fix it.
    – womble
    Apr 15, 2019 at 6:45
  • But how can FTP be blocked if the tunnel is otherwise working? I just don't get my head around that.
    – Jürgen
    Apr 15, 2019 at 8:13
  • 1
    The information you have provided is not enough to troubleshoot the issue. If it was working before, and not working now, there must be something that changed. Comparing the new settings with old one would be the first step to start troubleshooting.
    – Abu Zaid
    Apr 15, 2019 at 10:29
  • OpenVPN and FTP settings are identical (as they haven't changed). All I did was updating the raspberry in the hope that this would fix things. I have no router access; I assumed – as SSH and VPN tunnels are working – that the configuration here is okay. But I don't know how I could possibly verify that. Is it technically possible that the router forwards the tunnel correctly but prevents FTP from working? How? As you might have already guessed, I'm not an expert, so sorry if these are dumb questions – I just don't understand what is going on here.
    – Jürgen
    Apr 15, 2019 at 13:34
  • That would be difficult to answer. FTP is complicated than ssh. Without router access, your options are limited. You can try to run Wireshark/tcpdump and analyze the traffic, see if the connection is established, authentication is working, and so on. You will need to have good understanding of a working ftp session, and then if you see the issue is with Network (traffic is not making through), present it to your new service provider.
    – Abu Zaid
    Apr 15, 2019 at 16:34

1 Answer 1

0

The problem that happens sometime is the following: say that:

Site A's LAN is 192.168.1.x and RaspberryPi's LAN address is 192.168.1.10 Time clock's LAN address is 192.168.1.11

Now RaspberryPi hands out OpenVPN addresses to it's clients (site B, say using 10.1.2.0) so: SiteB's client has 10.1.2.5 and RaspberryPi itself is set as a server as 10.1.2.1

What happens now is that RaspberryPi routes the 10.1.2.0 traffic to 192.168.1.0 network allowing you to access the time clock. So far so good (i assume this was never touched). This 192.168 traffic is then handled by the LAN router to reach the time clock.

The problem happens when the LAN router sometimes see the packets as coming from RaspberryPi's 10.1.2.0 address instead of 192.168.1.10 address. So, it sends the packet to the time-clock but the responses are routed to the regular Internet gateway instead.

The solution for that is to have a static route on the LAN router which sets RaspberryPi 192.168.1.10. as the gateway for all 10.1.2.0 traffic.

The other solution which i hate to suggest is to setup an open VPN client on the time clock that connects to the RaspberryPi bypassing the LAN router issues altogether.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .