I recommend to add UPnP optionally instead of obscure and unreliable NAT punching. Most firewalls support UPnP nowadays.

Oh yeah, Master85 who tested it with me had UDP 2302-2306 forwarded at the time he could connect. When he removed the port forwarding, he couldn't connect anymore.

I switched to "Static NAT/PAT" on my firewall and then everything starts working again.

Looks like with current NAT punching methods it expects that the source port on the router equals the source port on the PC running the server.

It also affects "dedicated server" (game started with -server).

Maybe this is why every time I try to host a server I get the message "No challenge value was received from master server".

Nope that must be something different, or at least I never got this message.

I wish I knew what it was iv tried everything short of reformatting my computer. I have no problems in any other games, even Arma II/OA.

Your problem is related to your firewall. Make sure you don't block outgoing connections. But best is, if you open a topic in the BI forums, this is not a support forum here.

I wanted to note that I posted some additional finding/comments in this thread on the BIS fora: http://forums.bistudio.com/showthread.php?155454-Connecting-failed.

I want to repeat my question from the thread here however:
My pfSense NAT box chooses 59818 as the outbound port in the dynamic NAT case; in the static NAT case it would probably use the 2304 port. Because the A3 server doesn't expect this 2304 port to be rewritten to 59818, the connecting fails. The only question I'm asking myself i:, why does the server reply to a totally different port 57901 and how does it determine this port (I'm seeing ICMP port unreachable messages, so clearly this port is not (yet) opened by my A3 client)? Is it somehow calculated from the first port? If so, it isn't a simple offset.
It seems to me that the A3 server should just reply to the same port (i.e. 59818 and not the 'magic port' 57901) and all would be well. I'm guessing when the game is running these kind of ports come into play (ports above 55000> and as these can be asymmetric I could imagine the different ports). But as this is the first connection attempt to the A3 server, the server shouldn't assume that my client has reached this state yet and it shouldn't use a different port for replying! I'm still not convinced that this isn't bad design of the A3 client/server.

@logion:
The thing is, it ignores the ports you opened (2304) for the master server announcement, i.e. it publishes the port which it opens for communication on your A3 host, which is 57901 in your case. But for the sake of dynamic PAT, on your pfSense the port is translated to 59818, hence the answer comes to the wrong port.

The server determines the port it announces to the master server simply by the fact, that it is able to *choose* the port it opens on your A3 host within the dynamic port range, in your case as stated already, 57901. You can confirm this by running the command described above in my ticket on your A3 host ("netstat -a" at least).

EDIT: That port obviously changes every time you start a new server/host.

I understand that BIS decided to let the server choose the port for the client within the dynamic port range; however why this does work with static NAT and not with dynamic NAT is beyond me. In both cases the NAT box will not forward traffic that is destined to this server-chosen port back to the client behind the NAT. Unless your client opens the UDP 'connection' first or you forward the port like I did here: http://forums.bistudio.com/showthread.php?155454-Connecting-failed&p=2400328&viewfull=1#post2400328. But even when forwarding these ports on my dynamic NAT box, I still couldn't connect. As you can see, the A3 client replies with 'ICMP 192.168.1.35 udp port 57901 unreachable'; so clearly the client should be notified what client-side port the server chose (so it can open a socket) and I'm guessing this notification gets lost?

Clearly, something is broken because my NAT box translates port 2304 on my client to an other port and some A3 software instance (be it the server or the master server) is unable to cope with this. Not assuming that this static port equals to 2304 or letting the client choose all the ports (and not assume that the server can reply to any of the dynamic ports) would already be a step in the right direction. I'm amazed that so many boxes actually run Static NAT (which gives problems when 2 clients want to use the same host port) and that therefor the amount of people having issues with this is so low.

In both cases the NAT box will not forward traffic that is destined to this server-chosen port back to the client behind the NAT. Unless your client opens the UDP 'connection' first or you forward the port like I did here.

Actually, yes the NAT box will/should forward traffic back, because UDP is stateless (i.e. no serial number and syn packets). The attempt to keep state on UDP is merely a convenience or rather compatibility implementation, else there would be no way how a bidirectional UDP session could be initiated or maintained across NAT/PAT. Not sure why it wouldn't work when you forwarded the port in question, but at any rate, when you use static PAT, it works, which shows how it WOULD work currently.

I agree that it should announce the static port (2302 or whatever) if it manages to contact the server on the port you specify. There are games which are able to determine the NAT method or if the static ports are forwarded externally and then announce the correct port. A3 should use similar techniques and/or implement UPnP optionally.

This was a issue in the Alpha, 1 year ago.

Now with the newest PERF4, this has come back, we are 30-40 people and 3-4 of us have this problem with the newest PERF4, however, if we revert back, to older version there is no problem.

So whatever you introduced to the newest performance patch for the server, revert it before you put it to stable.