IP Helper Addresses for UDP broadcast VLAN traversal

I have had two important marine projects recently that have multi vendor equipment onboard (hydraulics, nav, IT, VoIP, navigation etc) that need to all be in separate VLANs from a security perspective.

However because application developers don’t typically understand networks or network security, all the smartphone and tablet based apps that the crew and guests need to use to manage these devices rely on UDP broadcast for device discovery and management.

CISCO have the idea of an IP helper address that act as a UDP broadcast proxy between VLANS.

Please please please can we add that capability to MAX devices and Switches ASAP?

4 Likes

If I understand correct, the ip helper-address from Cisco is used to relay the BOOTP and DHCP to the BOOTP/DHCP server - IP Addressing: DHCP Configuration Guide, Cisco IOS Release 15SY - Configuring the Cisco IOS DHCP Relay Agent [Support] - Cisco. It mainly forwards the broadcast traffic from the client to Unicast to the server.

If this is correct, do you think this helps?


1 Like

Its not DHCP I want to relay.

Onboard there are many electro-mechanical services that are now network connected. These often have tablet and smartphone clients. A client will join a SSID (Crew, Engineering, Owner), and run their management apps.

The apps will sent a UDP broadcast packet to their subnets broadcast address on a specific port the idea being that the devices they want to control listen on the same UDP port and all of them receive the broadcast.

This all works fine when the devices that need to be controlled are all on a flat network with the user devices (phones and tablets) that need to do the controlling.

However that is not the desired situation. We want crew and engineering, and owner to be in separate VLANs for bandwidth management. We want the navigation computer and autopilot to be in a different VLAN to the hydraulics and infotainment systems so that remote engineers from these different companies are restricted to what they manage.

So we need a UDP broadcast proxy. Configurable so that you decide which UDP ports on which VLANs get re-broadcast on other VLANs.

Do that and all my superyacht security and remote management issues go away, and I can deliver better user experience for everyone on board.

This is the most regularly used example of UDP broadcast relay online which is a good place to start: GitHub - udp-redux/udp-broadcast-relay-redux: Small daemon to relay udp broadcast / multicast packages on a different subnet.

But, if you used something like this we could even proxy the UDP broadcasts over L3 PepVPN which would mean I could run a navigation plotter here on my desk connected to an autopilot on a remote vessel and remotely pilot it… (not a typical use case, but you see what I mean).

GitHub - synfinatic/udp-proxy-2020: A crappy UDP router for the year 2020 and beyond

3 Likes

+1 for me we could use this as well. For the same reason, customers have a roku app on the wifi vlan , and video devices on another vlan. With the ip helper address we could still keep them on seperate networks , but the app would work.

1 Like

+1 for me too.

1 Like

I wanted to say I am in dire need of using this and I’m considering moving away from Peplink until this feature is enabled in their routers, as it’s paramount for making these kind of local services working with clients connected to a locally configured WireGuard VPN running in one internal service.

Hi all, we are exploring the requested feature and it has been filed.

@jvican, can you elaborate more on your used case? We need to understand how this will help with the application you used. For example, @MartinLangmaid gives a good explanation here and this helps us to understand more about the application behavior and what we can do to achieve the requirement.

Thanks.

1 Like

Thanks for requesting clarifications! Here’s my components:

  • Wireguard VPN running on computer inside home network.
  • Clients connecting to this Wireguard VPN from outside my home network.
  • Services running and accessible inside my home network.

Right now, if one of my clients connects to my network through Wireguard VPN it can’t find internal services such as Roon —that rely on UDP broadcasting to announce clients/server very much in the same line as @MartinLangmaid explained— because the server UDP broadcasts are not propagated from my home network to the VPN.

In addition to that, if I want to have devices such as Google Nest and smart plugs in a safe VLAN separate from my home network, I can’t because they also depend on UDP broadcasting (of this I’m less sure than on the first scenario).

Another appealing scenario is also providing services in one remote network connected either through pepvpn or custom VPN and allow clients in my network to access the ones outside whenever the services depend on UDP broadcasting.

Hope that clarifies the request, let me know if it doesn’t.

1 Like

In my case, I have a local Roon server running in my local network, and I’d like to be able to access it from the outside. Roon uses mutlicast to discover clients so if the network doesn’t support UDP broadcasting then I can’t stream audio from Roon to my device.

Update: UDP relay will be supported in the coming 8.3.0! We will announce it when 8.3.0 is ready.

2 Likes

Did anyone test UDP relay with sonos (both wired and wireless on a guest VLAN while Crestron on AV VLAN)?

Hey

You’re better off doing Bonjour Forwarding from Guest to AV or opposite.
That’s what we’ve done, and it works.

UDP relay we’ve used for other stuff (NMEA data streams etc…).

1 Like

Does UDP Relay apply if the use case is a Remote User Access VPN user trying to receive UDP data from a device on the yacht subnet?

We have a MAX BR1 Pro on a yacht with a NMEA 2000 server sending data on TCP 11102 and UDP 11101. Locally the NMEA stream is available via both TCP and UDP. Via the Remote Access VPN, which provides an IP on the same subnet as the NMEA 2000 server which is also the same subnet we connect to locally via wifi, data is only accessible via TCP.

I tried to configure UDP Relay but it requires the source and destination networks be different.