@GettCouped:

Firewall rules were set up according to specified.

By this, do you mean that the Firewall rules for the LAN Interface that the PC is connected to were setup per Ubisoft AND the Firewall/NAT/Port Forwards were also setup to forward the unsolicited inbound to the PC and added the corresponding firewall rules?

Do you see any blocked packets in your firewall logs on your WAN interface when you start up the game?

Also, what uPnP port is your PC getting?

Probably be good to post some screen shots of your config.

Step 1. DHCP Static Mapping
Step 2. Outbound NAT rule & mapping order (put it at the top)
Step 3. NAT Port forwards
Step 4. UPnP Config
Step 5. Firewall rules

At a minimum, your firewall rules should allow traffic to port 1900 for the uPnP SSDP discovery broadcast, and to port 2189 to talk to the miniupnpd server

Also, to diagnose this, you can either do a Diagnostics - Packet Capture on your PC and comb through the capture to map out your traffic OR setup a Floating Match rule to log all traffic in & out of your PC into the firewall log.  Then correlate those to WAN block/pass events.

Here's what I found with ours;

The XB1 running CoD sets up a Demonware port in UPnP and makes a connection to the Demonware (Activision CoD) server using the server port 3074 as the destination.
However, Demonware then makes a separate connection from a different server on server port 3075 to port 3076 on your public IP address.  It only does this once.  pfSense CE's normal behaviour is to block this unsolicited traffic.

As soon as I created a NAT forward source: Any:3075 destination: WAN address:3076 to the XB1 & the associated firewall rule, I got open NAT in CoD. (Now of course I changed Any to the Demonware IPs for better security, but this was just for the test)

So it seems,
If you are not forwarding (nor permitting in the firewall rules) port 3076 to your XB1, you will get NAT type moderate in CoD.
If you are forwarding (and permitting in the firewall rules) port 3076 to your XB1, you should get NAT type open in CoD.

Of course, this Demonware/Activision server configuration/behavior means that only 1 XB1 can get an open NAT type in CoD due to the NAT forwarding of port 3076 to only 1 XB1.  We have multiple XBox's & PC's, so only 1 XB1 can get an open NAT type in CoD.

In your case, you might want to verify that you have a NAT forward & permit rule of inbound WAN destination port 3076 to your PC.  In fact, I would suggest logging this traffic so that you can see the inbound successful connection.  Because if you don't see the inbound packet at all,  it means it's being blocked farther up your WAN (like your ISP)

Also, feel free to post a screen shot of your Status / UPnP&NAT-PMP page while the game is running (which should show your Teredo port & your Demonware port).

I'm not really sure on how DS2 runs in relation to using the internet. But my understanding was that if you aren't doing any kind of PVP, there is no ping involved in how you interact with NPC's.

This doesn't seem like a ping issue?

Have you tried running ping on other websites to see what your numbers were?

If you have other games on steam I know some games will show you what your ping is in game. Might want to check that out if you can?

@Isegrim:

I have a moderate nat on my ps4 and every other system, it depends on the game though, some games report an open nat despite the ps4 saying NAT Type 2 in the network section.
I did what most of the other users did: enabled upnp, static port and set up the necessary nat outbound rules. it works fine for me, i have no issues with VIOP, chat or connecting to games.

I have all that in place now as well but I recieved an Open NAT (some problems with my NAT type with Call of Duty games) but I read that having a Moderate NAT type can be expected with how pfSense works, and in other cases people will say they have a harder time getting connected to games.

Hello am new here, i also encountered this issue.

Just an observation, static ports are for outbound source ports, not what you want, you want to port forward inbound destination ports. (which technically would be outbound source ports on the replies the destination port would be what they sent in on and if you start rewriting that you are going to break the traffic at the firewall their end)

Did you ever get this resolved?

We have similar goals. Here is a link to my post

https://forum.pfsense.org/index.php?topic=123086.msg679804#msg679804

