PF Rules Issue

M

mlager

I am having issues with being able to connect to remote hosts that are on my VPN network. From 172.16.1.1, I attempt to connect to port 22 on 172.16.10.1. I can ping 172.16.10.1 from 172.16.1.1. When I do so, PF on 172.16.1.1 blocks the traffic and the log shows:

Code: 
00:00:02.988936 rule 2..16777216/0(match): block in on gif1: 172.16.10.10.3389 > 172.16.1.204.60345: Flags [S.], seq 3184792111, ack
 1547387879, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 19099025 ecr 12134732], length 0

My rules on 172.16.1.1 are as follows:

Code: 
# MACROS
ext_if="re0"
int_if="re1"
internal_net="172.16.1.0/24"

# NORMALIZATION
scrub in all

# NETWORK ADDRESS TRANSLATION
nat on $ext_if from $internal_net to any -> ($ext_if)

# FILTERING
pass in all
pass out all

block in log all
pass quick on lo0 all
pass quick on $int_if all

pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif1 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif1 from any to any

# ENABLE ICMP
pass in on $ext_if proto icmp all keep state

# IPV6
pass quick on gif0 proto icmp6 all keep state

pass out on $ext_if proto { tcp, udp, icmp } all keep state

I would have thought the pass in quick on gif1 and pass out quick on gif1 would allow the traffic that PF is blocking, does anyone see anything obvious? 172.16.10.1 is access through 172.16.2.1, and 172.16.1.1 and 172.16.2.1 are connected via a IPsec VPN tunnel.
 
Are you sure that gif1 is the right interface? I believe that there is one interface generated per tunnel, thus you would have to use gif0,gif1 and gif2 respectively.

You have a bunch of redundant, or contradictory, lines in your config. I would suggest removing these for easier reading.
 
The block line I pasted from pflog references gif1, I have a gif0 but that handles my ipv6 tunnel. I'm not sure I understand which lines in my config are duplicated... If you are talking about the pass in and pass out lines for the IPSec traffic, that is pulled directly from the FreeBSD handbook.
 
Why are you doing NAT in local network? Your machines just need to route (make sure you have proper static routes pointing to all networks on needed devices).

Looking at the log you are receiving packet for 172.16.1.204 on 172.16.1.1 interface?

Also the way "quick" works is that the rules matching terminate there. You have "quick" inbound pass on your tunnel interface, and then bellow you permit icmp, rule which never gets hit. That's why it's redundant.

Is is alot easier to picture the network if you provide small ascii picture. What goes where, etc.
 
Thanks for the clarification on how "quick" works, I get the duplication now...

This particular system is running NAT for a local network, re0 has a public and re1 has an internal, NAT feeds the 172.16.1.0/24 network the Internet. gif1 is an IPsec tunnel to another FreeBSD system which also provides NAT to another location. So the routers are serving NAT locally and connecting the internal networks via IPsec tunnel...

I found that if I disable filtering on the tunnel interfaces things work properly, I.E.:

set skip on gif1

Since I do filtering on my external interface (re0), this doesn't seem to be a problem, and I'm ok not filtering traffic between the tunnels. I've got several tunnels established and have static routes in place to reach networks beyond the endpoint of my tunnels, so I think PF has a hard time with some of that, I could be wrong but I'm still doing more extensive testing.

I also noticed that pflog was rejecting some packets due to a bad hdr length, which may also be due to the IPsec setup.

Tomorrow I'll get an ASCII diagram of the network together, as you stated that will help paint a better picture. Thx again.
 
You must log in or register to reply here.
Back
Top