|
OpenBSD Security Functionally paranoid! |
|
Thread Tools | Display Modes |
|
|||
Questions about static-port and how pf keeps state.
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 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 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. Last edited by philomathic_life; 26th June 2021 at 12:33 AM. |
|
|||
As mentioned by jggimi, you can answer most of your questions by enabling logging in your pf rule.
To show how you could set up the logging, I will use the first rule set that you posted (adjusted to my system):. Code:
# cat philo-log.pf #match out on em0 inet from alc0:network to any nat-to (em0) match out log (all,to pflog0) on egress inet from wlan:network to any nat-to (egress) #pass in quick on alc0 inet pass in quick log (all, to pflog1) on wlan inet #pass out quick on em0 inet pass out quick log (all, to pflog2) on egress inet block quick log (all,to pflog3) all # ifconfig pflog1 up # ifconfig pflog2 up # ifconfig pflog3 up #pfctl -vvf philo-log.pf Loaded 714 passive OS fingerprints @0 match out log (all) on egress inet from 192.168.0.0/24 to any nat-to (egress:*) round-robin @1 pass in log (all, to pflog1) quick on wlan inet all flags S/SA @2 pass out log (all, to pflog2) quick on egress inet all flags S/SA @3 block drop log (all, to pflog3) quick all # pfctl -vvsr @0 match out log (all) on egress inet from 192.168.0.0/24 to any nat-to (egress:3) round-robin [ Evaluations: 18 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 6872 State Creations: 0 ] @1 pass in log (all, to pflog1) quick on wlan inet all flags S/SA [ Evaluations: 18 Packets: 11 Bytes: 308 States: 1 ] [ Inserted: uid 0 pid 6872 State Creations: 6 ] @2 pass out log (all, to pflog2) quick on egress inet all flags S/SA [ Evaluations: 12 Packets: 24 Bytes: 2056 States: 0 ] [ Inserted: uid 0 pid 6872 State Creations: 12 ] @3 block drop log (all, to pflog3) quick all [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 6872 State Creations: 0 ] # tcpdump -eni pflog2 tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog2, link-type PFLOG 05:18:38.317708 rule 2/(match) pass out on bge0: 192.168.222.242.17496 > 213.154.236.182.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 05:18:38.326393 rule 2/(match) pass in on bge0: 213.154.236.182.123 > 192.168.222.242.17496: v4 server strat 2 poll 3 prec -24 (DF) [tos 0xb8] Let us know what you find out
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
Tags |
nat, pf |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Round-Robin AND Static-Port in the same rule? | daemonbak | OpenBSD Security | 1 | 17th July 2015 01:58 PM |
The current state of NetBSD | Oko | NetBSD General | 87 | 16th May 2015 04:08 PM |
FreeBSD The state of 802.11n on FreeBSD | joekiser | News | 0 | 27th December 2011 08:15 PM |
current state of virtualization? | MBybee | OpenBSD Packages and Ports | 4 | 14th April 2011 07:27 PM |
pftop state query. | bsdnewbie999 | OpenBSD General | 1 | 10th April 2009 03:33 AM |