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?
Hi, just to let you know that I’m trying to achieve the exact same thing as vvakser.
While I’m far from been a network expert as you guys, I ended up with exact same settings and getting iPhone app ActivCaptain to some how see the Garmin MFD, but doesn’t communicate properly (displaying wrong information). Funny enough, the Garmin MFD thinks it’s correctly connected as the dedicated ActiveCaptain page on it says it’s connected.
Since vvasker didn’t reply to you last message, how can I help?
My setup is very similar (except Im on a MAX BR1 Mini HW3 and my WAN port is connected to a StarLink).
Would bridging (Layer2) both LAN and VLAN would fix the issue?
Hi @fguiot, @MarceloBarros,
I experienced the same exact behavior - Garmin shows that it’s connected, but the app is not detecting the connection correctly. I’ve seen different scenarios based on whether UDP relay is enabled or not: most of the time app shows that it’s connected, but also complains that it can’t see ActiveCaptain card. I suspect that for this portion, it requires a TCP connection between the iPhone and Garmin, which will not work when routed across VLANs (see my explanations above about default gateway on Garmin).
Unfortunately, I got sidetracked and completely forgot to to grab a pcap trace before everything got installed on a boat. Since we weren’t able to figure out how to get MAX BR1 to work, i used a workaround with a separate switch blocking Garmin’s DHCP requests, and created a separate Wifi network with flat 172.16.x.x/16 address space connected to this switch.
Here is the drawing.
The intend is to have ActiveCaptain IOS app accessing the GPSMAP923, like @vvakser described. I’m experiencing the exact behaviour he described yesterday: The app is finding the GPSMAP, connect but then cannot communicate properly.
I’m happy to test any ideas, or collect logs. But I believe @vvakser already norrowed down the issue. Given he fixed the problem with an external Switch, Would it be possible to do the exact same thing with the LAN port 2 of the PepLink?
Another way to illustrated the issue:
On PepLink, I created an additional Wi-Fi AP attached to VLAN 2 (Garmin).
I know the GPSMap923 Ip is 172.16.6.62 (this is the gateway provided by internal GPSMap Wi-Fi).
I have connected my iPhone to this PepLink Garmin Wi-Fi and ActiveCaptain works as expected, and same as if I used the internal GPSMAP Wi-Fi.
Then I have connected my Mac to the PepLink Garmin Wi-Fi.
The GPSMAP doesn’t reply to ping while it’s replying when the Mac is attached to either internal GPSMAP Wi-Fi or to the PepLink Garmin Wi-Fi.
Interestingly, I found that when trying to ssh to it replied! (from PepLink Garmin Wi-Fi).
If we could ssh to it, we could for sure change some network settings, and add the route to PepLink…`
fguiot@Mac-mini-Hisse-O ~ % ssh [email protected] The authenticity of host ‘172.16.6.62 (172.16.6.62)’ can’t be established. ED25519 key fingerprint is SHA256:482jClzZxByVDNyVjr4TX93A7+iOlqvkal9/dm6t7Xs. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added ‘172.16.6.62’ (ED25519) to the list of known hosts. [email protected]’s password:
But… looking at the first sniffer packet, send by @vvakser .
I think there is a communication at multicast and this bi-directional happen, after a broadcast first level communication… Maybe I am not be clear, here.
