Potential New XBoxLive / XBox 360 HOWTO for Review and Comment
-
Recently I set up a pfsense with an XBox 360 as one of the clients.
I aggregated everything I read, and learned quite a bit more, and
ended up with a setup that works very well.I would like to propose the HOWTO below as a sticky, after it has been
reviewed and updated based on comments.What is below worked for me, but should be considered a document in
review until "finalized."–Ray
XBox360 Setup and Tutorial
Enormous caveat is that this work was done ENTIRELY with "Call of
Duty / Modern Warfare 2." I will update this as adjustments are
made for other games.On the other hand, it is completely consistent with everything else I
have read, yet gives more information and a more closely carved setup.Microsoft and others tell you to "open" or "Forward" ports 88 and 3074.
This is both unnecessary and insufficient for pfsense if you have a
"Default Deny" rule-set. I assume that these directions are appropriate
for other routers because of router behavior that Microsoft has assumed
but not stated.This setup assumes that you want to constraint the xbox360 as much as
possible without any compromises on its activities.88 is for kerebos authentication. You have to let it out, but if you
are doing NAT then the NAT engine will generate a transient rule to
let the reponse in. No port-forward is necessary. If you put a port
forward in place then no other machine on your network will be able to
use kerebos, since all responses will come back to your XBox360!I will present the configuration required, followed by an explanation.
First, NAT / Portforward port 3074 to the XBox360 port 3074.
Second, create a Fireall / Rule for WAN allowing the portforward of
3074 to get through:TCP/UDP * * xbox360 3074
Third, NAT / Outbound
* Manual Outbound Rule Generation
Create rules for each of your subnets. Set "Static Port" on the subnet hosting the xbox360 to "Yes." My rules look like this: WAN 192.168.240.0/24 * * * * * NO WAN 192.168.241.0/24 * * * * * NO WAN 192.168.243.0/24 * * * * * YES XBox declared the connection as "Strict" without "Static Port, moving up to "Moderate" with "Static Port" Create the following firewall rules on the interface that services the xbox360: TCP/UDP ABC_Net * IF IP Address 53(DNS) TCP/UDP ABC_Net * !IF IP Address 53(DNS) TCP/UDP ABC_Net * * 80(HTTP) TCP/UDP ABC_Net * * 88(KEREBOS) TCP/UDP xbox360 3074 * 1024-65535 TCP/UDP ABC_Net 1024-65535 * 3074 Now for the explanation. Off topic, but I block use of external DNS servers. 3074 is used for all communication, but in various ways. During play, all communication goes out through 3074. Some other players appear to receive their incoming communication only on 3074, others on apparently random registered and dynamic port numbers. A single one minute trace contained ports from 3976 to 63789. You can block outgoing traffic except for destination ports 88 and 3074 and receive an "Open" rating when you run the XBoxLive connection test, but as you play, there will be many outgoing packets going to registered and dynamic ports that are blocked. You seem to be much harder to kill. The hypothesis is that those outgoing packets are reporting your death, and that the players with the ports other than 3074 cannot learn of your death. All outgoing communication during play originates on port 3074. If you move the 3074 requirement from the destination to the source to restrict your xbox to sending on 3074 but allow it to send to any port, then you will be able to send to all other players. You will be able to play fine, an examination of your Firewall log will not show anything blocked, and Packet Capture will not show any packets being sent to anything you have blocked. However you will find that your XBoxLive network test now fails, saying that your MTU is too small. This is not true; the xbox' test sends from ports 1258, 1259, maybe 1257, and less likely 1256. Those packets are blocked from going out. So Microsoft is testing on ports not being used for play, and playing on ports not being used for test! It appears that the use of registered ports is anarchy, except in all observed cases either the source or destination was port 3074. Short of openning everything wide, allow source (xbox) on 3074 or any registered (1024-49151) or dynamic ports (49152-65536) ports with destination to port 3074. In my mind this is pretty stupid, but at least it prevents your XBox from sending to non-allowed well-known ports. TCP/UDP ABC_Net 1024-65535 * 3074 Similarly, allow the xbox port 3074 to send to any registered or dynamic ports: TCP/UDP xbox360 3074 * 1024-65535 I have not seen any traffic to date (other than 53(DNS) or 80(HTTP) or 88(Kerebos) that did not have 3074 as either the soure or the destination. This allows the XBoxLive network test to run, and it allows full play without any blocked packets in either direction. I have not used uPnP because if I understand it correctly, it is an enormous hole. Any device, or software running on a machine behind the firewall, *can* open up anything and everything, for either itself or any other machine, or all machines. You are basically trusting every device, and every malware that might be infected on every machine. I assume that I must be wrong or uPnP would be render each and every little blue box firewall worthless, but this is my understanding right now. So I will not go near it. -
Imo you have too much text.
It's quite a lot to read with much unneeded information which is partly wrong and not a step by step how to.Upnp in pfsense allows you to limit which IP can map which port.
What i would do:
Limit yourself in the text to what steps are necessary to get it to work.
Move all explanations into a second post.
Look at upnp and how to configure it correctly without opening everything up. -
Thanks. I will collect comments for a couple of days then take another shot at it.
I would strongly prefer to have the explanation in the same note to keep them together. This keeps all of the pertinent information together. They could still be very separate, with the steps first. However if you and others tell me otherwise, I will separate them. -
I decided to put up a new-improved version for the benefit of future readers. Please continue to comment. The information content should be the same.
–-PFSense XBox360 Setup
NAT / Portforward WAN port 3074 to the XBox360 port 3074.
NAT / Outbound
Select:
(*) Manual Outbound Rule GenerationCreate rules for each of your subnets. Set "Static Port" to "YES"
on the subnet with the XBox360, "NO" on the others.My rules look like this, the XBox 360 is on the
192.168.243.0/24 network:WAN 192.168.240.0/24 * * * * * NO
WAN 192.168.241.0/24 * * * * * NO
WAN 192.168.243.0/24 * * * * * YESXBox's network test declared the connection as "Strict" before setting
"Static Port", moving up to "Moderate" after setting "Static Port"Create a Fireall / Rule for WAN allowing the portforward of 3074 to get
through to the xbox360 port 3074:TCP/UDP * * xbox360 3074
Create the following firewall rules allowing outgoing traffic from the
subnet hosting the XBox360 (Indicated here as "LAN_Net"):TCP/UDP LAN_Net * IF IP Address 53(DNS)
TCP/UDP LAN_Net * * 80(HTTP)
TCP/UDP LAN_Net * * 88(KEREBOS)
TCP/UDP LAN_Net 3074 * 1024-65535
TCP/UDP LAN_Net 1024-65535 * 3074That is all you have to do. If you want to understand more, read the
explanation below.Explanation
This setup assumes that you want to constraint the xbox360 as much as
possible without any compromises on the XBox functionality or play.Microsoft says to "open" or "Forward" ports 88 and 3074. This is both
unnecessary and insufficient for pfsense if you have a "Default Deny"
rule-set. I assume that these directions are appropriate for other
routers because of router behavior that Microsoft has assumed but not
stated.88 is for kerebos authentication. You have to let it out, but if you
are doing NAT then the NAT engine will generate a transient rule to
let the reponse in. No port-forward is necessary. If you put a port
forward in place for port 88, then no other machine on your network
will be able to use kerebos, since all responses will come back to
your XBox360!3074 is used for all communication, but in various ways. During play,
all communication goes out through 3074. Some other players appear to
receive their incoming communication only on 3074, others on apparently
random registered and dynamic port numbers. A single one minute trace
contained ports from 3976 to 63789. You can block outgoing traffic
except for destination ports 88 and 3074 and receive an "Open" rating
(The highest) from the XBoxLive connection test, but as you play, there
will be many outgoing packets going to registered and dynamic ports
that are blocked. You will seem to be much harder to kill.Since all outgoing communication during play originates on port 3074,
it would seem to make sense to move the 3074 requirement from the
destination to the source, restricting your xbox to sending on 3074
but allow it to send to any port. This would enable your xbox to
contact all other players. With this change, you will be able to
play fine, an examination of your Firewall log will not show anything
blocked, and Packet Capture will not show any packets being sent to
anything you have blocked. However the XBoxLive connection test will
fail completely, saying that your MTU is too small. This is not true;
the XBoxLive connection test sends from ports 1258, 1259, maybe 1257,
and less frequently on 1256. Those packets are blocked from going
out. Microsoft is testing on ports not being used for play, and
playing on ports not tested!In all observed cases either the source or destination was port 3074.
Short of openning everything wide, allow both:
Source (xbox) on port 3074 to any registered (1024-49151) or
dynamic (49152-65536) port.
and
Source (xbox) on any registered (1024-49151) or dynamic
(49152-65536) port to destination port 3074.This appears to be the tightest constraint that provides an "Open"
XBoxLive connection and does not block any packets during test or play.I have not seen any xbox traffic to date (other than 53(DNS) or
80(HTTP) or 88(Kerebos) that did not have 3074 as either the soure or
the destination port.
