So I think I've come to the conclusion for me that it's Call of Duty that isn't working right, plus I think there might be a bug in the gui UPNP status.The app I am using to test with will also display current port forwards and I have not been using it to check for them.. I've just been using the status page.
If I create a forward without a description, it does not display in the list. According to the specs, a description isn't required. But without a description it doesn't show in the GUI status list. I've been creating them without this whole time and seeing them not show up. Also, when testing these forwards, I haven't been closing the browser window or clearing states. I think FreshTomato must be doing that behind the scenes without telling you it is..
Anyway. My test is by running nginx on my local PC (same one that runs Warzone/Cold War) with it's default web page. I create a forward using upnp for external port 8080 and internal port 80 to my local PC. Then on my phone, I turn off Wifi, and go to http://myexternalip:8080 and see if the page comes up. Without the forward, it doesn't come up. I then close that tab, clear all the states, then create the forward. I then go to that address on my phone and the page shows up immediately. Close the tab, remove the forward using the utility, clear all states, and open a tab and go to that address and it times out.
I've tried that both with a description and without, and it works. Now, this was before reading about nat-pmp. So mine is on right now. I will test again with that turned off, but for now, it does look like this is working on my config (without changing any settings like xpendable has. I will most likely try his settings as well.
The problem with the UPNP service on OpnSense (not opnsense specific issue, it's upstream) is that it expects to work on an a "dumb" switch that floods multicast. The upnp daemon never sends an IGMP Join to the switch (which, with IGMP snooping on, it expects). Since the join is never received by the switch, it never sends the <client>->239.255.255.250 traffic to the opnsense port. That is why the static join is needed -- to force sending the client upnp requests to the opnsense box.Option 2> Turn IGMP SNooping off, so all multicast is flooded:Another option is to turn igmp snooping off & make sure the clients & opnsense box are in the same vlan on the same switch.
Hi all,I have a LOT of experience with this. Are both the OPNSense box & the other device on the same switch? Are they on the same vlan? Can they ping each other directly without going through a router?
I know this thread is over a month old now, but I found a solution and wanted to report it. I believe my problem stemmed from the fact that I'm using Multi-WAN, which then requires rules on the LAN side to set a gateway group for the outgoing traffic.I have a rule above my GW Group rule that is just a generic "allow to firewall LAN IP"... but that overlooks multicast.Had to add this rule, prior to my GW group selection rule:source network: <LAN net>destination host: 239.255.255.250 [multicast IP used for UPnP discovery]Protocol: UDPPort: 1900This got UPnP functional again, at least with the handy Mac app "Port Map". I haven't tried an Xbox yet, but I suspect it will be OK too.
I am not even using UPnP and I have a PS4 working fine so far. I gave the PS4 a static IP and it's own network for easy management and allowed a bunch of port range and some outbound ports that are static. I also use a multi wan setup. Should I even bother using UPnP if I am able to make the console work without it? When I tried to make it work I didn't work.
Quote from: DoomSalamander on May 26, 2021, 03:00:20 pmI am not even using UPnP and I have a PS4 working fine so far. I gave the PS4 a static IP and it's own network for easy management and allowed a bunch of port range and some outbound ports that are static. I also use a multi wan setup. Should I even bother using UPnP if I am able to make the console work without it? When I tried to make it work I didn't work.Sounds like you've manually done what UPnP should do automatically. It's up to you if you'd rather UPnP do it or you continue manually as you have. Sent from my IN2025 using Tapatalk
Quote from: FullyBorked on May 26, 2021, 03:04:02 pmQuote from: DoomSalamander on May 26, 2021, 03:00:20 pmI am not even using UPnP and I have a PS4 working fine so far. I gave the PS4 a static IP and it's own network for easy management and allowed a bunch of port range and some outbound ports that are static. I also use a multi wan setup. Should I even bother using UPnP if I am able to make the console work without it? When I tried to make it work I didn't work.Sounds like you've manually done what UPnP should do automatically. It's up to you if you'd rather UPnP do it or you continue manually as you have. Sent from my IN2025 using TapatalkI have set it up for a friend that shares the internet with me and he is only using a few games. Doesn't UPnP also do automatic port forwarding which can be pretty dangerous? I am just wondering which solution is more secure.
Then I wonder why the PS4 is even working because I haven't set up a single port forward rule yet. I only have rules on the network the PS4 is and very few ports on the outgoing NAT side that are static.
Quote from: DoomSalamander on May 26, 2021, 03:25:41 pmThen I wonder why the PS4 is even working because I haven't set up a single port forward rule yet. I only have rules on the network the PS4 is and very few ports on the outgoing NAT side that are static.Maybe you haven't played anything yet that requires port forwards? That would be my only thought. Not every game requires a port forward. Usually peer to peer games do, but dedicated server games or single player titles do not. It's mostly rare at this point that I hit games that require it. Warframe for example does require UPnP to function correctly since it's peer to peer.