PF PF blocking opposite of IPs in network

stratacast1

stratacast1

I'm trying to allow one network to only have access to some IPs in another network. For some reason this isn't as intuitive as I thought as this is blocking the exact opposite of what I would expect. I'm experimenting with an OpenIKED server. The rules in question:

Code: 
intra = "bge0"
table <allowedlocal> { 192.168.10.6, 192.168.10.40, 192.168.10.42, 192.168.10.43, 192.168.10.49, 192.168.10.50 }

set reassemble yes
set block-policy return
set loginterface egress
set skip on { lo }

match in all scrub (no-df random-id max-mss 1440)

block in quick from urpf-failed label uRPF
block return log

pass out all modulate state

pass in on egress proto { ah, esp }
pass in on egress proto udp to (egress) port { isakmp, ipsec-nat-t }
pass out on egress from 10.0.1.0/24 to any nat-to (egress)
pass out on $intra from 10.0.1.0/24 to $intra:network nat-to ($intra)

pass in on $intra from <allowedlocal> to 10.0.1.0/24
pass out on $intra from 10.0.1.0/24 to <allowedlocal>

pass in quick inet proto icmp icmp-type { echoreq, unreach }

In essence, with the <allowedlocal> rules gone I can communicate with my internal network as well as reach out to the internet. But, once I put those two rules in I can communicate with every 192.168.10.0 IP EXCEPT the ones listed in the table. So why is it doing the opposite?
 
I believe your syntax is off. Here's mine:

Code: 
ext_if = "em0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"


### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp


Here's yours:

Code: 
intra = "bge0"
table <allowedlocal> { 192.168.10.6, 192.168.10.40, 192.168.10.42, 192.168.10.43, 192.168.10.49, 192.168.10.50 }

pass in on $intra from <allowedlocal> to 10.0.1.0/24
pass out on $intra from 10.0.1.0/24 to <allowedlocal>
 
Trihexagonal said:
I believe your syntax is off. Here's mine:

Code: 
ext_if = "em0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"


### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp


Here's yours:

Code: 
intra = "bge0"
table <allowedlocal> { 192.168.10.6, 192.168.10.40, 192.168.10.42, 192.168.10.43, 192.168.10.49, 192.168.10.50 }

pass in on $intra from <allowedlocal> to 10.0.1.0/24
pass out on $intra from 10.0.1.0/24 to <allowedlocal>
Click to expand...


No dice. I changed my pass in/out lines to be similar to what you mentioned, so I had this:

Code: 
block in quick log on $intra from 10.0.1.0/24 to <allowedlocal>
block out quick log on $intra from 10.0.1.0/24 to <allowedlocal>

Still no change. I can access the IPs I don't want accessed and vise-versa
 
It's still not the same:

Code: 
allowedlocal = "{ 192.168.10.6, 192.168.10.40, 192.168.10.42, 192.168.10.43, 192.168.10.49, 192.168.10.50 }"

block in quick log on $intra from 10.0.1.0/24 to $allowedlocal
block out quick log on $intra from 10.0.1.0/24 to $allowedlocal

I don't run the same set-up as you so I can't guarantee it's right, but that's what I was talking about.
 
GOT IT!!! So it took your answer plus a modification to my table. So here's what it looks like:

Code: 
table <allowedlocal> { 192.168.10.0/26, !192.168.10.6, !192.168.10.40, !192.168.10.42, !192.168.10.43, !192.168.10.49, !192.168.10.50 }

block in quick log on $intra from 10.0.1.0/24 to <allowedlocal>
block out quick log on $intra from 10.0.1.0/24 to <allowedlocal>


So everything in 192.168.10.0/26 is blocked except those addresses. Man what a pain haha. Firewalling can be evil sometimes. Thank you for pointing me to those block lines!
 
Spoke a little too soon though. I can ping the right hosts, but can't access the sites. Maybe I need the broadcast in there. More monkeying to do but this is a step in the right direction I think
 
You must log in or register to reply here.
Back
Top