Adding the mailing list for the invaluable information provided.
On Thu, Apr 20, 2023 at 01:08:52AM -0400, LenLynch wrote:
> Thanks for the follow up.
>
> Let's see if I can keep you moving toward your desired goal.
>
> It's hard for me to provide you with a detailed response, because I don't
> know what your pf.conf looks like, so I have no idea why it may be blocking
> the traffic you are interested in passing. But I may be able to show you
> how I go about figuring out what's wrong.
>
> First some basics, if you know these already, ignore them...
>
> 1) I install pftop from packages, after launching it, you can get to "rule
> view" by using the "v" key 5x
> it displays the configured rule list, and updates hit counts on the rules
> on an update interval (I think its 10 secs or something close)
> So in this view you can see if traffic you generate is matching a rule you
> have configured, most likely it is being blocked.
> If it is NOT being blocked, then there is a different problem than a pf
> rule, and you'll have to find and fix it.
>
> 2) The default pf.conf supplied starts-out something like this:
> /etc/pf.conf:
> #set skip on lo. <<< commented out in my /etc/pf.conf, I do this later in
> the my pf.conf.local, you won't see this in the output of pftop I show
>
> #block return # block stateless traffic <<< I "block drop", you won't see
> this in the output of pftop I show
> #pass # establish keep-state <<< I replace this with other rules, you
> won't see this in my output of pftop I show
>
> # By default, do not permit remote connections to X11
> block return in on ! lo0 proto tcp to port 6000:6010 <<< you will see
> this in my pftop output (rule 2 in pftop)
>
> # Port build user does not need network
> block return out log proto {tcp udp} user _pbuild <<< you will see this
> in my pftop output (rule 3 and 4 in pftop)
>
> include "/etc/pf/pf.conf.local"
> <EOF>
>
> /etc/pf/pf.conf.local
> set block-policy drop
> set loginterface egress
> set skip on lo0
> set state-policy if-bound
> ##
> # Queues ##############################
> include "/etc/pf/queue.local"
> ##
> ## start rules that come from the default pf.conf ##
> # split the block all so that per address family logging can be done
> # in and out both blocked
> block inet all <<<<<<< ipv4 traffic being blocked (rule 0 in pftop)
> block inet6 all <<<<<<< ipv6 traffic being blocked (rule 1 in pftop)
> ...
> file continues...
>
> I'm essentially leaving the /etc/pf.conf file as close to stock as
> possible, commenting out everything but the include to my real config file,
> in its own directory. This way when the OBSD team decide that they will
> change the default pf.conf file in the future, when I do an upgrade, when
> sysmerge runs at the end of that process, the diff that is generated by
> sysmerge will show me what is so important that I need to consider changing
> in my pf.conf.local to keep current with the direction that OBSD is
> headed. Merging with the new pf.conf should be very easy and not be stress
> inducing when this occurs.
>
> 3) Now you can see how the top of my pf rules start out. This translates
> to the following output in pftop, in "rule view" (see above)
>
> RULE ACTION DIR LOG Q IF PR K PKTS BYTES STATES
> MAX INFO
> 0 Block Any 145830 8832569 0
> drop inet all
> 1 Block Any 98840 31003720 0
> drop inet6 all
> 2 Block In !lo0 tcp 173 7080 0
> return from any to any port 6000:6010
> 3 Block Out Log tcp 0 0 0
> return all user = 55
> 4 Block Out Log udp 0 0 0
> return all user = 55
>
> You can see that rule and what is in-play for the rules.
>
> When you are testing rules, if you are not seeing the "PKTS" and "BYTES"
> and "STATES" incrementing for a PASS or MATCH rule, then it is being
> blocked.
> You should see the counters incrementing for this "drop inet all" rule # 0.
> If that looks to be true, you should confirm this, by updating this rule to
> add logging to it, so you can remove all doubts.
>
> See what is being logged before making changes in real-time (from the pf
> FAQ logging section)
> NOTE: watching pf logs is different...
>
> *tcpdump -n -e -ttt -i pflog0*
>
> If none are being generated, then you can change your config and try and
> confirm
> rule0:
> block inet all should become>> block log inet all
>
> Apply your updated policy, start the log viewing command, see what is
> generated with OUT test traffic FIRST
>
> hostname$ doas tcpdump -n -e -ttt -i pflog0
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> Apr 19 22:57:37.663845 rule 0/(match) block in on vlan6: 192.168.x.144.3722
> > 192.168.x.68.3722: udp 4
> Apr 19 22:57:37.664105 rule 0/(match) block in on vlan6: 192.168.x.144.3722
> > 192.168.x.72.3722: udp 4
> Apr 19 22:57:39.979593 rule 0/(match) block in on em0: 58.255.139.71.38314
> > 172.8.19.138.23: S 2886210442:2886210442(0) win 26954
> Apr 19 22:57:40.837773 rule 0/(match) block in on vlan6:
> 192.168.x.136.10101 > 239.255.255.251.10101: udp 38 (DF) [ttl 1]
> Apr 19 22:57:40.837981 rule 0/(match) block in on vlan6:
> 192.168.x.136.10101 > 224.0.0.250.10101: udp 38 (DF) [ttl 1]
> Apr 19 22:57:40.944520 rule 0/(match) block in on em0: 94.102.61.50.37736 >
> 172.8.19.138.8012: S 3027710645:3027710645(0) win 65535 <mss 1460>
>
> You should expect to see all of this as a rule 0 match, because it's the
> only rule that logging is enabled for, AND traffic is being generated
> without any action by you...
>
> When you have a sense of what is being blocked by default, then generate
> your test traffic and verify that it shows up here.
>
> If you see your test traffic in the log, then you have confirmed that
> whatever pass/match rules you are trying are NOT being matched so far.
> If you do NOT see your test traffic, then either there is an issue with how
> you are generating the test traffic (routing to the wrong interface on pf,
> etc) or the traffic is being forwarded the way you are specifying, but when
> this forwarding occurs, there is *some other problem* that causes the test
> traffic to fail (no listening IP to accept the traffic, or a bad route to
> the destination, or there is no return route for the traffic, etc)
>
> 4) Now you are setup to see what works and what does NOT, and this should
> help you change the way you think about HOW you think pf is working, and
> how to make it do what you want it to. I do NOT think that you will need a
> SOCKS proxy or rdr/divert rules, most folks once they understand more about
> pf, can make it work with simple pass/match rules. But maybe I'm not
> following your descriptions closely enough yet and am mistaken.
>
> Let me speculate a little and see if this makes any sense:
>
> You do NOT show your egress interface, and wireguard uses the egress
> interface to transit traffic to the Internet.
> You are showing internal LAN interface re0, you don't show what the
> relationship is between your LAN and the proxy server IP.
> The original diagram does NOT make sense to me, and your attempt to clarify
> it, still makes little sense. Sorry.
>
> Maybe you are trying to do something very clever. If that's the case, it's
> too clever for me.
> I would suggest trying something much simpler first.
> So if you want a VPN client to be forwarded into your internal network, you
> will need a rule for this.
> Wireguard/Tailscale tunnel interface (tun0 for tailscale, use ifconfig to
> confirm your vpn interface), so a rule something like:
>
> wg_if="tun0"
> wg_ip="10.76.150.11"
> table <wg_src_allow> { IP1 IP2 } # wireguard VPN IP addresses
> table <wg_dst_allow> { IP3 IP4 } # internal LAN IP addresses
> #
> pass in on $wg_if from <wg_src_allow> to <wg_dst_allow>
>
> This pass in rule will keep-state, and should NOT require a "pass out"
> rule, UNLESS you have a very clever set of rules that is shooting you in
> the foot.
>
> This simple rule might not work, if you want the vpn client at the end of
> the VPN to know nothing about the IP address that it is connecting to.
> In a case like this, you would need something like this to make that work:
>
> # divert-to for a socket on the firewall itself
> pass in on $wg_if inet proto tcp from <wg_src_allow> to $wg_ip port 1080
> divert-to $fw_hosted_SOCKS_ip port 1080
>
> This should allow your VPN clients to connect to the VPN endpoint IP on the
> FW, and traffic will be directed to a listening service on another
> interface on the FW, with no knowledge of the client. The client would
> need to configure the socks proxy as the wireguard firewall IP for it to
> work...
>
> If you HAVE to run the SOCKS proxy on another box, you may need additional
> rules, something like:
>
> pass in on $wg_if from <wg_src_allow> to $wg_ip port 1080
> match out inet proto tcp from <wg_src_allow> to $wg_ip port 1080 rdr-to
> $SOCKS_proxy port 1080 nat-to $fw_lan_if
> pass out on $fw_lan_if inet # maybe needed if no generic pass out rule...
>
> (pass in will keep-state, and if the SOCKS is working correctly, return
> traffic should just work...)
>
> It seems like you have read and partially understand the pf.conf for nat-to
> rules, but you must be doing something wrong, like picking the wrong
> interface or have the routing backwards or something.
>
> I hope this provides you some help.
>
> Good Journey,
>
> -LenLynch
> Realizes: "Culture eats technology for breakfast..." -Russ White