Your help will be greatly appreciated.

All think allright, os server oldest.

Novice question:  If I'm setting up a MineCraft server (on a separate FreeNAS box) located on my local LAN and I want others (i.e. my kid's friends) to be able to access the server from WAN, then this is the setup to use, correct?

Thanks!

It only works for me with manual outbound nat with per device static port entries in the outbound nat rules for allow any udp to that device.  I could make it more secure but I have a "gaming" subnet with more lax rules.

I don't know if you still need help, but, First, I wanted to say that I was going to bridge the connections on my system, I found several posts saying basically "Shame on you, bridges are bad" and after researching, yes, bridges are bad. They are forcing software to act like a switch, which will never work as well as a switch. What most people DON'T tell you, ( I think they expect you to work out) is that the only thing stopping your other networks (subnets) from communicating is the firewall rules (or lack thereof) for that interface, I duplicated the default "Lan to any" rule on my second network, because I wanted that network to be able to communicate, and it worked fine, it does mean doing every firewall rule twice, but it works! So consider doing this.

If you want to be a bridge troll (kidding) them I do have one question. PFsense filters traffic in the interfaces that are bridge members by default, NOT in the bridge itself, you can change this behavior, if you edit some lines in system tunables. Here is the quote from pfsense docs

By default, traffic is filtered on the member interfaces and not on the bridge interface itself. This behavior may be changed by toggling the values of net.link.bridge.pfil_member and net.link.bridge.pfil_bridge under System > Advanced on the System Tunables tab

Has this been done?

I copied this config set by set, for my two Xbox ones. Now I don't get any NAT as my Xbox cannot get a Teredo IP

Can you do ipv6 with your isp?  The xbox one supports ipv6 and is currently the only console to do so AFAIK.

IPV6 would solve these issues for you.

They use P2P - and yes it can "destroy" your cpu if you're using proxy and anti virus.
I only have 150mb down and it was only saturating 90mb at it would shoot my cpu to 100%.  Once I turned of the AV (which I assumed was only scanning port 80 and 443) the cpu went back down to nearly nothing.  However, I have very bad nics which are being replaced today.
Bad nics can destroy your cpu when you're doing high traffic over a ton of simultaneous connections.
You should only experience this when downloading the game not during gameplay.
Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz

@arsenic32:

I actually found the opposite to be true in practice. When I used UPNP and randomized outbound ports, my xboxs reported a moderate nat, but were able to play together in multiplayer games.

When enabling static nat, one xbox was able to join multiplayer games (with open nat) while the other 3 could not. I suspect that the xboxs are accessing static ports that are not reported to UPNP, and therefore all of the packets for that port are being routed back to a single box. With the random source port nat, the router was able to assign a different port for each xbox so the return packets were able to reach the correct xbox.

I'm not sure if there is a way to tell pfSense to only randomize packets that have the same port, but different lan addresses. If that would even solve the issue here.

Right.  The order of setup should be UPNP by itself.

If that doesn't work then port foward/nat forward.

I'm sure one setup doesn't work for everything.

You might get more attention to your issue if you post it in the Traffic Shaping forum.

@Navok:

The ingame ping value is determined by calling/"pinging" battlelog.battlefield.com via Port80/443

Had the same problem on our 400+ people Lan Party. Firewall was set up with TrafficShaping/QOS optimized for gaming. Even they could play without any lags, the ingame PING shows something with 1000ms and above and player get kicked for high ping after a while. Later we discovered that the client doesn't use ICMP to discover the ping. Instead the ping was high because port 80/443 was "punished" in traffic shaping/QOS. After prioritize battlelog.battlefield.com in QOS/TS the pings was good again.

Hope this helps.

Hi, would you mind explaining how you did that ?

Thanks !

Doesn't play well with my xbox one or computers with steam.  Works great with my mac, though.

The NAT forwards are enough.  I've just turned off uPNP.