I’m having an issue configuring MAX BR1 Pro 5G routing/UDP NAT traversal to connect WiFi clients to a VLAN with a Garmin display.
Config:
VLAN12:
IP:172.16.200.10/16
Inter-VLAN routing enabled; DHCP server not enabled
Connected to:
Garmin network with one of MFD displays acting as a DHCP server;
– DHCP server allocates random IPs from the 172.16.74.0/16 range with 172.16.6.0 gateway (same as the DHCP server IP, so all traffic leads back to it).
– There is no way to add or change any routes on the display. It can only reach hosts on its network (172.16/16)
– When a client connects to the Garmin network, it gets an IP from the display and performs a service discovery lookup using SSDP and mDNS (UDP), followed by a TCP connection to the discovered service endpoints (displays or cameras).
Physical Port: mapped to LAN2 (access)
Untagged VLAN
IP: 192.168.50.1/24 (factory default IP)
Inter-VLAN enabled; DHCP server enabled (192.168.50.100 - 200, .50.1 gateway)
Connected to: WiFi clients via built-in AP
“Advanced” config:
UDP Relay: enabled
UDP Ports/Multicast relay for: 5353/224.0.0.251 and 1900/239.255.255.250 bidirectionally between 192.168.50.x and VLAN12;
Problem:
WiFi clients on 192.168.50.x subnet cannot access services hosted by Garmin display with the 172.16.6.0 address on VLAN12. The display does not have a route back to 192.168.50.x subnet, and there is no way to add a routing table entry.
Since service discovery is SSDP/mDNS-based, when Wi-Fi clients on 192.168.50.x issue multicast search requests using mDNS, the UDP Relay correctly relays the answer from the display located on the VLAN12, iterating its services and endpoints. After that, Wi-Fi clients try to connect to the advertised services using TCP, and these connections fail (no route back to 192.168.50.x on the display).
I tried to solve this by creating One-to-One custom NAT policies mapping 192.168.50.x/24 subnet to 172.16.6.0/24, but it didn’t help. I’m assuming One-to-One NAT works only for LAN-WAN connections and doesn’t support LAN-LAN NATting.
I also tried connecting the Garmin network to a WAN port, in which case the TCP works as designed, but the UDP Relay doesn’t, so Wi-Fi clients don’t find the service endpoints and don’t know what to connect to.
Either LAN-to-LAN NATting or WAN-to-LAN UDP relay should solve this. Am I missing another way to solve it?
P.S. Historically, this situation was resolved using “brute force” - by adding a switch with DHCP snooping (blocking) on the port connected to the Garmin network and then using one flat IP address space for all clients, including Garmin devices and WiFi clients. While doable, this presents several issues:
The Garmin network is very chatty, and unless IGMP snooping is enabled and tightly controlled, it will flood all endpoints with its traffic.
Another switch means 5-10 more watts of power draw. On a boat, where this system needs to run 24/7 to provide connectivity, avoiding the extra draw as much as possible would be best, especially if it’s sitting at an anchor on batteries/solar.
Do you see a more elegant way to accomplish this by using only the Peplink router?
Garmin IP: 172.16.6.0
WiFI Client IP: 192.168.50.92 (iPhone running ActiveCaptain app - that’s what needs to connect to Garmin MFD)
Filter pcap by these IPs. Ignore any traffic that is sent to the outside IPs (the Wan is connected and I can’t make phone stop connecting to outside hosts).
I captured traffic from the moment ActiveCaptain app is launched on the phone until it finds Garmin through SSDP and tries to connect to it using TCP. you will see a bunch of failed SYN requests to 172.16.6.0
Let me take a look… Please… Give me a few hours. Tks.
updating…
ok… filtering using ip.addr==192.168.50.92
and checking also, using ip.addr==172.16.6.0
Are you using just the WAN (internet) of the device?
and about the LAN of the device? Are in use? Only for Garmin?
Just have some ideas, here…
The iPhone and Garmin… are trying to shaking hands, using 224.0.0.251 ?!
Garmin packet 1074
iPhone packet 1076
and not able to talk one with other. (packet 873 / 877)
iPhone find Garmin (packet 1160), but Garmin, don’t answer back.
UDP Relay, not work between WAN and LAN.
It was build to work between LANs, local or under VPN.
So… To make this work… Garmin network and WiFi network need to be under LANs / VLANs side.
For the PCAP I shared, Garmin is connected to VLAN12 (LAN side), and the iPhone is connected to the WiFi VLAN, also on the LAN side. Internet traffic is routed through the cellular modem. The WAN port is not connected at all.
Garmin and iPhone can’t talk to each other since Garmin doesn’t have a route back to the Wi-Fi VLAN: the return route (172.16.200.10—Peplink’s VLAN12 IP) is NOT in Gamin’s internal routing table. The return packets don’t even show up in the trace (as you pointed out) since they are not addressed back to Peplink, and this trace only has the traffic Peplink sees (UDP + whatever traverses its LAN interfaces).
Is there a way to NAT packets from WiFI VLAN to VLAN12 (like it happens for WAN interfaces)? Or trick Peplink into doing that? The main objective here is to have a local IP on VLAN12 that NATs all IP traffic from the WiFi segment.
I know I can do this with Sonicwalls, and was hoping there was a way I’m not thinking of to accomplish it on Peplink. Wishful thinking on my part?
Interesting. From your post, it sounds like the internal DNS server on Peplink crashes or stops responding to queries, and devices go offline. An interesting test would be to use nslookup against the internal DNS (when clients went offline) and see if it responds. Then, repeat the same from another VLAN on the same router (try to connect to both DNS servers—for the second VLAN and the one that failed initially). If the server responds to nslookup, the issue is not with DNS. In that case I would start looking into any restrictions setup on the router.
Sadly, the issue is different in my case - it doesn’t work to start with. I think I’m hitting the limit of what Peplink can do, although, technically, it should be able to…
hi, @vvakser
Please…
Do you have a sniffer from you iPhone running the garmim software and both are in the same network 172.16.???.??? ?
Will be nice to have a second device, not only the iPhone.
my suspicions… I can be wrong…
Is the packet coming from 172.16.6.0 (garmin) and going to 239.254.??.?? (udp) is choose by Garmin and it is random generate by it?
