I tried to move my Xbox to a VLan all by itself. Everything thing works except the UPnP port forwarders that it sets up when starting the console and starting the game. I tried a trace route from that VLan and didn’t notice a “hop” from VLan to LAN to Internet, so why would the UPnP request not be routed in the same fashion? Is the UPnP only attached to the LAN interface IP? That leaves me in a bit of a bind since it is preferable to let PNP set it up as opposed to doing a broad NAT mapping.
Well, why not move everything to a VLan and leave the XBox alone on the LAN. Well, I have several devices and apps that are currently requiring one broadcast domain since they only send a 1 in the TTL. ideally, I would have a wired and wireless LAN, but I need to have some broadcast and multicast shared between the networks.
I see the custom service forwarding, but it only seems to deal with TCP ports and all of the multicast groups use UDP. I saw a post where DHCP extended option 3 helped him, but none of my clients seem to honor that setting and the VLAN gateway is always set to the VLAN IP of the Peplink (logical).
Port forwarding would work, but there are some scenarios where the Xbox will use random high port numbers. The XBox starts a forwarder for Chat on UDP 3074. Then, some games will have an in game data channel on 3075. If those two ports are already forwarded, that is when it starts going for random.
NAT mapping worked, but then other UPnP devices can’t setup their forwarders.
As you can see - I am looking forward to forwarding from a VLan. Thanks @TK_Liew for confirmation.
result: get warnings about “Strict NAT” from the game asking to open two UDP ports
result: on Balance One UI / Status / UPnP / NAT-PMP: no UPnP devices are showing up / no ports are forwarded.
Edit to add:
More settings:
Guest VLAN has Inter-VLAN routing ON, DHCP server is enabled. Captive portal is OFF
Firewall / Access rules has a rule “BlockGuestVLAN” which says “Protocoll=Any, Source=(any IP on the guest VLAN), Destiation=(any IP on the untagged VLAN), Action = Block”
@soylentgreen, thank you for reporting this. We have revisited this feature and the problem is acknowledged. A bug has been filed and engineering team will fix it accordingly.
You may consider using port forwarding for the time being. Sorry for the inconvenience caused.
I don’t even remember creating this thread - I abandoned anything that required layer 2 support from the Peplink layer 3 VLan solution. They got it to work with bonjour, but so many different vendors implement this in so many different ways - it is not a small feet to accomplish. And they have made big improvements - although kind of quietly. Somewhere in the release notes it has something to do with a remote gateway responding to its LAN IP on a WAN interface when in IP Forward mode - it may be limited to a static IP (don’t quote me on that). They don’t sound the same, but they are quite similar in spirit.
I also don’t have the Nintendo, but it would not surprise me at all if the switch only tries to open up ports under specific scenarios. Have you done a packet capture to insure that the Nintendo is actually requesting the port forwarder From the router? It may do some kind of UDP discovery of the network before it even tries. Or, it may only try when a new wireless network is added. Or maybe only at startup from a full shutdown. I hope you are able to pick up what I am putting down. Catching what I am throwing. Smelling what I am stepping in, ya dig?
If it is sending the request, it may only have a TTL of 1. The packet is set to expire before it ever gets to the primary gateway. It takes one router hop to get from the vlan gateway to the main lan gateway. A packet capture is the only way I know of to find out for sure. Warning: knowing does absolutely nothing for the frustration level. You gotta remember what network boundaries were designed to do. In all fairness, consumer based routers were never meant to have VLans. I am certainly glad they do, but the implementation on the client and server sides both have to make assumptions due to the gaps in standards as far as combining them. I don’t think there is anything specific with regards to combining NAT (has a spec) and VLan (802.1q), much less multicast layer 2 features while doing it. Your mileage may vary.
My point is, some off the shelf consumer grade gear may do this stuff, but it does it because it treats all traffic as layer 2. And only needing to support one WAN connection. Peplink is trying to do it with security mechanisms in place. Layer 2 is physical, layer 3 is logical. There are some grey areas. There are a ton of new features in this beta, that is one of the longest change logs I have seen for years. They are most definitely working hard.
Also, not trying to be in your business, but is the strict NAT type causing the game to be unplayable? Most of the time, you don’t want to be the host - and that is typically what the port forwarder allows in the games I play. It’s not so much the bandwidth of being a host, some games are just rubbish with their matchmaking, and you really don’t want to be a host in that kind of environment. Lots of ping requests from every client doing matchmaking. On a pipe like mine (3Mbps/.5Mbps) - that ruins my experience in the game.
I’m not the gamer, so possibly I’m not describing this correctly, but without UPnP, using the switch version of Warframe, you can invite people, but they can’t join you.
For Port forwarding, the online info is conflicting, with one source suggesting you only need to open up ports 1-65535 UDP Forwarding Ports in Your Router for Warframe Another source suggests only ports from 45000 up. I tried that, and it didn’t help.
This is not a big deal obviously, but since Peplink had said they thought that VLAN + UPnP was working, I’m curious if they will be able to fix it.
Thank you, we have some more information. These tests are run using Warframe on both a PC running Windows 10, and a Nintendo Switch Lite. Both were connected via WiFi to Peplink AP One Minis running 3.7.0 managed by a Balance One running 8.1.0.b02. There are two WiFi networks, the untagged one and the “Guest” VLAN for untrusted devices.
Test 1:
I have 2 WANs, and in all cases there is an Outgoing Policy set to Enforced to force the device to WAN2
First, the good news: The PC version of Warframe seems to set up UPnP on the VLAN just fine when entering the game:
When launching the game, we get a warning: “Strict NAT detected, please forward UDP ports 4950 and 4955”.
If we add Port Forwarding rules, this message goes away.
Once in the game, the game is playable, but there is no NAT-PMP or UPnP showing up.
Inside the game, if the user Invites another player to join, the person receiving the invitation can not Join, getting a “Host unreachable” message.
Test 2: I turned off all of the Outbound Policy and Port Forwarding rules, and instead set up the nintendo switch with a NAT Mapping rule to use a single unused static IP address on WAN1.
When launching the game, we still get the warning: “Strict NAT detected, please forward UDP ports 4950 and 4955”. This seems weird, shouldn’t a NAT mapping rule cover this situation? [Edit: see below, I think this is a problem with NAT mapping outgoing rules]
However, now the game works - the Switch user can play, invite others, and the others can reply and join.
In summary, it looks like this may be something weird or buggy with the Nintendo Switch implementation of UPnP or NAT-PMP? If Peplink is interested in pursuing this, you clearly need to buy Switches for all your employees but if I can do anything to help debug (packet capture, etc?) do let me know.
I just want to make sure you aren’t missing a step. UPnP only covers the port forward and does not apply the correct firewall rules. You have to permanently put an inbound firewall rule to cover the ports that will be automatically forwarded under UPnP.
Good point, but I see that your default rule is Deny, so that’s why it’s needed. Looks like my default inbound rule is Accept so in my case any further specific firewall rules aren’t necessary.
It’s my understanding that when you are behind NAT, the function of NAT functions like a default Deny rule - the router won’t forward the port inbound unless it’s got a NAT entry in the tranlastion table.
[Edit to add:] In other words, it’s my theory that NAT Mapping functions kind of like DMZ - by default all incoming connections are passed through, so long as there’s no firewall rule preventing it. I could be wrong?
Excellent. Just making sure. Like I said, I have a working open NAT on Xbox, but because I’m using a speedfusion tunnel to accomplish it, I can’t use UPnP and have to use old fashion hard coded Port forwarders. For security reasons I’m now deleting the pictures above
For my setup it’s a 4 step process
Inbound rule in Azure
Port forward in the FusionHub at Azure
Inbound firewall rule in the FusionHub at Azure
Internal Network firewall rule on my Max Transit at home
