1

I'm trying to make SMA LCS tool work through openVPN.

Context

The hardware Inverter Manager permits to manage the inverters. The LCS tool, is the only windows application (no other OS) which permits to interact with the inverter manager. It's the way I can get extracted data from the solar plant generation I need, and don't want to go on LAN each time I need to get them.

On the LAN of a solar plant, I have a GSM router which doesn't have a static IP (LAN IP 192.168.0.1). I have a raspberry Pi on the plant which makes me able to connect remotely to the LAN with reverse SSH. The LCS tool seems to:

  1. Discover the the inverter manager through sending every 20sec a broadcast packet as I saw with wireshark on UDP port 1414, first I don't understand why it does it through this port, the inverter manager is a linux machine on a Moxa. enter image description here
  2. Then it seems to send requests to the postgresql database (I don't have the credentials of course) to export the data to a CSV.

Tried

  • To map with ssh tunnels on another linux machine of my office LAN the postgresql, ssh and 1414 ports, which seem to be the ones used by the LCS tool, it doesn't work, I don't get any device into the LCS tool
  • Create an openVPN connection with an openVPN server on the raspberry Pi and an openVPN client on the windows 10 office machine (172.16.10.155). This is working through a tunnelled SSH TCP connection on port 1194 (ssh -L 1194:localhost:1194 my_plant_rpi). Unfortunately, when doing that, the LCS tool is still sending the broadcast requests to the LAN of my office's interface AND subnet. I tried to set a bridge as suggested in some posts, but more than disconnecting my plant connection after closing it, It didn't work more than that either.

Any idea * how to manage that the windows machine of my office could be more seen as into the LAN of the plant? * Or how to make the LCS tool able to discover the inverter manager which has the 192.168.0.68 IP into the LAN of the plant through the win10 machine of my office?

I'm really lost on the solutions or ways to do that...

Thx in advance, any help or suggestion would be greatly appreciated.

Improve this question
5
  • 1
    using SSH tunnels you can forward TCP traffic, not UDP. That's why the first solution didn't work
    – Silvio Massina
    Commented Oct 9, 2019 at 16:34
  • thx, any idea how I can forward UDP traffic?
    – Philippe Gachoud
    Commented Oct 9, 2019 at 23:53
  • bridging is the right path. Please notice that on the remote side the tap interface has to be bridged with the lan interface
    – Silvio Massina
    Commented Oct 10, 2019 at 13:12
  • Do you can add a NIC inside your work computer ? As I would put another device from there, that make the vpn tunnel to make a open bridge, thus that second NIC inside your PC would be bridged to that remote LAN.
    – yagmoth555 ♦
    Commented Oct 10, 2019 at 13:18
  • Thx @yagmoth555, could you point me out some doc I can consult to do something like that?
    – Philippe Gachoud
    Commented Oct 11, 2019 at 0:11

1 Answer 1

Reset to default
0

Based on your description, the LCS tool needs to access the remote LAN as if it were on the same network segment (the inverter managers are discovered using broadcast packets).

This requirement rules out a routed VPN and can be satisfied with bridging as you started to explore.

You'll need to:

  • configure openvpn so that it uses a tap interface (if you are forced to access OpenVPN via an SSH tunnel, you'll have to configure it in TCP mode)
  • on the remote side (raspberry), the OpenVPN interface (tap) has to be bridged to the LAN, which means:
    • instead of the current LAN interface you'll have a bridge interface (with the ip address that was on the LAN) and the LAN interface will become a member port of the bridge
    • the OpenVPN tap interface has to be added as a member port of the bridge. This can be done either dynamically with an up script or creating a persistent tap interface and adding it to the bridge

With this setup, when the Windows OpenVPN client is connected, its interface will behave as if it was directly connected to the remote LAN. Give it a free IP address on the 192.168.0.0/24 network. If the LCS tools does the discovery on all the network interfaces, it should find the remote device.

Improve this answer
7
  • Many thx, the point is on windows 10 that the broadcast packet is sent on only one interface which would be the local interface (in my case 172.16.10.255 => ethernet adapter 2) and should be relayed to the VPN interface which is not the case... do U say that its enough to configure the VPN server so that the windows client could relay the broadcast UDP traffic?
    – Philippe Gachoud
    Commented Oct 11, 2019 at 0:09
  • When you did the test, was the OpenVPN interface connected, with an IP address on 192.168.0.x/24, and were you able to ping successfully devices in the remote site?
    – Silvio Massina
    Commented Oct 11, 2019 at 9:39
  • 1) yes, it worked, as I did the VPN through TCP mode of openVpn. 2) I had a problem doing the TAP interface (openvpn.net/community-resources/ethernet-bridging) it was not working with the V3 client on windows tap not supported and with V2 it was not working with a password and didn't know how to configure the password, or making it ask for it (openvpn.net/client-connect-vpn-for-windows). When I stopped the bridge, with sample-scripts/bridge-stop, it disconnected my reverse ssh tunnel and had to wait for a power failure 1 week later to have it back...
    – Philippe Gachoud
    Commented Oct 11, 2019 at 9:40
  • 1
    Here: stackpointer.io/network/ssh-port-forwarding-tcp-udp/365 you can find some info on tunneling UDP through ssh, using socat (on both sides of the connection). You can have a try, using the linux machine you have in the office. I would not bet that it works, but it's easy to give a try
    – Silvio Massina
    Commented Oct 11, 2019 at 12:54
  • 1
    If the socat way doesn't work, I'd test again openvpn starting with a minimal config, In my case (linux/openvpn 2.4.7) that is, on server: dev tap, proto tcp-server, port 1194 and on client: dev tap, proto tcp-client, port 1194, remote w.x.y.z
    – Silvio Massina
    Commented Oct 11, 2019 at 13:26

You must log in to answer this question.

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