Re: Redirect SOCKS connections to another server on a different net

[Kenneth Gober]

On Sun, Apr 16, 2023 at 5:30 AM Charlie  wrote:

> I want to share the access to this proxy server on my OpenBSD machine
> with other systems in my home network. So basically what I want is to
> open a 1080 port on the OpenBSD server and redirect it to the local
> VPN address 10.64.0.1. I have been successful in doing so with the
> help of the "socat" program:
>
> $ socat tcp-listen:1080,bind=192.168.1.10,reuseaddr,fork \
> tcp:10.64.0.1:1080
>
> I would very much like to replace the above command with pf rule(s).
> All the combinations I tried with "rdr-to", "nat-to", "divert-to",
> "synproxy state", etc. did not work. Could someone kindly point me in
> the right direction (pun intended)?
>

I suspect you need something like this:

pass in on re0 from any to (re0) port 1080 rdr-to 10.64.0.1 tag nat
pass out on wg0 nat-to (wg0) tagged nat

The first rule handles the forwarding, the second rule makes it so
that all forwards to your SOCKS proxy appear to come from your
router (which the proxy knows how to reach) rather than other
systems on your home network (which the proxy might not have
usable routes to send replies to).

PF rules automatically set up the return path when the forward
path is 'passed' so you don't need rules for those.  You do need
to have both inbound and outbound rules for the forward path to
allow a connection to get set up.

-ken

Re: Understanding if-bound vs floating state policy

[Kenneth Gober]

On Fri, Dec 13, 2019 at 10:02 AM Victor Sudakov  wrote:

> But then, what is the real difference betwttn if-bound and global?
>

My understanding is that the difference applies when you have multiple
paths to the same destination.  For example, suppose you have a hardwired
ethernet connection on em0, and you also have a wireless connection on
iwn0, and you freely switch back and forth between them but use the same IP
address on both.  With if-bound states, switching from one interface to
another would require you to restart all your already-in-progress sessions
in order to re-establish states on the new interface.  With floating
states, a state established on one interface could be used directly if
packets for that connection suddenly start appearing on a different
interface.  (this is a bad example, I know, because ARP issues would make
it hard for an IP to float back and forth transparently, but a more proper
example is harder to explain).

It is a more useful setting on a router in a mesh network, where packets
you're forwarding might move between different interfaces, as their path
through the network is adjusted due to congestion or whatever.  On an
endpoint it's not particularly useful unless you want to allow sessions to
migrate between different interfaces (all using the same IP address), which
is a somewhat rare use case and one you would normally use trunk interfaces
to support, rather than floating states.

-ken

Re: pf ruleset parser re: tag and tagged

[Kenneth Gober]

On Tue, Jan 30, 2018 at 3:20 PM, S. Donaldson  wrote:
> It seems that tag references are not dynamically defined [ unless 
> perhaps they are used in authpf scenarios? ]. Would it make sense for the 
> parser to issue a warning if a 'tagged value' references appear but no 
> defining 'tag value' is found in a ruleset?

A warning would make sense.  Definitely not an error though, since the
'tag value' rule might be added later in an anchor.

I wonder how many people have gotten the bright idea of adding 'tagged
xyz' to comment out a rule without disturbing the rule numbering...

-ken

Re: Simple block of inbound ssh with exceptions

[Kenneth Gober]

On Sun, Dec 3, 2017 at 11:17 PM, Rolf Loudon  wrote:
> I’m both new to pf and struggling with what I thought was a simple idea.
> This is on a laptop, not a firewall per se.  I want to (a) allow incoming
> ssh connections for a small list of addresses, and (b) block other inbound
> ssh.  No outbound restrictions at all.

It's unclear whether you want to block other inbound traffic besides
ssh.  I am going to assume that you do.

# allow ssh from specific hosts
table  { 192.168.10.13, 192.168.10.14, 192.168.100.1 }
pass in quick proto tcp from  port ssh

# if you want to allow incoming ping requests uncomment next line
# pass in quick proto icmp icmp-type echoreq

# all other inbound blocked
# "quick" rules above will never get here
block in log all

# no outbound restrictions
pass out all

Re: pfctl parse issue with negated protocol list: block on $int proto ! { prot1 prot2 prot3 } leads to syntax error

[Kenneth Gober]

On Thu, Nov 23, 2017 at 4:37 PM, S. Donaldson  wrote:
> I've moved past simple block / allow and am trying to add 'forensic' 
> rules that generate log data that I can perform  some low level analysis 
> against. I have not found documentation that clearly states that a block rule 
> such as you suggest:
>
> block on $int inet
>
> will also effectively block all non-ip protocols. I assume that it does.

In a router, non-IP protocols are effectively blocked if they are not
forwarded.  If you are routing then blocking IP is equivalent to
blocking everything (unless you have compiled support for other
protocols into your kernel).

If you are bridging (or doing something very unusual) then you will
want instead:

block on $int
pass on $int inet proto tcp

-ken

Re: when used pfctl should log any changes to state of FW

[Kenneth Gober]

On Tue, Nov 21, 2017 at 1:21 PM, S. Donaldson  wrote:
> So why does pfctl not appear to (I could not find a command line option - nor 
> previous request)
>  log to syslog every command (who when what exit status) that changes 
> anything within
>  the pf context such as : rules, table contents, states?

pfctl doesn't do this because it is so easily evaded.  Anyone with the
access to run pfctl also has the access to compile their own version
with logging disabled.  The only way to prevent this is to deny people
root access, and once you have done that there are far easier ways to
log who is doing what, for example doas(1).

-ken

Re: lists of lists

[Kenneth Gober]

On Tue, Mar 21, 2017 at 12:11 PM, Admin Lewis  wrote:
> I have a simple question. Can I use lists of lists on pf.conf configuration
> file ?
>
> my_macro1=192.168.1.1
> my_macro2=192.168.1.2
> my_list1="{ 192.168.1.3 192.168.1.4 }"
> my_list2="{ 192.168.1.5 192.168.1.6 }"
>
> my_list_of_lists="{" $my_macro1 $my_macro2 $my_list1 $my_list2 "}"

This should work:

my_macro1=192.168.1.1
my_macro2=192.168.1.2
my_list1="192.168.1.3 192.168.1.4"
my_list2="192.168.1.5 192.168.1.6"
my_list_of_lists="{" $my_macro1 $my_macro2 $my_list1 $my_list2 "}"

This avoids nesting the curly braces, which makes the result simply a list
rather than a list of lists.

-ken