Question 1. According to
pf.conf(5), the
static-port option with
nat-to rules "prevents
pf(4) from modifying the source port on TCP and UDP packets." The way that I interpret that is if I have an IPv4 address,
i, that gets NATed to the IPv4 address,
j, the source port that was used by
i will
not be translated to another port on
j. A brief test seems to support this interpretation as
beta$ pfctl -s state | grep "192.168.2.2" outputted content that showed the source port that was used was not being changed. If this is true though, then it would only take 302 different local devices/IPv4 addresses connecting to the same destination IPv4 address + port (using the same protocol (e.g., TCP)) before the probability of a "port collision" exceeds 50%. I'm guessing that
pf(4) simply
attempts to not translate the source port; however in the event that that source port is already being used by another IPv4 address connecting to the same destination IPv4 address + port, then it will translate the source port to a port that is unused. Furthermore, subsequent connections with the same IPv4 address and port will get translated to the same port. Is this correct?
Question 2. I know that
pf(4) by default keeps state of connections thus freeing one from having to create explicit rules that allow returned traffic. I would like to test my comprehension of the following situations:
a.
beta$ cat /etc/pf.conf
HTML Code:
match out on em0 inet from alc0:network to any nat-to (em0)
pass in quick on alc0 inet
pass out quick on em0 inet
block quick all
b.
beta$ cat /etc/pf.conf
HTML Code:
match out on em0 inet from alc0:network to any nat-to (em0)
pass in quick on alc0 inet proto { udp tcp } to any port 80
pass out quick on em0 inet proto { udp tcp } to any port 80
block quick all
Am I correct that both a. and b. will cause
pf(4) to block returning traffic if either the IPv4 address or port (regardless if it's TCP or UDP) is different than what the destination IP or port were when the traffic was initially sent—in this case let's assume initial connections were made to the destination port 80?
The reason I ask is that according to
this post on CALOMEL, "Sending three UDP packets to three different machines (all on the same port) creates three entries on a symmetric NAT and only one on a cone NAT. These two extra entries are what breaks Xbox Live. When you talk to the Live servers they remember the port you connected on and tell other Xboxes to talk to you over that same port. If your NAT is symmetric (default for pf) then it blocks the traffic from the other Xboxes as only the Live server is allowed back on that port. We need to use the 'static-port' nat directive and allow traffic using our anchor."
This makes it seem that if at least UDP is being used the response traffic is allowed to be from a different IP than the destination IP that was used in the initial connection. The reason I have both a. and b. is that while I realize b. will only allow initial traffic to port 80 and a. allows all traffic, I don't know if explicitly stating a port is necessary to ensure that the returned traffic is from the same port.
Please correct any mistakes in my comprehension or confirm my interpretations.