Re: PF Rules for Dual Upstream Gateways

[Stuart Henderson]

On 2023-11-22, Ian Timothy  wrote:
> Hello,
>
> I have two ISPs where one connection is primary and the other is 
> low-bandwidth for temporary failover only. ifstated handles the failover by 
> simply changing the default gateway. But under normal conditions I want to be 
> able to connect via either connection at any time without changing the 
> default gateway.
>
> A long time ago under the old pf syntax I had this in /etc/pf.conf which 
> worked fine, and as far as I can remember was the only thing needed to enable 
> this desired behavior:
>
> pass in on $wan1_if reply-to ( $wan1_if $wan1_gw )
> pass in on $wan2_if reply-to ( $wan2_if $wan2_gw )
>
> But I’ve not been able to find the right way to do this under the new pf 
> syntax. From what I’ve been able to find this is supposedly does the same 
> thing, but no success so far:
>
> pass in on $wan1_if reply-to ($wan1_if:peer)
> pass in on $wan2_if reply-to ($wan2_if:peer)

The :peer syntax is for point-to-point interfaces (e.g. pppoe, maybe umb).

> What am I missing? Or this there a better way to do this?

As long as the gateway is at a known address (not a changing address from
DHCP) this should do:

pass in on $wan1_if reply-to $wan1_gw
pass in on $wan2_if reply-to $wan2_gw

You can also have a setup with multiple rtables, but in the simple case,
reply-to is often easier.

-- 
Please keep replies on the mailing list.

PF Rules for Dual Upstream Gateways

[Ian Timothy]

Hello,

I have two ISPs where one connection is primary and the other is low-bandwidth 
for temporary failover only. ifstated handles the failover by simply changing 
the default gateway. But under normal conditions I want to be able to connect 
via either connection at any time without changing the default gateway.

A long time ago under the old pf syntax I had this in /etc/pf.conf which worked 
fine, and as far as I can remember was the only thing needed to enable this 
desired behavior:

pass in on $wan1_if reply-to ( $wan1_if $wan1_gw )
pass in on $wan2_if reply-to ( $wan2_if $wan2_gw )

But I’ve not been able to find the right way to do this under the new pf 
syntax. From what I’ve been able to find this is supposedly does the same 
thing, but no success so far:

pass in on $wan1_if reply-to ($wan1_if:peer)
pass in on $wan2_if reply-to ($wan2_if:peer)

What am I missing? Or this there a better way to do this?

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[lain.]

(Sorry, I just realized I replied to just your email address, replying
again to the mailing list this time.)

On 2023年08月16日 10:05, Stuart Henderson wrote:
> wireguard-tools is not required, everything you need for wg(4) is in
> the base OS.

Oh, I didn't know that.
In that case, valid point.

> After some OS upgrades, some packages (especially those interfacing
> with the kernel for things like networking) will be broken until
> packages are updated.
> This is a problem if you rely on wg(4) to access the machine.

Not sure how frequent this is, but this only happened for me once on a
ThinkPad T43, and it was just a matter of running pkg_add -ui both
before and after an OS upgrade.

> chatgpt often makes the answer sound good but the answer is not
> necessarily reliable, so still needs vetting by someone who understands
> the area. better leave it to someone who understands in the first place.

Yes, but in my case it was more about how to phrase it, not a matter of
"what the fuck am I even talking about".
I understood why, I just didn't know how to explain in a way that sounds
reasonable.

I still stand by that the answer itself is more important than the person
(or thing) answering.
I would have expected the OpenBSD userbase to be much more merit-based
rather than leftist-leaning as seen in most other BSD's and Linux distro's
nowadays.

-- 
lain.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[SOUBHEEK NATH]

Hi,

I appreciate the valuable advices you provided about pf rules in
OpenBSD. I am currently away on a trip, but once I return, I will
thoroughly test those rules and provide you with feedback.

On Wed, Aug 16, 2023 at 3:50 PM Stuart Henderson
 wrote:
>
> On 2023-08-14, SOUBHEEK NATH  wrote:
> > 2. Please have a look at the configuration I have implemented.
> >
> >  pass in quick on wg0 proto tcp from 10.0.8.3/32 to any port {22 80}
> >  block in on wg0 proto tcp from any to any port {22 80}
> >  block in quick on bwfm0 proto tcp from any to any port {22 80}
> >
> >This configuration is functioning well and your suggestions have
> >greatly assisted me in achieving it.
> >
> >I would like to discuss my insights on this configuration and would
> >appreciate your feedback on it.
> >
> >I. I use the word "quick" in the first line to prevent the "block"
> >rules in the second line from taking precedence over it.
>
> That's one way to do it. Personally I don't like writing "quick" on all
> these lines so I normally order them for "last match wins" rather than
> "first match wins". This is mostly down to personal preference.
>
> >II. The second line effectively prevents any devices in the wireguard
> >network from accessing ports 22 and 80. However, because the 'quick'
> >command is used in the first line, the rule in the first line takes
> >precedence and allows access to ports 22 and 80 for the machine with
> >IP address 10.0.8.3.
>
> This also blocks forwarded traffic from machines on wg0 (other than
> 10.0.8.3) to port 22/80 on the internet, not just to the machine running
> PF. If this is what you want, that's ok, if not then you.may want "self"
> instead of "any".
>
> > On Mon, Aug 14, 2023 at 7:35 AM lain.  wrote:
> >>
> >> On 2023年08月13日 12:17, Stuart Henderson wrote:
> >> > >
> >> > > https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/
> >> >
> >> > what a mess of things from the base OS and unneeded third-party tools.
> >> >
> >> List of tools:
> >> wireguard-tools (required), nano (vim would have been enough), and the
> >> rest is everything OpenBSD ships with.
>
> wireguard-tools is not required, everything you need for wg(4) is in
> the base OS.
>
> >> Oh the horror, that's far too much, the sky is falling!
>
> After some OS upgrades, some packages (especially those interfacing
> with the kernel for things like networking) will be broken until
> packages are updated.
> This is a problem if you rely on wg(4) to access the machine.
>
> I suggest replacing use of wireguard-tools with the native configuration
> direct in hostname.wg0, see the wg(4) and ifconfig(8) manuals.
>
> >> > > On Sun, Aug 13, 2023 at 7:04 AM lain.  wrote:
> >> > >>
> >> > >> I failed to come up with reasons for using a preshared key, so I've 
> >> > >> let
> >> > >> ChatGPT generate reasons for me:
> >> >
> >> > oh $deitt please do not.
> >> >
> >> What matters is not who or what answered, what matters is the answer,
> >> and the answer it provided is good, but I guess autists gonna autist.
>
> chatgpt often makes the answer sound good but the answer is not
> necessarily reliable, so still needs vetting by someone who understands
> the area. better leave it to someone who understands in the first place.
>
> if you want to quote something, there's a perfectly good explanation
> in the wg(4) manual.
>
> --
> Please keep replies on the mailing list.
>

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[Stuart Henderson]

On 2023-08-14, SOUBHEEK NATH  wrote:
> 2. Please have a look at the configuration I have implemented.
>
>  pass in quick on wg0 proto tcp from 10.0.8.3/32 to any port {22 80}
>  block in on wg0 proto tcp from any to any port {22 80}
>  block in quick on bwfm0 proto tcp from any to any port {22 80}
>
>This configuration is functioning well and your suggestions have
>greatly assisted me in achieving it.
>
>I would like to discuss my insights on this configuration and would
>appreciate your feedback on it.
>
>I. I use the word "quick" in the first line to prevent the "block"
>rules in the second line from taking precedence over it.

That's one way to do it. Personally I don't like writing "quick" on all
these lines so I normally order them for "last match wins" rather than
"first match wins". This is mostly down to personal preference.

>II. The second line effectively prevents any devices in the wireguard
>network from accessing ports 22 and 80. However, because the 'quick'
>command is used in the first line, the rule in the first line takes
>precedence and allows access to ports 22 and 80 for the machine with
>IP address 10.0.8.3.

This also blocks forwarded traffic from machines on wg0 (other than
10.0.8.3) to port 22/80 on the internet, not just to the machine running
PF. If this is what you want, that's ok, if not then you.may want "self"
instead of "any".

> On Mon, Aug 14, 2023 at 7:35 AM lain.  wrote:
>>
>> On 2023年08月13日 12:17, Stuart Henderson wrote:
>> > >
>> > > https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/
>> >
>> > what a mess of things from the base OS and unneeded third-party tools.
>> >
>> List of tools:
>> wireguard-tools (required), nano (vim would have been enough), and the
>> rest is everything OpenBSD ships with.

wireguard-tools is not required, everything you need for wg(4) is in
the base OS.

>> Oh the horror, that's far too much, the sky is falling!

After some OS upgrades, some packages (especially those interfacing
with the kernel for things like networking) will be broken until
packages are updated.
This is a problem if you rely on wg(4) to access the machine.

I suggest replacing use of wireguard-tools with the native configuration 
direct in hostname.wg0, see the wg(4) and ifconfig(8) manuals.

>> > > On Sun, Aug 13, 2023 at 7:04 AM lain.  wrote:
>> > >>
>> > >> I failed to come up with reasons for using a preshared key, so I've let
>> > >> ChatGPT generate reasons for me:
>> >
>> > oh $deitt please do not.
>> >
>> What matters is not who or what answered, what matters is the answer,
>> and the answer it provided is good, but I guess autists gonna autist.

chatgpt often makes the answer sound good but the answer is not
necessarily reliable, so still needs vetting by someone who understands
the area. better leave it to someone who understands in the first place.

if you want to quote something, there's a perfectly good explanation
in the wg(4) manual.

-- 
Please keep replies on the mailing list.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[Matthew Ernisse]

On Mon, Aug 14, 2023 at 05:54:55PM +0530, SOUBHEEK NATH said:


2. Please have a look at the configuration I have implemented.

pass in quick on wg0 proto tcp from 10.0.8.3/32 to any port {22 80}
block in on wg0 proto tcp from any to any port {22 80}
block in quick on bwfm0 proto tcp from any to any port {22 80}


[ snip ]


  I. I use the word "quick" in the first line to prevent the "block"
  rules in the second line from taking precedence over it.


In general I prefer in my pf ruleset to block first and then explicitly 
allow things through.  I find this causes far less mistakes.  The very 
first rule in my ruleset is:


``block log all label "Default block"''

I try to avoid ``quick'' rules unless there is a really good reason to 
use them.  They can introduce some unintended side-effects if you aren't 
careful and if you find yourself using many of them you probably should 
re-think your rules.  For example, directly after the default block I also 
block bogon IP addresse from my WAN interface and I do it with quick so I 
don't accidentally unblock them later:


``block drop in quick log on egress inet from  to any''

(I have a table populated with bogon addresses)

You may wish to review the PF handbook, the filter section seems a good 
place to start.


https://www.openbsd.org/faq/pf/filter.html

--
Please direct replies to the list.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[SOUBHEEK NATH]

Hello,

The solution you both provided, worked well.

1. I do not use nano! I use the vi editor for my tasks.

2. Please have a look at the configuration I have implemented.

 pass in quick on wg0 proto tcp from 10.0.8.3/32 to any port {22 80}
 block in on wg0 proto tcp from any to any port {22 80}
 block in quick on bwfm0 proto tcp from any to any port {22 80}

   This configuration is functioning well and your suggestions have
   greatly assisted me in achieving it.

   I would like to discuss my insights on this configuration and would
   appreciate your feedback on it.

   I. I use the word "quick" in the first line to prevent the "block"
   rules in the second line from taking precedence over it.
   II. The second line effectively prevents any devices in the wireguard
   network from accessing ports 22 and 80. However, because the 'quick'
   command is used in the first line, the rule in the first line takes
   precedence and allows access to ports 22 and 80 for the machine with
   IP address 10.0.8.3.
   III. The third line is used to prevent any devices outside of the
   wireguard network from accessing ports 22 and 80.

I appreciate the time and effort you dedicated to this. Thank you so
much.
--
Soubheek Nath
Fifth Estate
Kolkata, India
soubheekn...@gmail.com

On Mon, Aug 14, 2023 at 7:35 AM lain.  wrote:
>
> On 2023年08月13日 12:17, Stuart Henderson wrote:
> > >https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/
> >
> > what a mess of things from the base OS and unneeded third-party tools.
> >
> List of tools:
> wireguard-tools (required), nano (vim would have been enough), and the
> rest is everything OpenBSD ships with.
> Oh the horror, that's far too much, the sky is falling!
>
> > > On Sun, Aug 13, 2023 at 7:04 AM lain.  wrote:
> > >>
> > >> I failed to come up with reasons for using a preshared key, so I've let
> > >> ChatGPT generate reasons for me:
> >
> > oh $deitt please do not.
> >
> What matters is not who or what answered, what matters is the answer,
> and the answer it provided is good, but I guess autists gonna autist.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[lain.]

On 2023年08月13日 12:17, Stuart Henderson wrote:
> >https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/
> 
> what a mess of things from the base OS and unneeded third-party tools.
> 
List of tools:
wireguard-tools (required), nano (vim would have been enough), and the
rest is everything OpenBSD ships with.
Oh the horror, that's far too much, the sky is falling!

> > On Sun, Aug 13, 2023 at 7:04 AM lain.  wrote:
> >>
> >> I failed to come up with reasons for using a preshared key, so I've let
> >> ChatGPT generate reasons for me:
> 
> oh $deitt please do not.
> 
What matters is not who or what answered, what matters is the answer,
and the answer it provided is good, but I guess autists gonna autist.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[lain.]

tical at this 
> > point, quantum computers could eventually break the Diffie-Hellman key 
> > exchange used in many encryption protocols. By using a PSK, WireGuard adds 
> > protection against this potential future vulnerability.
> >
> > 4. **Simplicity**: WireGuard's design is intended to be simple and easy to 
> > implement. The use of a PSK aligns with this philosophy by providing a 
> > straightforward way to bolster security.
> >
> > Here's an example of how you would generate and implement a preshared key 
> > in WireGuard:
> >
> > Generate the PSK:
> > ```bash
> > wg genpsk
> > ```
> >
> > You would then add the generated key to both the client and server 
> > configurations:
> >
> > Server's `wg0.conf`:
> > ```ini
> > [Peer]
> > PublicKey = CLIENT_PUBLIC_KEY
> > PresharedKey = GENERATED_PRESHARED_KEY
> > AllowedIPs = CLIENT_IP/32
> > ```
> >
> > Client's `wg0.conf`:
> > ```ini
> > [Peer]
> > PublicKey = SERVER_PUBLIC_KEY
> > PresharedKey = GENERATED_PRESHARED_KEY
> > AllowedIPs = 0.0.0.0/0
> > Endpoint = SERVER_IP:PORT
> > ```
> >
> > In summary, adding a PSK provides an extra layer of security that 
> > complements the existing asymmetric encryption, protects against potential 
> > quantum attacks, and adheres to WireGuard's principles of simplicity and 
> > effectiveness.
> >
> > On 2023年08月13日 10:22, lain. wrote:
> > > First off, unless you faked your private and public keys, please change
> > > them as soon as possible.
> > > You've just made yourself volunerable to cyber attacks!
> > >
> > > If I understand you correctly, you want to be able to SSH and HTTP only
> > > over WireGuard, right?
> > > In that case, on your WireGuard server:
> > >
> > > # Block access to SSH and HTTP from everyone except for your WireGuard 
> > > network
> > > pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
> > > block in quick on egress proto tcp from any to any port {22, 80}
> > >
> > > From your specifications, it's not quite clear whether your network is
> > > accessible from the outside or not, whether you're using a dynamic IP or
> > > static IP, how your router is configured, and all else, because
> > > requirements change depending on these details.
> > > If you're using a dynamic IP, and both your server and clienbts are
> > > within the same network, there's a good chance that this setup is
> > > unnecessary, given that using a WireGuard VPN makes sense if the server
> > > is remote and normally accessible from the outside, and you want to make
> > > it only accessible from the inside.
> > >
> > > As for your WireGuard config, you might want to add the Address to your
> > > "[Interface]" block like this for example:
> > > Address = 10.0.8.1/24
> > >
> > > Not necessarily required to get it working, but would still add an extra
> > > layer of security if you generate a preshared key on each peer, then on
> > > both your server and peers:
> > > [Peer]
> > > ...
> > > PreSharedKey = (output)
> > > ...
> > >
> > > To generate the preshared key (only do this on your peers):
> > > wg genpsk > preshared.key
> > >
> > > On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> > > > Dear OpenBSD Mailing List Community,
> > > >
> > > > I hope this email finds you well. I am writing to seek your expertise
> > > > and guidance regarding a Wireguard VPN configuration and pf rules on my
> > > > OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> > > > the provided interface configuration, and the VPN is operational as
> > > > intended. However, I have encountered a challenge while attempting to
> > > > implement pf rules to restrict access to SSH login and port number 80
> > > > based on specific IP addresses.
> > > >
> > > > Below is the pf rule settings I have applied:
> > > >
> > > > set skip on lo
> > > > block return# block stateless traffic
> > > > pass# establish keep-state
> > > >
> > > > # By default, do not permit remote connections to X11
> > > > block return in on ! lo0 proto tcp to port 6000:6010
> > > >
> > > > # Port build user does not need network
> > > > block return in quick on bwfm0 proto tcp from ! 192.168.0

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[Stuart Henderson]

>Based on my understanding of the OpenBSD PF-Packet filtering document
>(https://www.openbsd.org/faq/pf/filter.html), the intention of this
>pf rule is to allow only the IP address 10.0.8.4 to access ports 22
>and 80. However, currently both machines with IP addresses 10.0.8.2
>and 10.0.8.3 are able to access ports 22 and 80.

Maybe try something like

set skip on lo
block log
match out on bwfm0 inet received-on wg0 nat-to (bwfm0)
pass out
pass in on wg0
block log in to (self)
pass proto tcp from 10.0.8.4 to port {22 80}

I recommend ignoring the pf faq and use https://man.openbsd.org/pf.conf 
instead.

>https://www.vultr.com/docs/install-wireguard-vpn-server-on-openbsd-7-0/

what a mess of things from the base OS and unneeded third-party tools.

> On Sun, Aug 13, 2023 at 7:04 AM lain.  wrote:
>>
>> I failed to come up with reasons for using a preshared key, so I've let
>> ChatGPT generate reasons for me:

oh $deitt please do not.

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[SOUBHEEK NATH]

redKey = GENERATED_PRESHARED_KEY
> AllowedIPs = 0.0.0.0/0
> Endpoint = SERVER_IP:PORT
> ```
>
> In summary, adding a PSK provides an extra layer of security that complements 
> the existing asymmetric encryption, protects against potential quantum 
> attacks, and adheres to WireGuard's principles of simplicity and 
> effectiveness.
>
> On 2023年08月13日 10:22, lain. wrote:
> > First off, unless you faked your private and public keys, please change
> > them as soon as possible.
> > You've just made yourself volunerable to cyber attacks!
> >
> > If I understand you correctly, you want to be able to SSH and HTTP only
> > over WireGuard, right?
> > In that case, on your WireGuard server:
> >
> > # Block access to SSH and HTTP from everyone except for your WireGuard 
> > network
> > pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
> > block in quick on egress proto tcp from any to any port {22, 80}
> >
> > From your specifications, it's not quite clear whether your network is
> > accessible from the outside or not, whether you're using a dynamic IP or
> > static IP, how your router is configured, and all else, because
> > requirements change depending on these details.
> > If you're using a dynamic IP, and both your server and clienbts are
> > within the same network, there's a good chance that this setup is
> > unnecessary, given that using a WireGuard VPN makes sense if the server
> > is remote and normally accessible from the outside, and you want to make
> > it only accessible from the inside.
> >
> > As for your WireGuard config, you might want to add the Address to your
> > "[Interface]" block like this for example:
> > Address = 10.0.8.1/24
> >
> > Not necessarily required to get it working, but would still add an extra
> > layer of security if you generate a preshared key on each peer, then on
> > both your server and peers:
> > [Peer]
> > ...
> > PreSharedKey = (output)
> > ...
> >
> > To generate the preshared key (only do this on your peers):
> > wg genpsk > preshared.key
> >
> > On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> > > Dear OpenBSD Mailing List Community,
> > >
> > > I hope this email finds you well. I am writing to seek your expertise
> > > and guidance regarding a Wireguard VPN configuration and pf rules on my
> > > OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> > > the provided interface configuration, and the VPN is operational as
> > > intended. However, I have encountered a challenge while attempting to
> > > implement pf rules to restrict access to SSH login and port number 80
> > > based on specific IP addresses.
> > >
> > > Below is the pf rule settings I have applied:
> > >
> > > set skip on lo
> > > block return# block stateless traffic
> > > pass# establish keep-state
> > >
> > > # By default, do not permit remote connections to X11
> > > block return in on ! lo0 proto tcp to port 6000:6010
> > >
> > > # Port build user does not need network
> > > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> > > port ssh
> > > block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
> > > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> > > port 80
> > > block return out log proto {tcp udp} user _pbuild
> > >
> > > pass in on egress proto tcp from any to any port 22
> > >
> > > pass out on egress inet from (wg0:network) nat-to (bwfm0:0)
> > >
> > > The objective of these rules is to restrict SSH login and access to port
> > > 80 exclusively for the machine with the IP address 192.168.0.229 when
> > > the OpenBSD system is connected to the bwfm0 network interface. While
> > > the rule for SSH login and IP address 192.168.0.229 is functioning as
> > > expected, I have encountered an issue with the rule pertaining to port
> > > 80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0)
> > > during active Wireguard connections.
> > >
> > > The problem arises when attempting to enforce the restriction on port 80
> > > with IP address 10.0.8.2. Despite the pf rule in place, it seems that
> > > Wireguard is overriding the restriction. For instance, devices with
> > > assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within
> > > the Wireguard network, can access both SSH login and port 80, c

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[lain.]

I failed to come up with reasons for using a preshared key, so I've let
ChatGPT generate reasons for me:

Certainly! WireGuard's use of a preshared key (PSK) adds an additional layer of 
symmetric encryption to the standard asymmetric encryption. Here's a brief 
explanation of the advantage:

1. **Symmetric vs. Asymmetric Encryption**: WireGuard primarily uses asymmetric 
encryption, where each party has a pair of keys (public and private). Symmetric 
encryption, on the other hand, utilizes the same key for both encryption and 
decryption. By adding a PSK, WireGuard incorporates both types of encryption.

2. **Additional Security Layer**: The PSK is mixed into the encryption process 
along with the standard public and private keys. Even if an attacker could 
somehow compromise the asymmetric part (though practically very difficult), 
they would still need the PSK to decrypt the communication.

3. **Protection Against Quantum Attacks**: Though still theoretical at this 
point, quantum computers could eventually break the Diffie-Hellman key exchange 
used in many encryption protocols. By using a PSK, WireGuard adds protection 
against this potential future vulnerability.

4. **Simplicity**: WireGuard's design is intended to be simple and easy to 
implement. The use of a PSK aligns with this philosophy by providing a 
straightforward way to bolster security.

Here's an example of how you would generate and implement a preshared key in 
WireGuard:

Generate the PSK:
```bash
wg genpsk
```

You would then add the generated key to both the client and server 
configurations:

Server's `wg0.conf`:
```ini
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
PresharedKey = GENERATED_PRESHARED_KEY
AllowedIPs = CLIENT_IP/32
```

Client's `wg0.conf`:
```ini
[Peer]
PublicKey = SERVER_PUBLIC_KEY
PresharedKey = GENERATED_PRESHARED_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = SERVER_IP:PORT
```

In summary, adding a PSK provides an extra layer of security that complements 
the existing asymmetric encryption, protects against potential quantum attacks, 
and adheres to WireGuard's principles of simplicity and effectiveness.

On 2023年08月13日 10:22, lain. wrote:
> First off, unless you faked your private and public keys, please change
> them as soon as possible.
> You've just made yourself volunerable to cyber attacks!
> 
> If I understand you correctly, you want to be able to SSH and HTTP only
> over WireGuard, right?
> In that case, on your WireGuard server:
> 
> # Block access to SSH and HTTP from everyone except for your WireGuard network
> pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
> block in quick on egress proto tcp from any to any port {22, 80}
> 
> From your specifications, it's not quite clear whether your network is
> accessible from the outside or not, whether you're using a dynamic IP or
> static IP, how your router is configured, and all else, because
> requirements change depending on these details.
> If you're using a dynamic IP, and both your server and clienbts are
> within the same network, there's a good chance that this setup is
> unnecessary, given that using a WireGuard VPN makes sense if the server
> is remote and normally accessible from the outside, and you want to make
> it only accessible from the inside.
> 
> As for your WireGuard config, you might want to add the Address to your
> "[Interface]" block like this for example:
> Address = 10.0.8.1/24
> 
> Not necessarily required to get it working, but would still add an extra
> layer of security if you generate a preshared key on each peer, then on
> both your server and peers:
> [Peer]
> ...
> PreSharedKey = (output)
> ...
> 
> To generate the preshared key (only do this on your peers):
> wg genpsk > preshared.key
> 
> On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> > Dear OpenBSD Mailing List Community,
> > 
> > I hope this email finds you well. I am writing to seek your expertise
> > and guidance regarding a Wireguard VPN configuration and pf rules on my
> > OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> > the provided interface configuration, and the VPN is operational as
> > intended. However, I have encountered a challenge while attempting to
> > implement pf rules to restrict access to SSH login and port number 80
> > based on specific IP addresses.
> > 
> > Below is the pf rule settings I have applied:
> > 
> > set skip on lo
> > block return# block stateless traffic
> > pass# establish keep-state
> > 
> > # By default, do not permit remote connections to X11
> > block return in on ! lo0 proto tcp to port 6000:6010
> > 
> > # Port build user does not need network
> > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> > port s

Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[lain.]

First off, unless you faked your private and public keys, please change
them as soon as possible.
You've just made yourself volunerable to cyber attacks!

If I understand you correctly, you want to be able to SSH and HTTP only
over WireGuard, right?
In that case, on your WireGuard server:

# Block access to SSH and HTTP from everyone except for your WireGuard network
pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
block in quick on egress proto tcp from any to any port {22, 80}

>From your specifications, it's not quite clear whether your network is
accessible from the outside or not, whether you're using a dynamic IP or
static IP, how your router is configured, and all else, because
requirements change depending on these details.
If you're using a dynamic IP, and both your server and clienbts are
within the same network, there's a good chance that this setup is
unnecessary, given that using a WireGuard VPN makes sense if the server
is remote and normally accessible from the outside, and you want to make
it only accessible from the inside.

As for your WireGuard config, you might want to add the Address to your
"[Interface]" block like this for example:
Address = 10.0.8.1/24

Not necessarily required to get it working, but would still add an extra
layer of security if you generate a preshared key on each peer, then on
both your server and peers:
[Peer]
...
PreSharedKey = (output)
...

To generate the preshared key (only do this on your peers):
wg genpsk > preshared.key

On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> Dear OpenBSD Mailing List Community,
> 
> I hope this email finds you well. I am writing to seek your expertise
> and guidance regarding a Wireguard VPN configuration and pf rules on my
> OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> the provided interface configuration, and the VPN is operational as
> intended. However, I have encountered a challenge while attempting to
> implement pf rules to restrict access to SSH login and port number 80
> based on specific IP addresses.
> 
> Below is the pf rule settings I have applied:
> 
> set skip on lo
> block return# block stateless traffic
> pass# establish keep-state
> 
> # By default, do not permit remote connections to X11
> block return in on ! lo0 proto tcp to port 6000:6010
> 
> # Port build user does not need network
> block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> port ssh
> block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
> block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> port 80
> block return out log proto {tcp udp} user _pbuild
> 
> pass in on egress proto tcp from any to any port 22
> 
> pass out on egress inet from (wg0:network) nat-to (bwfm0:0)
> 
> The objective of these rules is to restrict SSH login and access to port
> 80 exclusively for the machine with the IP address 192.168.0.229 when
> the OpenBSD system is connected to the bwfm0 network interface. While
> the rule for SSH login and IP address 192.168.0.229 is functioning as
> expected, I have encountered an issue with the rule pertaining to port
> 80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0)
> during active Wireguard connections.
> 
> The problem arises when attempting to enforce the restriction on port 80
> with IP address 10.0.8.2. Despite the pf rule in place, it seems that
> Wireguard is overriding the restriction. For instance, devices with
> assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within
> the Wireguard network, can access both SSH login and port 80, contrary
> to the intended restriction.
> 
> I am providing the Wireguard configuration below for your reference:
> 
> [Interface]
> ListenPort = 51820
> PrivateKey = oPernzzF+Kl499z2TMU6wDdrDpnDN6/e630Q=
> 
> [Peer]
> PublicKey = yyhY5Blx+PxCHu/wK7QgrXHQ34RmTi//zynVA=
> AllowedIPs = 10.0.8.2/32
> PersistentKeepalive = 25
> 
> [Peer]
> PublicKey = dQO6ACctkgepDtWxGrHuGFdvaO9qfrL4mmjA=
> AllowedIPs = 10.0.8.3/32
> PersistentKeepalive = 25
> 
> I would greatly appreciate your insights, suggestions, and expertise in
> resolving this issue. Your assistance will be invaluable in helping me
> achieve the desired access restrictions while maintaining the
> functionality of the Wireguard VPN.
> 
> Thank you for your time and consideration.
> --
> Soubheek Nath
> Fifth Estate
> Kolkata, India
> soubheekn...@gmail.com
> 

-- 
lain.

Did you know that?
90% of all emails sent on a daily basis are being sent in plain text, and it's 
super easy to intercept emails as they flow over the internet?
Never send passwords, tokens, personal information, or other volunerable 
information without proper PGP encryption!

If you're writing

Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3

[SOUBHEEK NATH]

Dear OpenBSD Mailing List Community,

I hope this email finds you well. I am writing to seek your expertise
and guidance regarding a Wireguard VPN configuration and pf rules on my
OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
the provided interface configuration, and the VPN is operational as
intended. However, I have encountered a challenge while attempting to
implement pf rules to restrict access to SSH login and port number 80
based on specific IP addresses.

Below is the pf rule settings I have applied:

set skip on lo
block return# block stateless traffic
pass# establish keep-state

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010

# Port build user does not need network
block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
port ssh
block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
port 80
block return out log proto {tcp udp} user _pbuild

pass in on egress proto tcp from any to any port 22

pass out on egress inet from (wg0:network) nat-to (bwfm0:0)

The objective of these rules is to restrict SSH login and access to port
80 exclusively for the machine with the IP address 192.168.0.229 when
the OpenBSD system is connected to the bwfm0 network interface. While
the rule for SSH login and IP address 192.168.0.229 is functioning as
expected, I have encountered an issue with the rule pertaining to port
80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0)
during active Wireguard connections.

The problem arises when attempting to enforce the restriction on port 80
with IP address 10.0.8.2. Despite the pf rule in place, it seems that
Wireguard is overriding the restriction. For instance, devices with
assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within
the Wireguard network, can access both SSH login and port 80, contrary
to the intended restriction.

I am providing the Wireguard configuration below for your reference:

[Interface]
ListenPort = 51820
PrivateKey = oPernzzF+Kl499z2TMU6wDdrDpnDN6/e630Q=

[Peer]
PublicKey = yyhY5Blx+PxCHu/wK7QgrXHQ34RmTi//zynVA=
AllowedIPs = 10.0.8.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = dQO6ACctkgepDtWxGrHuGFdvaO9qfrL4mmjA=
AllowedIPs = 10.0.8.3/32
PersistentKeepalive = 25

I would greatly appreciate your insights, suggestions, and expertise in
resolving this issue. Your assistance will be invaluable in helping me
achieve the desired access restrictions while maintaining the
functionality of the Wireguard VPN.

Thank you for your time and consideration.
--
Soubheek Nath
Fifth Estate
Kolkata, India
soubheekn...@gmail.com

Re: Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

I have no idea how I could make my question any clearer:
> My question is not about how to disable pf, but rather why the packets
> are see as "in" when coming from my own address, and, why they are
> blocked i.e. ...

On Thu, Jul 06, 2023 at 11:09:27AM -0600, Zack Newman wrote:
> For added clarity, this tcpdump you show is with pf disabled and all
> its rules flushed. The tcpdump you showed in the initial e-mail
> clearly was with active pf rules.
Dude, it is _literally_ the same trace output.

If you feel the need to try to help people, maybe calm down a bit and
actually read the question.

I'm out.

Robb.

Re: Question regarding pf rules: block in on em0: ...

[Zack Newman]

On 7/6/23 06:14, Why 42? The lists account. wrote:

Hi,

I see that I was not clear enough.


You were not. One of the first things in your initial e-mail was the
following:

"While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen."

Is it a pf problem or not? If it is the case your "scanner" thing
doesn't work with pf disabled and no active rules, then this entire
thread makes no sense as you are focusing on something that is not
relevant.

Next steps. Disable pf _and_ flush the rules. Confirm there are no
active rules with pfctl -s all. Run the following:

tcpdump -ntt -i em0 -w pkts.dat &

Check if your "scanner" thing works.

Case 1: it doesn't work. Reply to this thread closing it due to the
completely irrelevant nature of both its title and content since you
have an entirely separate issue you need to solve first. If you are
unable to figure it out, then start a new thread with a more relevant
title where you only focus on things that matter. The only part of that
thread that should mention pf is how you have it completely disabled,
so you know it is something else. In that thread include the contents
of the tcpdump.

Case 2: it does work. Reply to this thread retracting you false claim
that pf "doesn't seem to the the issue". In that response include the
contents of the tcpdump.

For added clarity, this tcpdump you show is with pf disabled and all
its rules flushed. The tcpdump you showed in the initial e-mail
clearly was with active pf rules.

In the event that you require some form of traffic manipulation (e.g.,
NAT), then obviously you cannot disable pf. In that situation, make
sure your pf.conf rules only contain something similar to the following:

set skip on lo
pass out quick on  inet from { :network
:network ... :network } nat-to  static-port
pass quick

Re: Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

On Tue, Jul 04, 2023 at 10:42:39AM -0600, Zack Newman wrote:
> ...
> I am guessing you didn't flush the rules after disabling pf since
> clearly pf rules are still being used. Run pfctl -F all after disabling
> pf. Run pfctl -s all to verify there are no active rules.

Hi,

I see that I was not clear enough.

My question is not about how to disable pf, but rather why the packets
are see as "in" when coming from my own address, and, why they are
blocked i.e.

I noticed these block messages being logged when I click "discover/refresh" in 
simple-scan:

Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 
255.255.255.255.3289: udp 15 [ttl 1]
Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 
255.255.255.255.1124: udp 37 [ttl 1]

192.168.178.11 is my OpenBSD desktop (where of is running).

I don't understand what I'm seeing here ...

 1. Why am I seeing traffic coming _in_ from my own address? Is that not
slightly weird? Is it because it is _to_ the .255 broadcast address?

 2. And why is it being blocked? Do I have explicitly allow broadcast
traffic e.g. with rules to handle broadcast addresses? I don't think
I ever considered doing that before ...

The more I use pf, the less I seem to understand?

Danke im Voraus!

Robb.

Re: Question regarding pf rules: block in on em0: ...

[Zack Newman]

On 7/4/23 10:36, "Why 42? The lists account.":


While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.

However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block
messages being logged when I click "discover/refresh" in simple-scan:
...
Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 >
192.168.178.255.8612: udp 16 Jul 04 11:23:44.601051 rule 2/(match) block in on 
em0:
192.168.178.11.8612 > 192.168.178.255.8610: udp 16 Jul 04 11:23:44.615516 rule
2/(match) block in on em0: 192.168.178.11.8612 > 192.168.178.255.8612: udp 16 
Jul 04
11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 >
192.168.178.255.8610: udp 16 Jul 04 11:23:45.147239 rule 2/(match) block in on 
em0:
192.168.178.11.9609 > 255.255.255.255.3289: udp 15 [ttl 1] Jul 04 
11:23:46.155868
rule 2/(match) block in on em0: 192.168.178.11.39413 > 255.255.255.255.1124: 
udp 37


I am guessing you didn't flush the rules after disabling pf since
clearly pf rules are still being used. Run pfctl -F all after disabling
pf. Run pfctl -s all to verify there are no active rules.

Question regarding pf rules: block in on em0: ...

[Why 42? The lists account.]

Hi All,

I just noticed that "simple-scan" no longer discovers my scanner.

While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.

However, running "tcpdump -n -e -ttt -i pflog0" I noticed these block
messages being logged when I click "discover/refresh" in simple-scan:
...
Jul 04 11:23:44.601042 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.601051 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:44.615516 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8612: udp 16
Jul 04 11:23:44.615523 rule 2/(match) block in on em0: 192.168.178.11.8612 > 
192.168.178.255.8610: udp 16
Jul 04 11:23:45.147239 rule 2/(match) block in on em0: 192.168.178.11.9609 > 
255.255.255.255.3289: udp 15 [ttl 1]
Jul 04 11:23:46.155868 rule 2/(match) block in on em0: 192.168.178.11.39413 > 
255.255.255.255.1124: udp 37 [ttl 1]
...

192.168.178.11 is my OpenBSD desktop.

I don't understand what I'm seeing here ...

why am I seeing traffic coming _in_ from my own address? Is that not
slightly weird? Is it because it is _to_ the .255 broadcast address?

And why is it being blocked? Do I have explicitly allow broadcast traffic
e.g. with rules to handle broadcast addresses? I don't think I ever
considered doing that before ...

Grateful for any advice!

Yours,
Puzzled in PF-Land


FYI:
This is with a 7.3 snapshot: 7.3 GENERIC.MP#1268 amd64

Output of ifconfig:
4.07 11:23:51 # ifconfig em0
em0: 
flags=a48843
 mtu 1492
lladdr 94:c6:91:aa:16:67
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::96c6:91ff:feaa:1667%em0 prefixlen 64 scopeid 0x1
inet 192.168.178.11 netmask 0xff00 broadcast 192.168.178.255
inet6 2003:ee:1718:b100:39e3:3c67:bd3c:44f4 prefixlen 64 deprecated 
autoconf pltime 0 vltime 5213
inet6 2003:ee:1718:b100:3470:4349:f8d0:e1d2 prefixlen 64 deprecated 
autoconf temporary pltime 0 vltime 5213

Not sure what that "deprecated" means here.

Rule @2 is the "classic" block all rule ...

The contents of pf.conf:
#   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo
set block-policy return
set debug warning

# By default, do not permit remote connections to X11
#block return in log on ! lo0 proto tcp to port 6000:6010
block log on ! lo0 all  # Begin by blocking everything

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

# Allow all outbound
pass out quick modulate state

# Local subnet ...
local_subnet_v4="{ 192.168.178.0/24 }"

local_subnet_v6="{ fe80::/10 }"
# TODO: Correct ???

# Local systems that I might trust ...
trusted_clients_v4="{ 192.168.178.10, 192.168.178.12, 192.168.178.13, 
192.168.178.14 }"

# Allow ssh in
pass in log inet proto tcp from $trusted_clients_v4 to (egress) port ssh 
modulate state

# Scanner discovery? Allow traffic from Canon pixma TR8550
#scanner_ports="{ 8610, 8612 }"
#passlog inet  proto udp from 192.168.178.85 port $scanner_ports
pass in log inet proto udp from 192.168.178.85 port 8610
pass in log inet proto udp from 192.168.178.85 port 8612
#
# Allow avahi? See: /usr/local/share/doc/pkg-readmes/avahi
pass in log inet  proto udp from any to 224.0.0.251 port mdns allow-opts
pass in log inet6 proto udp from any to ff02::fb port mdns allow-opts
# and for SSDP:
pass in log inet  proto udp from any to 239.255.255.250 port ssdp allow-opts
pass in log inet6 proto udp from any to { ff02::c, ff05::c, ff08::c } port ssdp 
allow-opts
#
# OK, then try allowing multicast in general ...
pass log inet  proto igmp from any allow-opts

# NFS: Allow access to local NFS server
nfs_ports="{ sunrpc, nfsd, 881 }"
#
# But is UDP really still necessary?
#pass in proto udp from $trusted_clients to (egress) port $nfs_ports keep state
#pass out proto udp from (egress) to $trusted_clients port $nfs_ports keep state
#
pass in proto tcp from $trusted_clients_v4 to (egress) port $nfs_ports modulate 
state
pass in proto tcp from (egress) to $trusted_clients_v4 port $nfs_ports modulate 
state

# ICMP: Limit ICMP to allowed types: echorep, unreach, squench, echoreq, timex:
icmp_types = "{ echoreq, echorep, unreach, squench, timex }"
# See also: "man 4 icmp"
pass in log inet proto icmp to (egress) icmp-type $icmp_types label "rule $nr: 
pass: $proto: $icmp_type"

# HTTP: Running http-file-server:
# PORT= bin/http-file-server -u ~/Public/
# 2020/07/13 16:11:35 serving local path "/space/home/robb/Public" on "/Public/"
# 2020/07/13 16:11:35 redirecting to "/Public/" from "/"
# 2020/07/13 16:11:35 http-file-server listening on ":"
fs_port="{  }"
pass in proto tcp from $trusted_clients_v4 to (egress) 

Re: DHCP server ignoring PF rules?

[Marcus MERIGHI]

hello, 

barbarosb...@gmail.com (Barbaros Bilek), 2022.12.17 (Sat) 15:07 (CET):
> On Sat, Dec 17, 2022 at 4:40 PM Cristian Danila  wrote:
> > Thanks for the provided info, now it makes sense about what is happening.
> > Any idea about a possible way to control these packets?
> > Still investigating but I had still not found yet a way to do it.
> > Thank you.
>
> Hello Cristian,
> If you put your physical interface into veb(4) and set link1 flag you can
> filter dhcp packets.
> For more please read man veb
> Have a nice weekend.
> Barbaros

tcpdump(8)'s -B switch might work, too.

But beware. dlg@ already answered but he did not mention this, although
he committed it and said:

support configuring BIOCSFILDROP with tcpdump.

this allows tcpdump to be used a quick and dirty firewall. it
also looks like an amazing foot-gun, so be careful.

for example `tcpdump -B drop -i ix1 udp and port 7` lets you
completely drop discard packets in the hardware interrupt
handler.
[ I minimally edited the line flow. ]

https://cvsweb.openbsd.org/src/usr.sbin/tcpdump/tcpdump.c?rev=1.89=text/x-cvsweb-markup

I've not used this option, just saying...

Marcus

> > On Sat, Dec 17, 2022 at 3:11 PM David Gwynne  wrote:
> > >
> > > dhcpd reads packets off the wire using BPF, which happens as packets
> > come off the network interface, but before the IP stack where pf runs.
> > >
> > > > On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
> > > >
> > > > Good day!
> > > > I finished setup an DHCP server and for some reason it seems DHCP
> > > > server is ignoring PF filter.
> > > > In short, in PF I have active only one rule:
> > > > block drop quick all
> > > >
> > > > Double checked PF and it is enabled
> > > > So using a windows machine to test DHCP server:
> > > > 1) ifconfig /release
> > > > 2) ifconfig /renew
> > > >
> > > > somehow dhcpd still serves the windows(only when is enabled) and
> > > > ignores PF rule.
> > > > Could you please help me in telling if dhcpd has some intended logic
> > > > to ignore PF or what might
> > > > cause this unexpected behavior?
> > > >
> > > > Kind Regards!
> > > >
> > >
> >
> >

Re: DHCP server ignoring PF rules?

[Cristian Danila]

I was just about thinking to it, I will try it.
Many thanks and have a wonderful day!

On Sat, Dec 17, 2022 at 4:07 PM Barbaros Bilek  wrote:
>
> Hello Cristian,
>
> If you put your physical interface into veb(4) and set link1 flag you can 
> filter dhcp packets.
> For more please read man veb
> Have a nice weekend.
>
> --
> Best Regards
> Barbaros
>
>
>
> On Sat, Dec 17, 2022 at 4:40 PM Cristian Danila  wrote:
>>
>> Thanks for the provided info, now it makes sense about what is happening.
>> Any idea about a possible way to control these packets?
>> Still investigating but I had still not found yet a way to do it.
>>
>> Thank you.
>>
>> On Sat, Dec 17, 2022 at 3:11 PM David Gwynne  wrote:
>> >
>> > dhcpd reads packets off the wire using BPF, which happens as packets come 
>> > off the network interface, but before the IP stack where pf runs.
>> >
>> > > On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
>> > >
>> > > Good day!
>> > > I finished setup an DHCP server and for some reason it seems DHCP
>> > > server is ignoring PF filter.
>> > > In short, in PF I have active only one rule:
>> > > block drop quick all
>> > >
>> > > Double checked PF and it is enabled
>> > > So using a windows machine to test DHCP server:
>> > > 1) ifconfig /release
>> > > 2) ifconfig /renew
>> > >
>> > > somehow dhcpd still serves the windows(only when is enabled) and
>> > > ignores PF rule.
>> > > Could you please help me in telling if dhcpd has some intended logic
>> > > to ignore PF or what might
>> > > cause this unexpected behavior?
>> > >
>> > > Kind Regards!
>> > >
>> >
>>

Re: DHCP server ignoring PF rules?

[Barbaros Bilek]

Hello Cristian,

If you put your physical interface into veb(4) and set link1 flag you can
filter dhcp packets.
For more please read man veb
Have a nice weekend.

--
Best Regards
Barbaros



On Sat, Dec 17, 2022 at 4:40 PM Cristian Danila  wrote:

> Thanks for the provided info, now it makes sense about what is happening.
> Any idea about a possible way to control these packets?
> Still investigating but I had still not found yet a way to do it.
>
> Thank you.
>
> On Sat, Dec 17, 2022 at 3:11 PM David Gwynne  wrote:
> >
> > dhcpd reads packets off the wire using BPF, which happens as packets
> come off the network interface, but before the IP stack where pf runs.
> >
> > > On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
> > >
> > > Good day!
> > > I finished setup an DHCP server and for some reason it seems DHCP
> > > server is ignoring PF filter.
> > > In short, in PF I have active only one rule:
> > > block drop quick all
> > >
> > > Double checked PF and it is enabled
> > > So using a windows machine to test DHCP server:
> > > 1) ifconfig /release
> > > 2) ifconfig /renew
> > >
> > > somehow dhcpd still serves the windows(only when is enabled) and
> > > ignores PF rule.
> > > Could you please help me in telling if dhcpd has some intended logic
> > > to ignore PF or what might
> > > cause this unexpected behavior?
> > >
> > > Kind Regards!
> > >
> >
>
>

Re: DHCP server ignoring PF rules?

[Cristian Danila]

Thanks for the provided info, now it makes sense about what is happening.
Any idea about a possible way to control these packets?
Still investigating but I had still not found yet a way to do it.

Thank you.

On Sat, Dec 17, 2022 at 3:11 PM David Gwynne  wrote:
>
> dhcpd reads packets off the wire using BPF, which happens as packets come off 
> the network interface, but before the IP stack where pf runs.
>
> > On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
> >
> > Good day!
> > I finished setup an DHCP server and for some reason it seems DHCP
> > server is ignoring PF filter.
> > In short, in PF I have active only one rule:
> > block drop quick all
> >
> > Double checked PF and it is enabled
> > So using a windows machine to test DHCP server:
> > 1) ifconfig /release
> > 2) ifconfig /renew
> >
> > somehow dhcpd still serves the windows(only when is enabled) and
> > ignores PF rule.
> > Could you please help me in telling if dhcpd has some intended logic
> > to ignore PF or what might
> > cause this unexpected behavior?
> >
> > Kind Regards!
> >
>

Re: DHCP server ignoring PF rules?

[David Gwynne]

dhcpd reads packets off the wire using BPF, which happens as packets come off 
the network interface, but before the IP stack where pf runs.

> On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
> 
> Good day!
> I finished setup an DHCP server and for some reason it seems DHCP
> server is ignoring PF filter.
> In short, in PF I have active only one rule:
> block drop quick all
> 
> Double checked PF and it is enabled
> So using a windows machine to test DHCP server:
> 1) ifconfig /release
> 2) ifconfig /renew
> 
> somehow dhcpd still serves the windows(only when is enabled) and
> ignores PF rule.
> Could you please help me in telling if dhcpd has some intended logic
> to ignore PF or what might
> cause this unexpected behavior?
> 
> Kind Regards!
> 

DHCP server ignoring PF rules?

[Cristian Danila]

Good day!
I finished setup an DHCP server and for some reason it seems DHCP
server is ignoring PF filter.
In short, in PF I have active only one rule:
block drop quick all

Double checked PF and it is enabled
So using a windows machine to test DHCP server:
1) ifconfig /release
2) ifconfig /renew

somehow dhcpd still serves the windows(only when is enabled) and
ignores PF rule.
Could you please help me in telling if dhcpd has some intended logic
to ignore PF or what might
cause this unexpected behavior?

Kind Regards!

Re: PF rules to block out every IP from a given country

[Frank Habicht]

Hi,

On 07/12/2022 18:36, Peter N. M. Hansteen wrote:
...> and can now be found at 
https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --

as it says in the script itself, a trivial hack.

And I might add, it comes with *NO* warranties of any kind.


I think instead of :
grep allocated
in the two important lines, it should be :
egrep '(allocated)|(assigned)'

coz both can go to countries.

Frank

Re: PF rules to block out every IP from a given country

[Stuart Henderson]

On 2022-12-07, Peter N. M. Hansteen  wrote:
> On Wed, Dec 07, 2022 at 10:28:27AM +1100, Damian McGuckin wrote:
>> 
>> Has anybody created rules such as this and if so, do you have an example?
>
> As others have already indicated, the PF way to do anything like this would be
> to generate a list of addresses and networks you want to address (block in 
> this case),
> feed that list into a table and make the table the criteria for a blocking 
> rule.
>
> I remembered that a few years back I was asked to do something along those 
> lines,
> I forget the exact reason why, but anyway I decided that the most reasonable 
> way
> to determine which IP addresses or ranges belong to a certain country would be
> to fetch the most up to date data from the things RIPE publish. 
>
> My tiny writeup which in fact contains the entire script for massaging RIPE's
> data into something you can feed into a PF table survived a couple of job 
> changes
> and can now be found at https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --
> as it says in the script itself, a trivial hack. 

# 16777216 -> /8 (Not actually found in RIPE data but with ARIN who knows)

btw there are /8's in the RIPE file now. Also prefix lengths smaller than
/26, even down to single addresses, so the subst will need some tweaks to
cover those.

> It is for example quite conceivable that an organization with premises in more
> than one country might want to split their allocations not strictly according
> to national borders.

And other specialities like anycast addresses, and as it's user-supplied
data it can't be completely relied upon. It changes often too; people using
this will want to arrange to keep it updated; allocations do change and
can move between countries (and, these days, even between regions).

It's likely that the output can be shrunk further by passing it through
aggregate6 (in ports).

-- 
Please keep replies on the mailing list.

Re: PF rules to block out every IP from a given country

[Peter N. M. Hansteen]

On Wed, Dec 07, 2022 at 10:28:27AM +1100, Damian McGuckin wrote:
> 
> Has anybody created rules such as this and if so, do you have an example?

As others have already indicated, the PF way to do anything like this would be
to generate a list of addresses and networks you want to address (block in this 
case),
feed that list into a table and make the table the criteria for a blocking rule.

I remembered that a few years back I was asked to do something along those 
lines,
I forget the exact reason why, but anyway I decided that the most reasonable way
to determine which IP addresses or ranges belong to a certain country would be
to fetch the most up to date data from the things RIPE publish. 

My tiny writeup which in fact contains the entire script for massaging RIPE's
data into something you can feed into a PF table survived a couple of job 
changes
and can now be found at https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --
as it says in the script itself, a trivial hack. 

And I might add, it comes with *NO* warranties of any kind. 

It is for example quite conceivable that an organization with premises in more
than one country might want to split their allocations not strictly according
to national borders.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: PF rules to block out every IP from a given country

[Muhammad Muntaza]

On Wed, 7 Dec 2022 at 08.55 Damian McGuckin  wrote:

>
> Has anybody created rules such as this and if so, do you have an example?
>
> Stay safe - Damian
>

Check this Example:

https://www.muntaza.id/pf/2020/02/03/pf-firewall-bagian-kedua.html

I write in Indonesia, you can use Google Translate to read it.


Thanks,

Muhammad Muntaza bin Hatta



>

Re: PF rules to block out every IP from a given country

[Craig Schulz]

Take a look at PF-Badhost.

Here is a decent write-up:

https://undeadly.org/cgi?action=article;sid=20210119113425

Craig

> On Dec 6, 2022, at 18:28, Damian McGuckin  wrote:
> 
> 
> Has anybody created rules such as this and if so, do you have an example?
> 
> Stay safe - Damian
> 
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer
> 



signature.asc
Description: Message signed with OpenPGP

Re: PF rules to block out every IP from a given country

[All]

Considering you solved the issue with getting all IPs
for a given country correctly (and perhaps updating it sometimes):
1. Dump all IP addresses/ranges into a file (eg. blocked.ips)
2. add table  file  /path/to/blocked.ips
add "persist" if you want.
3. create rule to block all incoming connections from  

Alternatively, you can just create a file with IPs you allow, 
create table and write rules to allow connections from IPs
in that file. 

On Wednesday, December 7, 2022 at 09:44:34 a.m. GMT+9, Damian McGuckin 
 wrote: 






Has anybody created rules such as this and if so, do you have an example?

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

PF rules to block out every IP from a given country

[Damian McGuckin]

Has anybody created rules such as this and if so, do you have an example?

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: pf rules after crash

[Allan Streib]

On Sat, Jul 10, 2021, at 11:30 AM, Stuart Henderson wrote:
> On 2021-07-10, Peter Nicolai Mathias Hansteen  wrote:
> > For whatever reason your pf.conf did not parse to a valid config, so rc’s 
> > own default rules were kept in place.
> 
> Yep. dmesg -s might give a clue.

Thank you both, I suspected it might be default startup rules but I didn't know 
they were in /etc/rc.

Since I've rebooted again since the crash I don't think dmesg -s is helpful 
now, but there are other indicators in /var/log/messages that something wasn't 
right:

...
Jul  9 17:13:58 ** ntpd[24315]: constraints configured but none 
available
Jul  9 17:14:14 ** ntpd[24954]: no reply received in time, skipping 
initial time setting
Jul  9 17:14:14 ** savecore: no core dump
Jul  9 17:14:24 ** reorder_kernel: kernel relinking done
Jul  9 17:28:58 ** ntpd[24315]: constraints configured but none 
available
Jul  9 17:43:58 ** ntpd[24315]: constraints configured but none 
available
Jul  9 17:58:58 ** ntpd[24315]: constraints configured but none 
available
...

For now I'll chalk it up to an issue with the KVM host (I have a ticket open 
with the hosting provider asking about the event, since both my VMs on that 
node crashed at the same time).

If it happens again I will try dmesg -s.

Allan

Re: pf rules after crash

[Stuart Henderson]

On 2021-07-10, Peter Nicolai Mathias Hansteen  wrote:
> For whatever reason your pf.conf did not parse to a valid config, so rc’s own 
> default rules were kept in place.

Yep. dmesg -s might give a clue.

Re: pf rules after crash

[Peter Nicolai Mathias Hansteen]

> 10. jul. 2021 kl. 05:11 skrev Allan Streib :
> 
> Hi,
> 
> I have a KVM host running OpenBSD 6.9 for a few days. It crashed today for 
> some reason, and when I logged in and realized the uptime had changed, I 
> checked the pf rules out of curiosity since I have been experimenting with 
> pf. These rules are very different from what is in /etc/pf.conf.
> 
> # pfctl -s rules
> block drop all
> pass out inet6 proto ipv6-icmp all icmp6-type neighbrsol
> pass out inet6 proto ipv6-icmp all icmp6-type routersol
> pass out inet6 proto udp from any port = 546 to any port = 547
> pass out inet proto icmp all icmp-type echoreq
> pass out inet proto udp from any port = 68 to any port = 67
> pass out proto tcp from any to any port = 53 flags S/SA
> pass out proto udp from any to any port = 53
> pass in inet6 proto ipv6-icmp all icmp6-type neighbradv
> pass in inet6 proto ipv6-icmp all icmp6-type routeradv
> pass in inet6 proto udp from any port = 547 to any port = 546
> pass in proto tcp from any to any port = 22 flags S/SA
> pass in inet proto udp from any port = 67 to any port = 68
> pass on lo0 all flags S/SA
> pass in proto carp all keep state (no-sync)
> pass out proto carp all !received-on any keep state (no-sync)
> 

This matches the default rule set in /etc/rc.

For whatever reason your pf.conf did not parse to a valid config, so rc’s own 
default rules were kept in place.


> # cat /etc/pf.conf
> #   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
> #
> # See pf.conf(5) and /etc/examples/pf.conf
> table  persist
> set skip on lo
> block in quick from 
> block return# block stateless traffic
> pass out quick inet
> pass in quick on egress proto tcp from any to any port { www, https }
> pass in on egress proto tcp to vio0 port ssh keep state \
>(max-src-conn-rate 3/10, overload  flush)
> 
> I reloaded my rules (pfctl -f /etc/pf.conf) which worked, and then rebooted 
> and checked (pfctl -s rules) which now matched the rules in /etc/pf.conf.
> 
> What could explain this?

With a config that simple it is hard to say what could possibly go wrong.
I’d investigate /var/log/messages for anything unusual around the time of the 
event.

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP

pf rules after crash

[Allan Streib]

Hi,

I have a KVM host running OpenBSD 6.9 for a few days. It crashed today for some 
reason, and when I logged in and realized the uptime had changed, I checked the 
pf rules out of curiosity since I have been experimenting with pf. These rules 
are very different from what is in /etc/pf.conf.

# pfctl -s rules
block drop all
pass out inet6 proto ipv6-icmp all icmp6-type neighbrsol
pass out inet6 proto ipv6-icmp all icmp6-type routersol
pass out inet6 proto udp from any port = 546 to any port = 547
pass out inet proto icmp all icmp-type echoreq
pass out inet proto udp from any port = 68 to any port = 67
pass out proto tcp from any to any port = 53 flags S/SA
pass out proto udp from any to any port = 53
pass in inet6 proto ipv6-icmp all icmp6-type neighbradv
pass in inet6 proto ipv6-icmp all icmp6-type routeradv
pass in inet6 proto udp from any port = 547 to any port = 546
pass in proto tcp from any to any port = 22 flags S/SA
pass in inet proto udp from any port = 67 to any port = 68
pass on lo0 all flags S/SA
pass in proto carp all keep state (no-sync)
pass out proto carp all !received-on any keep state (no-sync)

# cat /etc/pf.conf
#   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
table  persist
set skip on lo
block in quick from 
block return# block stateless traffic
pass out quick inet
pass in quick on egress proto tcp from any to any port { www, https }
pass in on egress proto tcp to vio0 port ssh keep state \
(max-src-conn-rate 3/10, overload  flush)

I reloaded my rules (pfctl -f /etc/pf.conf) which worked, and then rebooted and 
checked (pfctl -s rules) which now matched the rules in /etc/pf.conf.

What could explain this?

Thanks,

Allan


#dmesg
OpenBSD 6.9 (GENERIC) #4: Mon Jun  7 08:20:14 MDT 2021
r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056817152 (1007MB)
avail mem = 1009557504 (962MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf58f0 (9 entries)
bios0: vendor SeaBIOS version "1.12.0-1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 9 3900X 12-Core Processor, 3793.36 MHz, 17-71-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,SSBD,IBPB,SSBD,XSAVEOPT,XSAVEC,XGETBV1
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0010" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pvclock0 at pvbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  removable
cd0(pciide0:1:1): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 00:16:72:0e:be:c6
virtio0: msix shared
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Network" rev 0x00
vio1 at virtio1: address 00:16:e8:45:ed:a4
virtio1: msix shared

Re: pf rules vs late pppoe0 setup

[Daniel Jakots]

On Sun, 26 Apr 2020 13:54:27 +0200, Jan Stary  wrote:

> Is there a recommended way to deal with this?

If I correctly understood your problem, the solution:
(from pf.conf(5))

> Host name resolution and interface to address translation are
> done at ruleset load-time.  When the address of an interface (or
> host name) changes (under DHCP or PPP, for instance), the ruleset
> must be reloaded for the change to be reflected in the kernel.
> Surrounding the interface name (and optional modifiers) in
> parentheses changes this behaviour.  When the interface name is
> surrounded by parentheses, the rule is automatically updated
> whenever the interface changes its address.  The ruleset does not
> need to be reloaded.  This is especially useful with NAT.

Cheers,
Daniel

pf rules vs late pppoe0 setup

[Jan Stary]

This is current/amd64 on an APU2.

The machine is connected via pppoe over vlan over em as follows:

$ ifconfig em0
em0: flags=8843 mtu 1500
lladdr 00:0d:b9:56:5e:fc
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex)
status: active

$ ifconfig vlan0
vlan0: flags=8843 mtu 1500
lladdr 00:0d:b9:56:5e:fc
description: UVTNET
index 7 priority 0 llprio 3
encap: vnetid 848 parent em0 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active

$ ifconfig pppoe0
pppoe0: flags=8851 mtu 1492
index 6 priority 0 llprio 3
dev: vlan0 state: session
sid: 0x1 PADI retries: 5 PADR retries: 0 time: 00:00:32
sppp: phase network authproto pap authname "X"
groups: pppoe egress
status: active
inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 ->  prefixlen 64 scopeid 0x6
inet 185.63.96.79 --> 10.11.5.146 netmask 0x

That works just fine, but as the pppoe0 connection is not instantenuous,
by the time pf.conf rules are evaluated, pppoe0 is still 0.0.0.0.

Reading rc(8) and the boot up sequence messages

pf enabled
net.inet.ip.forwarding: 0 -> 1
starting network
add net default: gateway 0.0.0.1
add net default: gateway fe80::%pppoe0

pf is enabled first with the default rules,
then the network interfaces get their addresses,
and then the "real" rules are applied (right?).

The pppoe0 interface is set up as follows:
$ cat /etc/hostname.pppoe0
inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \
authproto 'pap' authname 'X' authkey 'PASS' up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0

Right after boot, it is still not entirely up:

pppoe0: flags=8851 mtu 1492
index 6 priority 0 llprio 3
dev: vlan0 state: PADI sent
sid: 0x0 PADI retries: 2 PADR retries: 0
sppp: phase establish authproto pap authname "X"
groups: pppoe egress
status: no carrier
inet 0.0.0.0 --> 0.0.0.1 netmask 0x
inet6 fe80::20d:b9ff:fe56:5efc%pppoe0 ->  prefixlen 64 scopeid 0x6

and, accordingly,

# pfctl -sr
match out on egress inet from ! 0.0.0.0 to any nat-to 0.0.0.0
block drop in log quick on ! lo inet6 from ::1 to any
block drop in log quick on ! lo inet from 127.0.0.0/8 to any
block drop in log quick inet from 127.0.0.1 to any
block drop in log quick on ! pppoe0 inet from 0.0.0.0 to any
block drop in log quick inet from 0.0.0.0 to any
block drop in log quick on ! em1 inet from 192.168.11.0/24 to any
block drop in log quick inet from 192.168.11.1 to any
block drop in log quick inet6 from ::1 to any
block drop in log quick on lo0 inet6 from fe80::1 to any
block drop in log quick on pppoe0 inet6 from fe80::20d:b9ff:fe56:5efc to any
block return in log all
pass out on egress all flags S/SA
pass quick inet proto icmp all
pass in on pppoe0 inet proto tcp from any to 0.0.0.0 port = 2200 flags S/SA 
rdr-to 127.0.0.1 port 22
pass in on pppoe0 inet proto tcp from any to 0.0.0.0 port =  flags S/SA 
rdr-to 127.0.0.1 port 22
pass in on em1 inet from 192.168.11.0/24 to any flags S/SA

Entire pf.conf below - but it's not about the indivdual rules,
the problem is that pppoe0 is 0.0.0.0, and only becomes 185.63.96.79
after pf.conf has been applied.

Is there a recommended way to deal with this?
Having physical access to the machine, I just re-run
pfctl -f /etc/pf.conf once pppoe0 gets its address;
I could do that in rc.local after a minute of sleep,
but that seems a bit crude.

Jan


set skip on lo
set block-policy return

match out on egress inet from !egress:network nat-to egress:0
antispoof log quick for { lo $ext $int }

block in log all

pass out on egress
pass quick inet proto icmp

pass in on $ext inet proto tcp to $ext port 2200 rdr-to localhost port ssh
pass in on $ext inet proto tcp to $ext port  rdr-to localhost port ssh

pass in on $int inet from $int:network

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Martins]

Nick,

Indeed Working.
Thanks.

>>
>> May be a dumb question, but do you have net.inet.ip.forwarding=1 set?
>>
>
> Neither can I believe had forgotten it, but I think you nailed it.
> Will test monday and let know.
>
> Thanks in advance.
>
> -fm
>
>>
>> tcpdump of a successful test connection:
>> c.c.c.c = remote test client on internet

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Martins]

>
> May be a dumb question, but do you have net.inet.ip.forwarding=1 set?
>

Neither can I believe had forgotten it, but I think you nailed it.
Will test monday and let know.

Thanks in advance.

-fm

>
> tcpdump of a successful test connection:
> c.c.c.c = remote test client on internet
> r.r.r.r = firewall external IP
>
> pf# tcpdump -ni vmx1 port 8099 or host 129.128.5.194
> tcpdump: listening on vmx1, link-type EN10MB
> 14:34:09.270237 c.c.c.c.63091 > r.r.r.r.8099: S 3178148684:3178148684(0)
> win 64240  [tos 0x20]
> 14:34:09.270303 r.r.r.r.62530 > 129.128.5.194.80: S
> 3178148684:3178148684(0) win 64240  8,nop,nop,sackOK> [tos 0x20]
> 14:34:09.342800 129.128.5.194.80 > r.r.r.r.62530: S
> 3355699325:3355699325(0) ack 3178148685 win 16384  1460,nop,nop,sackOK,nop,wscale 6> (DF) [tos 0x20]
> 14:34:09.342830 r.r.r.r.8099 > c.c.c.c.63091: S 3355699325:3355699325(0)
> ack 3178148685 win 16384  [tos 0x20]
> 14:34:09.372450 c.c.c.c.63091 > r.r.r.r.8099: . ack 1 win 1026 [tos 0x20]
> 14:34:09.372461 c.c.c.c.63091 > r.r.r.r.8099: P 1:436(435) ack 1 win
> 1026 [tos 0x20]
> 14:34:09.372477 r.r.r.r.62530 > 129.128.5.194.80: . ack 1 win 1026 [tos
> 0x20]
> 14:34:09.372500 r.r.r.r.62530 > 129.128.5.194.80: P 1:436(435) ack 1 win
> 1026 [tos 0x20]
> 14:34:09.450714 129.128.5.194.80 > r.r.r.r.62530: P 1:197(196) ack 436
> win 273 (DF) [tos 0x20]
> 14:34:09.450716 129.128.5.194.80 > r.r.r.r.62530: . 197:1657(1460) ack
> 436 win 273 (DF) [tos 0x20]
> 14:34:09.450759 r.r.r.r.8099 > c.c.c.c.63091: P 1:197(196) ack 436 win
> 273 [tos 0x20]
> 14:34:09.450774 r.r.r.r.8099 > c.c.c.c.63091: . 197:1657(1460) ack 436
> win 273 [tos 0x20]
>
>
>

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Nick Gustas]

On 2/14/2020 11:21 AM, Fabio Martins wrote:

I am trying now only with the redirect to www.openbsd.org, if it works, I
am sure it can be adapted to my case.

Unfortunately still no success.

# pf.conf:

ext_if="xnf0"

match in log on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR \
rdr-to 129.128.5.194 port 80

match out log on $ext_if proto tcp to 129.128.5.194 port 80 received-on \
$ext_if nat-to $ext_if

match out log quick on $ext_if inet all tagged RDR \
nat-to $ext_if

server_open="{ 80,110,443,25,587,465 }"

pass in log on $ext_if inet proto tcp from any port 1024:65535 to $ext_if
port $server_open tag n_traffic

#block all to start
block all
pass quick tagged RDR
pass quick tagged n_traffic
pass out on $ext_if




On 2/14/2020 6:30 AM, Fabio Martins wrote:

Hi Nick,

Thanks. I applied both rules below, unfortunately I am still only
hitting
rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
test). I tried inverting the order, too, but no luck.

#1
match in on $ext_if proto tcp from  to ($ext_if) port 25 \
rdr-to 200.200.200.200 port 

#2
match out on $ext_if proto tcp to 200.200.200.200 port  received-on
\
$ext_if nat-to ($ext_if)

--
Fabio Martins


Odd, are you allowing the traffic with an appropriate pass rule later?

I use tagging for rules related to rdr and nat to keep things simple,
here is the full working setup I used to bounce port 8099 on the
external interface to www.openbsd.org port 80.

#Fun reverse redirection of www.openbsd.org
match in on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR
rdr-to 129.128.5.194 port 80
match out on $ext_if proto tcp to 129.128.5.194 port 80 received-on
$ext_if nat-to $ext_if

#block all to start
block log all
pass quick tagged RDR
pass out on $ext_if


Make sure you are testing from an external host of course.









May be a dumb question, but do you have net.inet.ip.forwarding=1 set?


tcpdump of a successful test connection:
c.c.c.c = remote test client on internet
r.r.r.r = firewall external IP

pf# tcpdump -ni vmx1 port 8099 or host 129.128.5.194
tcpdump: listening on vmx1, link-type EN10MB
14:34:09.270237 c.c.c.c.63091 > r.r.r.r.8099: S 3178148684:3178148684(0) 
win 64240  [tos 0x20]
14:34:09.270303 r.r.r.r.62530 > 129.128.5.194.80: S 
3178148684:3178148684(0) win 64240 8,nop,nop,sackOK> [tos 0x20]
14:34:09.342800 129.128.5.194.80 > r.r.r.r.62530: S 
3355699325:3355699325(0) ack 3178148685 win 16384 1460,nop,nop,sackOK,nop,wscale 6> (DF) [tos 0x20]
14:34:09.342830 r.r.r.r.8099 > c.c.c.c.63091: S 3355699325:3355699325(0) 
ack 3178148685 win 16384  [tos 0x20]

14:34:09.372450 c.c.c.c.63091 > r.r.r.r.8099: . ack 1 win 1026 [tos 0x20]
14:34:09.372461 c.c.c.c.63091 > r.r.r.r.8099: P 1:436(435) ack 1 win 
1026 [tos 0x20]
14:34:09.372477 r.r.r.r.62530 > 129.128.5.194.80: . ack 1 win 1026 [tos 
0x20]
14:34:09.372500 r.r.r.r.62530 > 129.128.5.194.80: P 1:436(435) ack 1 win 
1026 [tos 0x20]
14:34:09.450714 129.128.5.194.80 > r.r.r.r.62530: P 1:197(196) ack 436 
win 273 (DF) [tos 0x20]
14:34:09.450716 129.128.5.194.80 > r.r.r.r.62530: . 197:1657(1460) ack 
436 win 273 (DF) [tos 0x20]
14:34:09.450759 r.r.r.r.8099 > c.c.c.c.63091: P 1:197(196) ack 436 win 
273 [tos 0x20]
14:34:09.450774 r.r.r.r.8099 > c.c.c.c.63091: . 197:1657(1460) ack 436 
win 273 [tos 0x20]

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Martins]

I am trying now only with the redirect to www.openbsd.org, if it works, I
am sure it can be adapted to my case.

Unfortunately still no success.

# pf.conf:

ext_if="xnf0"

match in log on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR \
rdr-to 129.128.5.194 port 80

match out log on $ext_if proto tcp to 129.128.5.194 port 80 received-on \
$ext_if nat-to $ext_if

match out log quick on $ext_if inet all tagged RDR \
nat-to $ext_if

server_open="{ 80,110,443,25,587,465 }"

pass in log on $ext_if inet proto tcp from any port 1024:65535 to $ext_if
port $server_open tag n_traffic

#block all to start
block all
pass quick tagged RDR
pass quick tagged n_traffic
pass out on $ext_if


>
>
> On 2/14/2020 6:30 AM, Fabio Martins wrote:
>> Hi Nick,
>>
>> Thanks. I applied both rules below, unfortunately I am still only
>> hitting
>> rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
>> test). I tried inverting the order, too, but no luck.
>>
>> #1
>> match in on $ext_if proto tcp from  to ($ext_if) port 25 \
>> rdr-to 200.200.200.200 port 
>>
>> #2
>> match out on $ext_if proto tcp to 200.200.200.200 port  received-on
>> \
>> $ext_if nat-to ($ext_if)
>>
>> --
>> Fabio Martins
>>
>
> Odd, are you allowing the traffic with an appropriate pass rule later?
>
> I use tagging for rules related to rdr and nat to keep things simple,
> here is the full working setup I used to bounce port 8099 on the
> external interface to www.openbsd.org port 80.
>
> #Fun reverse redirection of www.openbsd.org
> match in on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR
> rdr-to 129.128.5.194 port 80
> match out on $ext_if proto tcp to 129.128.5.194 port 80 received-on
> $ext_if nat-to $ext_if
>
> #block all to start
> block log all
> pass quick tagged RDR
> pass out on $ext_if
>
>
> Make sure you are testing from an external host of course.
>
>
>
>
>

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Almeida]

Hi Fabio (xará),
Apparently I achieved this with these rules:
--
pass out log on hvn0 inet proto tcp from any port 1024:65535 to 8.8.8.8
port =  flags S/SA label "TESTE LISTA"
pass in on hvn0 inet proto tcp from any port 1024:65535 to 10.101.0.17 port
= 25 flags S/SA label "TESTE LISTA" tag TESTE rdr-to 8.8.8.8 port 
match out log quick on hvn0 inet all label "TESTE LISTA" tagged TESTE
nat-to 10.101.0.17
--
Of course there's room for improvement, be it simplify the rules or make it
more specific.
Maybe I needed three rules because I use "block log" as a default rule so:
"block in" and "block out" by default.
Here is the tcpdump output:
--
rule 0/(match) match in on hvn0: 10.101.0.24.47964 > 10.101.0.17.25: S
3824310731:3824310731(0) win 42340  (DF)
rule 53/(match) match out on hvn0: 10.101.0.17.60331 > 8.8.8.8.: S
3824310731:3824310731(0) win 42340 
rule 16/(match) pass out on hvn0: 10.101.0.17.60331 > 8.8.8.8.: S
3824310731:3824310731(0) win 42340 
--
Regards,
Fabio Almeida

On Fri, Feb 14, 2020 at 8:33 AM Fabio Martins <
fm+obsd+misc+l...@phosphorusnetworks.com> wrote:

>
> Hi Nick,
>
> Thanks. I applied both rules below, unfortunately I am still only hitting
> rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
> test). I tried inverting the order, too, but no luck.
>
> #1
> match in on $ext_if proto tcp from  to ($ext_if) port 25 \
> rdr-to 200.200.200.200 port 
>
> #2
> match out on $ext_if proto tcp to 200.200.200.200 port  received-on \
> $ext_if nat-to ($ext_if)
>
> --
> Fabio Martins
>
> > Hi Fabio,
> >
> > I believe this will do what you want, seemed to work in quick testing
> > here, adjust to suit your environment.
> >
> >
> > match in on $ext_if proto tcp from  to ($ext_if) port 25
> > rdr-to 200.200.200.200 port 
> > match out on $ext_if proto tcp to 200.200.200.200 port  received-on
> > $ext_if nat-to ($ext_if)
> >
>
>
>

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Nick Gustas]

On 2/14/2020 6:30 AM, Fabio Martins wrote:

Hi Nick,

Thanks. I applied both rules below, unfortunately I am still only hitting
rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
test). I tried inverting the order, too, but no luck.

#1
match in on $ext_if proto tcp from  to ($ext_if) port 25 \
rdr-to 200.200.200.200 port 

#2
match out on $ext_if proto tcp to 200.200.200.200 port  received-on \
$ext_if nat-to ($ext_if)

--
Fabio Martins



Odd, are you allowing the traffic with an appropriate pass rule later?

I use tagging for rules related to rdr and nat to keep things simple, 
here is the full working setup I used to bounce port 8099 on the 
external interface to www.openbsd.org port 80.


#Fun reverse redirection of www.openbsd.org
match in on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR 
rdr-to 129.128.5.194 port 80
match out on $ext_if proto tcp to 129.128.5.194 port 80 received-on 
$ext_if nat-to $ext_if


#block all to start
block log all
pass quick tagged RDR
pass out on $ext_if


Make sure you are testing from an external host of course.

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Martins]

Hi Nick,

Thanks. I applied both rules below, unfortunately I am still only hitting
rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
test). I tried inverting the order, too, but no luck.

#1
match in on $ext_if proto tcp from  to ($ext_if) port 25 \
rdr-to 200.200.200.200 port 

#2
match out on $ext_if proto tcp to 200.200.200.200 port  received-on \
$ext_if nat-to ($ext_if)

--
Fabio Martins

> Hi Fabio,
>
> I believe this will do what you want, seemed to work in quick testing
> here, adjust to suit your environment.
>
>
> match in on $ext_if proto tcp from  to ($ext_if) port 25
> rdr-to 200.200.200.200 port 
> match out on $ext_if proto tcp to 200.200.200.200 port  received-on
> $ext_if nat-to ($ext_if)
>

Re: Replace PF rule + inetd Proxy with 2 PF rules

[Nick Gustas]

Hi Fabio,

I believe this will do what you want, seemed to work in quick testing 
here, adjust to suit your environment.



match in on $ext_if proto tcp from  to ($ext_if) port 25 
rdr-to 200.200.200.200 port 
match out on $ext_if proto tcp to 200.200.200.200 port  received-on 
$ext_if nat-to ($ext_if)




On 2/13/2020 11:56 AM, Fabio Martins wrote:

Hi,

I am trying to redirect + NAT incoming packets without the need of a TCP
Proxy.

Currently I have the following setup to redirect hosts abusing SMTP to an
email trap:

inetd listening in 127.0.0.1:8000 and redirecting to an external host

# inetd.conf
127.0.0.1:8000  stream tcp nowait _inetd_proxy /usr/bin/nc nc -w 20
200.200.200.200 

and  + pf rule redirecting the hosts:

# pf.conf

table  persist file "/etc/pf/tables/spammers.txt

pass in log on egress proto tcp from  to any port 25 \
  rdr-to 127.0.0.1 port 8000

I am trying to remove the inetd from the setup.
With Linux iptables I would do a DNAT + MASQUERADE, but with PF I already
tried:

# pf.conf

#1
pass in log on xnf0 proto tcp from  to any port  nat-to xnf0

#2
pass in log on egress proto tcp from  to any port 25 \
  rdr-to 200.200.200.200 port 


Rule #2 is correctly applied and changes the destination address to
200.200.200.200, but rule #1 (NAT) isnt applied.

I believe it is possible to NAT an external connection without using a TCP
Proxy.

Tried also the example from here: https://www.openbsd.org/faq/pf/rdr.html

pass in on $int_if proto tcp from $int_net to egress port 80 rdr-to $server
pass out on $int_if proto tcp to $server port 80 received-on $int_if
nat-to $int_if

Without success.

Thanks!

Replace PF rule + inetd Proxy with 2 PF rules

[Fabio Martins]

Hi,

I am trying to redirect + NAT incoming packets without the need of a TCP
Proxy.

Currently I have the following setup to redirect hosts abusing SMTP to an
email trap:

inetd listening in 127.0.0.1:8000 and redirecting to an external host

# inetd.conf
127.0.0.1:8000  stream tcp nowait _inetd_proxy /usr/bin/nc nc -w 20
200.200.200.200 

and  + pf rule redirecting the hosts:

# pf.conf

table  persist file "/etc/pf/tables/spammers.txt

pass in log on egress proto tcp from  to any port 25 \
 rdr-to 127.0.0.1 port 8000

I am trying to remove the inetd from the setup.
With Linux iptables I would do a DNAT + MASQUERADE, but with PF I already
tried:

# pf.conf

#1
pass in log on xnf0 proto tcp from  to any port  nat-to xnf0

#2
pass in log on egress proto tcp from  to any port 25 \
 rdr-to 200.200.200.200 port 


Rule #2 is correctly applied and changes the destination address to
200.200.200.200, but rule #1 (NAT) isnt applied.

I believe it is possible to NAT an external connection without using a TCP
Proxy.

Tried also the example from here: https://www.openbsd.org/faq/pf/rdr.html

pass in on $int_if proto tcp from $int_net to egress port 80 rdr-to $server
pass out on $int_if proto tcp to $server port 80 received-on $int_if
nat-to $int_if

Without success.

Thanks!

-- 
Fabio Martins

systat strange live display on pf rules activity.

[Eric Huiban]

Hello,

Functionnally pf is OK : packets are blocked or passed according to 
what's expected. But when i use systat for live examination of what 
appends amongst the rules there is no hit on match rules with IP list 
while there's on relevant block rule.


Did someone notice such behaviour, or did i missed something once again 
? Google and others only output some garbage about this question.


my pf is organised around an header pf.conf which calls sub pf files and 
puts each of them in an anchor ( one for IPv4 wan, one for IPv4 local, 
one for IPv6 wan, etc). It is organised with a lot of match rules and a 
few block/pass rules. (One list to rule them all, One match to find 
them, One block to bring them all and in the darkness bind them)


I changed the orders of rules and anchors : no effect. What i currently 
use is here :


(rogueIPs list is the automatically build from several reliable sources 
and processed to get clean without dups, annoyers is my manually fed table)


table  persist file "/etc/rogueIPs.tbl" counters
table  persist file "/etc/annoyers.tbl" counters

match in on $EXIT inet from {,  } to any tag 
"ROGUED:$if"
match out on $EXIT inet from any to {,} tag 
"ROGUED:$if"


block return quick on $EXIT inet tagged "ROGUED:$if"

Regards,
Eric.

Re: Simplifying pf-rules

[Kenneth Gober]

On Thu, Jan 4, 2018 at 8:09 AM, Jon S  wrote:
> This led to my first experieces with pf. After some work I came up with
> whats below. It works as I want it to work, but I wonder if there is a way
> to create a rule where incomming traffic to the internal NIC (re0) is
> passed if it is targeted for em0 (external, internet NIC)? The current
> solution would require an update of the "pass in on re0 to
> !re0:network"-rule if another NIC is added (lets say a DMZ).
>
> [ruleset omitted]

For years I used a vaguely similar ruleset on my own router; similar
in the sense that it used "pass out all" and relied only on filtering
inbound traffic.

But over time I've decided that it's better to block both inbound and
outbound by default, then explicitly allow traffic in 3 categories:
1. traffic to this router as the final destination (for services
running on the router)
2. traffic to be forwarded (with NAT if needed)
3. traffic that originates from this router

#3 is especially important if the router is also running other
services which may make announcements on the network.  If you are
running Samba for example you probably don't want to send
announcements to the Internet.  Yes, this means you need to know
explicitly what your services are doing so you know what to enable.
On the plus side it means nothing gets sent to the Internet simply
because you didn't know you needed to turn it off.

To differentiate between #1 and #2 I use tags to mark packets as
ACCEPT or FORWARD.  Only the packets tagged FORWARD are allowed to
pass out.  Inbound packets start with a TBD tag that basically means
"not yet tagged" and ensures that once a rule sets an ACCEPT or
FORWARD tag, other rules don't then try to re-tag it.

Also, I try to avoid using ! anywhere.  It is too easy to make
mistakes with it, and configuration mistakes are the #1 reason
unwanted traffic will get through your firewall.

A very stripped down subset of my ruleset follows, showing the
essentials.  em0 is my internal interface, em1 is my 'guest' interface
(that friends can use for their WiFi when they visit) and em2 connects
to my Internet cable modem (I don't use variable name substitutions
for unrelated reasons, but you may want to do so anyway).  I have
included em1 because it's very similar to a DMZ network.  I am running
several services on my router so I've also included the DNS and
ftp-proxy rules because they are good examples.  Note that I make
extensive use of "quick" to give "first matching rule wins" behavior.
I think this is easier to understand.

# pf.conf - PF configuration file

# tables
table  const { 10/8, 172.16/12, 192.168/16 }

# by default, block all traffic not explicitly allowed
block in log all tag TBD
block out log all

# ACCEPT - traffic that should be accepted by this router (not forwarded)

# accept ping requests
pass in log quick on em0 inet proto icmp from em0:network to (self)
icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on em1 inet proto icmp from em1:network to em1
icmp-type echoreq tagged TBD tag ACCEPT

# accept DNS requests
pass in log quick on em0 inet proto { udp tcp } to (self) port domain
tagged TBD tag ACCEPT
pass in log quick on em1 inet proto { udp tcp } from em1:network to
em1 port domain tagged TBD tag ACCEPT

# accept SSH connections
pass in log quick on em0 inet proto tcp from em0:network to (self)
port ssh tagged TBD tag ACCEPT
pass in log quick on em1 inet proto tcp from em1:network to em1 port
ssh tagged TBD tag ACCEPT

# FORWARD / Inbound - traffic that should be forwarded by this router

# block non-Internet traffic from public (guest) network
block in log quick on em1 to  tagged TBD

# pass internal FTP traffic
pass in log quick on em0 inet proto tcp from em0:network to 192.168/18
port ftp tagged TBD tag FORWARD

# proxy external FTP traffic
pass in log quick on em0 inet proto tcp from em0:network to port ftp
divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
pass in log quick on em1 inet proto tcp from em1:network to port ftp
divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
anchor "ftp-proxy/*"

# default forwarding rules for traffic from private network
pass in log quick on em0 from em0:network to 192.168/18 tagged TBD tag FORWARD
pass in log quick on em0 from em0:network modulate state tagged TBD tag FORWARD

# default forwarding rules for traffic from public (guest) network
pass in log quick on em1 from em1:network to em1:network tagged TBD tag FORWARD
pass in log quick on em1 from em1:network modulate state tagged TBD tag FORWARD

# game server
pass in log quick on em2 inet proto udp to (em2) port 27016 rdr-to
192.168.24.50 tagged TBD tag FORWARD

# FORWARD / Outbound

# forward internal traffic
pass out log quick on em0 tagged FORWARD
pass out log quick on em1 tagged FORWARD

# block unroutable external traffic
block out log quick on em2 to  tagged FORWARD

# forward external traffic
pass out log quick on em2 nat-to (em2) tagged FORWARD

# Outbound - traffic that 

Re: Simplifying pf-rules

[Jon S]

Marko: Thanks for your input. Your proposals got me thinking a few steps
further.

I now came up with the following solution which have all propertiers i want:

pass in on re0 inet to !all:network
pass in on re0 inet to em0:network # Just in case we would need to interact
# with some other service on the same segment...
block in quick log on re0 inet to em0 # ... but not our own IP

The above lines replaces my initial rule "pass in on re0 to !re0:network"


2018-01-04 16:29 GMT+01:00 Marko Cupać :

> On Thu, 4 Jan 2018 14:09:50 +0100
> Jon S  wrote:
>
> > Hello misc!
> >
> > My OpenBSD file server just became a router too (after getting a new
> > internet connection where the provider does not include a router in
> > the subscription).
>
> If possible, I'd avoid combining file server and firewall services on
> single box
>

> > This led to my first experieces with pf. After some work I came up
> > with whats below. It works as I want it to work, but I wonder if
> > there is a way to create a rule where incomming traffic to the
> > internal NIC (re0) is passed if it is targeted for em0 (external,
> > internet NIC)? The current solution would require an update of the
> > "pass in on re0 to !re0:network"-rule if another NIC is added (lets
> > say a DMZ).
>
> All my pf rulesets start with defining interface macros so they are
> more readable, and also more flexible (this way changing NIC with
> different driver needs one line changed, instead of all lines in the
> ruleset referencing that interface):
>
> # INTERFACE MACROS
> if_int = "re0"
> if_ext = "em0"
>
> > set skip on lo0
> >
> > # Block everything everywhere by default
> > block log all
>
> I prefer to put "match" section above default "block log all" rule.
> It's more logical to me, as something being "matched" has no impact if
> it's not "passed" or "blocked" later on in the ruleset.
>
> > # NAT local network to external
> > match out on em0 inet from re0:network nat-to (em0)
> >
> > # Allow all outgoing traffic
> > pass out on {em0, re0}
> >
> > # Allow only specific services on this machine to be accessed from
> > # local network
> > pass in on re0 inet proto tcp to port ssh # ssh
> > pass in on re0 inet proto icmp# icmp
> > pass in on re0 inet proto tcp to port 445 # samba
>
> Your description line does not describe accurately what next three
> lines do - as destination IP is not present, "to any" is assumed, so
> more accurate description would be "Allow specific services on any
> machine be accessed from local network".
>
> If you wanted your ruleset to match description line, and your
> services listen on internal NIC, you would do something like:
>
> pass in on $if_int inet proto tcp  from re0:network to re0 port ssh
> pass in on $if_int inet proto icmp from re0:network to re0
> pass in on $if_int inet proto tcp  from re0:network to re0 port 445
>
> >
> > #pass in on re0 inet to em0:network # This does not work, since the
> > #mask for this IF will only let traffic through to the limitied set of
> > #IPs on the same C-segment as em0. That would probably be a set of
> > #other customers at the nework operator...
> >
> > # This works, but will require an update if any furter NIC is involved
> > # later
> > pass in on re0 to !re0:network
>
> There are multiple ways to achieve this. One of them would be passing
> everything on $if_int, and blocking what you don't want later (if
> "quick" keyword is not used, last matching rule wins):
>
> pass in on $if_int
> block in on $if_int inet proto tcp from $if_int:network to \
>   $if_int port { !=ssh !=445 }
>
> The other one would be blocking unwanted stuff quickly early in the
> ruleset, and passing what you want later on:
>
>   block in quick on $if_int inet proto tcp from $if_int:network to \
>   $if_int port { !=ssh !=445 }
> pass in on $if_int
>
> Both examples block only TCP to internal NIC, so blocking other
> protocols if there are any on the firewall also needs to be done.
> >
> > # I would like something like this to work, so that future added NICs
> > # wont open new unwanted paths
> > #pass in on re0 to em0
> >
> > # Allow only incomming SSH to external NIC
> > pass in on em0 inet proto tcp to port ssh
>
> In the end, your ruleset seems quite minimal. I suggest you start
> worrying about new NIC once you add it. For now it would be better to
> play around with pfctl -vvsr, systat states/rules, tcpdumping pflog etc.
>
> Hope this helps,
>
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/
>



-- 
<>
Jon Sjöstedt
Gamla Björboholmsvägen 2
443 72 GRÅBO

Mobil 0735 - 029 557

jonsjost...@gmail.com jonsjost...@hotmail.com

Re: Simplifying pf-rules

[Marko Cupać]

On Thu, 4 Jan 2018 14:09:50 +0100
Jon S  wrote:

> Hello misc!
> 
> My OpenBSD file server just became a router too (after getting a new
> internet connection where the provider does not include a router in
> the subscription).

If possible, I'd avoid combining file server and firewall services on
single box.

> This led to my first experieces with pf. After some work I came up
> with whats below. It works as I want it to work, but I wonder if
> there is a way to create a rule where incomming traffic to the
> internal NIC (re0) is passed if it is targeted for em0 (external,
> internet NIC)? The current solution would require an update of the
> "pass in on re0 to !re0:network"-rule if another NIC is added (lets
> say a DMZ).

All my pf rulesets start with defining interface macros so they are
more readable, and also more flexible (this way changing NIC with
different driver needs one line changed, instead of all lines in the
ruleset referencing that interface):

# INTERFACE MACROS
if_int = "re0"
if_ext = "em0"

> set skip on lo0
> 
> # Block everything everywhere by default
> block log all

I prefer to put "match" section above default "block log all" rule.
It's more logical to me, as something being "matched" has no impact if
it's not "passed" or "blocked" later on in the ruleset.

> # NAT local network to external
> match out on em0 inet from re0:network nat-to (em0)
> 
> # Allow all outgoing traffic
> pass out on {em0, re0}
> 
> # Allow only specific services on this machine to be accessed from
> # local network
> pass in on re0 inet proto tcp to port ssh # ssh
> pass in on re0 inet proto icmp# icmp
> pass in on re0 inet proto tcp to port 445 # samba

Your description line does not describe accurately what next three
lines do - as destination IP is not present, "to any" is assumed, so
more accurate description would be "Allow specific services on any
machine be accessed from local network".

If you wanted your ruleset to match description line, and your
services listen on internal NIC, you would do something like:

pass in on $if_int inet proto tcp  from re0:network to re0 port ssh
pass in on $if_int inet proto icmp from re0:network to re0
pass in on $if_int inet proto tcp  from re0:network to re0 port 445

> 
> #pass in on re0 inet to em0:network # This does not work, since the
> #mask for this IF will only let traffic through to the limitied set of
> #IPs on the same C-segment as em0. That would probably be a set of
> #other customers at the nework operator...
> 
> # This works, but will require an update if any furter NIC is involved
> # later
> pass in on re0 to !re0:network

There are multiple ways to achieve this. One of them would be passing
everything on $if_int, and blocking what you don't want later (if
"quick" keyword is not used, last matching rule wins):

pass in on $if_int
block in on $if_int inet proto tcp from $if_int:network to \
  $if_int port { !=ssh !=445 }

The other one would be blocking unwanted stuff quickly early in the
ruleset, and passing what you want later on:

block in quick on $if_int inet proto tcp from $if_int:network to \
  $if_int port { !=ssh !=445 }
pass in on $if_int

Both examples block only TCP to internal NIC, so blocking other
protocols if there are any on the firewall also needs to be done.
> 
> # I would like something like this to work, so that future added NICs
> # wont open new unwanted paths
> #pass in on re0 to em0
> 
> # Allow only incomming SSH to external NIC
> pass in on em0 inet proto tcp to port ssh

In the end, your ruleset seems quite minimal. I suggest you start
worrying about new NIC once you add it. For now it would be better to
play around with pfctl -vvsr, systat states/rules, tcpdumping pflog etc.

Hope this helps,

-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Simplifying pf-rules

[Jon S]

Hello misc!

My OpenBSD file server just became a router too (after getting a new
internet connection where the provider does not include a router in the
subscription).

This led to my first experieces with pf. After some work I came up with
whats below. It works as I want it to work, but I wonder if there is a way
to create a rule where incomming traffic to the internal NIC (re0) is
passed if it is targeted for em0 (external, internet NIC)? The current
solution would require an update of the "pass in on re0 to
!re0:network"-rule if another NIC is added (lets say a DMZ).

set skip on lo0

# Block everything everywhere by default
block log all

# NAT local network to external
match out on em0 inet from re0:network nat-to (em0)

# Allow all outgoing traffic
pass out on {em0, re0}

# Allow only specific services on this machine to be accessed from
# local network
pass in on re0 inet proto tcp to port ssh # ssh
pass in on re0 inet proto icmp# icmp
pass in on re0 inet proto tcp to port 445 # samba

#pass in on re0 inet to em0:network # This does not work, since the
#mask for this IF will only let traffic through to the limitied set of
#IPs on the same C-segment as em0. That would probably be a set of
#other customers at the nework operator...

# This works, but will require an update if any furter NIC is involved
# later
pass in on re0 to !re0:network

# I would like something like this to work, so that future added NICs
# wont open new unwanted paths
#pass in on re0 to em0

# Allow only incomming SSH to external NIC
pass in on em0 inet proto tcp to port ssh


-- 
<>
Jon Sjöstedt

jonsjost...@gmail.com

Re: trunk0 link aggregation interface and PF rules not working

[Marcus MERIGHI]

den...@mindall.org (Denis), 2017.12.30 (Sat) 13:15 (CET):
> Trying to make aggregation using two wireless interfaces on OpenBSD 6.1
> amd64 but unsuccessful.
> 
> Both wireless interfaces successfully connects to its networks and have

these are different networks?

> DHCP assigned IP addresses.
> Both configs are listed below:
> 
> $ cat /etc/hostname.iwn0
> dhcp bssid BSSID_MAC nwid NWID wpa wpakey WPAKEY wpaprotos wpa2
> $ cat /etc/hostname.athn0
> dhcp bssid BSSID_MAC1 nwid NWID1 wpa wpakey WPAKEY1 wpaprotos wpa2

"dhcp" - but trunkport interfaces do not have the IP themselves!

> For trunk0 intefrace I have assigned different modes available while
> testing: failover, lacp, and loadbalance
> 
> $cat /etc/hostname.trunk0
> trunkproto failover trunkport iwn0 trunkport athn0 192.168.20.1 netmask
> 255.255.255.0
> #trunkproto lacp trunkport iwn0 trunkport athn0 192.168.20.1 netmask
> 255.255.255.0
> #trunkproto loadbalance trunkport iwn0 trunkport athn0 192.168.20.1
> netmask 255.255.255.0

do not assign an IP and run dhclient on trunk0!

> By PF I set trunk0 as an egress interface in PF instead of previously

PF does not set the egress interface, it just happens to know where the
default route points to

> used athn0 and iwn0 for outgoing traffic.
> 
> #cat /etc/pf.conf
> 
> ext_iftrunk0
> #ext_ifathn0
> #ext_ifiwn0

Where's the interesting part of pf.conf(5)?

> $cat /etc/sysctl.conf
> 
> net.inet.ip.forwarding=1
> #net.inet.ip.mforwarding=1
> #net.inet.ip.multipath=1

No need for that unless you use the machine with the two wireless
interfaces as a router.

> No traffic goes over trunk0, 

How is your system supposed to know you want your packets delivered via
trunk0? No route points towards it, exept the one for 192.168.20.1, I
suppose. Show the routes! (netstat -anrfinet)

> but all perfectly works if I reverse my PF config to iwn0 or athn0
> interfaces as egress ones.

PF just shows your problems, it is not the cause.

> Please give an advice what I'm doing wrong.

sorry to put it that bluntly, but read trunk(4), EXAMPLES:

# ifconfig em0 up
# ifconfig ath0 nwid my_net up
# ifconfig trunk0 trunkproto failover trunkport em0 trunkport ath0 \
192.168.1.1 netmask 255.255.255.0

The trunkport interfaces do not have an IP config. The trunkX has!

Happy new year, Marcus

Fwd: Re: trunk0 link aggregation interface and PF rules not working

[Krzysztof Strzeszewski]

--- Treść przekazanej wiadomości ---
Temat:  Re: trunk0 link aggregation interface and PF rules not working
Data:   Sat, 30 Dec 2017 14:09:16 +0100
Nadawca:Krzysztof Strzeszewski <krz...@krzy.ch>
Adresat:Denis <den...@mindall.org>



link aggregation uses at the same time two interface, link failover
backup ones interface

W dniu 30.12.2017 o 13:15, Denis pisze:
> Trying to make aggregation using two wireless interfaces on OpenBSD 6.1
> amd64 but unsuccessful.
>
> Both wireless interfaces successfully connects to its networks and have
> DHCP assigned IP addresses.
> Both configs are listed below:
>
> $ cat /etc/hostname.iwn0
> dhcp bssid BSSID_MAC nwid NWID wpa wpakey WPAKEY wpaprotos wpa2
>
> $ cat /etc/hostname.athn0
> dhcp bssid BSSID_MAC1 nwid NWID1 wpa wpakey WPAKEY1 wpaprotos wpa2
>
> For trunk0 intefrace I have assigned different modes available while
> testing: failover, lacp, and loadbalance
>
> $cat /etc/hostname.trunk0
> trunkproto failover trunkport iwn0 trunkport athn0 192.168.20.1 netmask
> 255.255.255.0
> #trunkproto lacp trunkport iwn0 trunkport athn0 192.168.20.1 netmask
> 255.255.255.0
> #trunkproto loadbalance trunkport iwn0 trunkport athn0 192.168.20.1
> netmask 255.255.255.0
>
> By PF I set trunk0 as an egress interface in PF instead of previously
> used athn0 and iwn0 for outgoing traffic.
>
> #cat /etc/pf.conf
> 
> ext_iftrunk0
> #ext_ifathn0
> #ext_ifiwn0
> .
>
> $cat /etc/sysctl.conf
> 
> net.inet.ip.forwarding=1
> #net.inet.ip.mforwarding=1
> #net.inet.ip.multipath=1
> 
>
> No traffic goes over trunk0, but all perfectly works if I reverse my PF
> config to iwn0 or athn0 interfaces as egress ones.
>
> Please give an advice what I'm doing wrong.
>
> Thank you! 
>
>
>
>
>
>

trunk0 link aggregation interface and PF rules not working

[Denis]

Trying to make aggregation using two wireless interfaces on OpenBSD 6.1
amd64 but unsuccessful.

Both wireless interfaces successfully connects to its networks and have
DHCP assigned IP addresses.
Both configs are listed below:

$ cat /etc/hostname.iwn0
dhcp bssid BSSID_MAC nwid NWID wpa wpakey WPAKEY wpaprotos wpa2

$ cat /etc/hostname.athn0
dhcp bssid BSSID_MAC1 nwid NWID1 wpa wpakey WPAKEY1 wpaprotos wpa2

For trunk0 intefrace I have assigned different modes available while
testing: failover, lacp, and loadbalance

$cat /etc/hostname.trunk0
trunkproto failover trunkport iwn0 trunkport athn0 192.168.20.1 netmask
255.255.255.0
#trunkproto lacp trunkport iwn0 trunkport athn0 192.168.20.1 netmask
255.255.255.0
#trunkproto loadbalance trunkport iwn0 trunkport athn0 192.168.20.1
netmask 255.255.255.0

By PF I set trunk0 as an egress interface in PF instead of previously
used athn0 and iwn0 for outgoing traffic.

#cat /etc/pf.conf

ext_iftrunk0
#ext_ifathn0
#ext_ifiwn0
.

$cat /etc/sysctl.conf

net.inet.ip.forwarding=1
#net.inet.ip.mforwarding=1
#net.inet.ip.multipath=1


No traffic goes over trunk0, but all perfectly works if I reverse my PF
config to iwn0 or athn0 interfaces as egress ones.

Please give an advice what I'm doing wrong.

Thank you! 

Re: PF Rules

[Peter N. M. Hansteen]

On 08/26/16 14:55, Leo Silva wrote:
> I'd like some help with the following rules on pf.
> I'm trying to block all https requests outgoing from my network and unblock
> just some IPs.
> The blocked IPs are allowed to access specifics sites that are placed in files
> with the domain names that I want to allow, the unblocked_ips and
> unblocked_sites files.

First, tcpdump is your friend. If something isn't working quite right,
you will need to dive in with tcpdump and some well placed log
statements on the rules you are studying in order to figure out where
your logic was too weak to begin with.

I suspect your problem may be overuse of the quick keyword. Remember,
once you hit a quick rule that matches, processing for that packet stops
right there.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

PF Rules

[Leo Silva]

Hello folks,

I'd like some help with the following rules on pf.
I'm trying to block all https requests outgoing from my network and unblock
just some IPs.
The blocked IPs are allowed to access specifics sites that are placed in files
with the domain names that I want to allow, the unblocked_ips and
unblocked_sites files.

The pf rules:
antispoof for bge0
antispoof for bge1
set block-policy drop
set skip on lo
it_ips="{ 192.168.255.35, 192.168.255.36, 192.168.255.20 }"
tcp_services="{ 20 21 25 80 110 143 465 587 993 1020 3389 5223 5310 8017 8080
8081 22000 }"
udp_services="{ domain ntp 5223 33433:33626 }"
icmp_types="{ echorep, echoreq, unreach, squench, redir, timex }"
table  persist file "/etc/pf/networks"
table  persist file "/etc/pf/martians"
table  persist file "/etc/pf/unblocked_sites"
table  persist file "/etc/pf/unblocked_ips"
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from lan:network to any nat-to (egress:0)
block return in on ! lo0 proto tcp to port 6000:6010
block in quick on egress from  to any
block return out quick on egress from any to 
block on egress all
anchor "ftp-proxy/*"
pass in quick on lan inet proto tcp to port 80 divert-to 192.168.255.254 port
3129
pass in quick on lan inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
pass in quick on lan inet proto tcp from $it_ips to lan:0 port 22
pass quick on lan inet proto icmp icmp-type $icmp_types
pass on lan all
pass out quick on egress inet proto tcp from  to port https
pass out quick on egress inet proto tcp from ! to
 port https
pass out quick on egress inet proto icmp icmp-type $icmp_types
pass out on egress inet proto tcp to port $tcp_services
pass out on egress inet proto udp to port $udp_services
With these rules applied all IPs, even those that are supposed to be
unblocked, are being blocked.

I'll appreciate any help.

Re: Syntax error in pf rules

[Marko Cupać]

On another occasion when Master Foo gave public instruction, an end
user, having heard tales of the Master's wisdom, came to him for
guidance.

He bowed three times to Master Foo. “I wish to learn the Great Way of
Unix,” he said “but the command line confuses me.”

Some of the onlooking neophytes began to mock the end user, calling him
“clueless” and saying that the Way of Unix is only for those of
discipline and intelligence.

The Master held up a hand for silence, and called the most obstreperous
of the neophytes who had mocked forward, to where he and the end user
sat.

“Tell me,” he asked the neophyte, “of the code you have written and the
works of design you have uttered.”

The neophyte began to stammer out a reply, but fell silent.

Master Foo turned to the end-user. “Tell me,” he inquired, “why do you
seek the Way?”

“I am discontent with the software I see around me,” the end user
replied. “It neither performs reliably nor pleases the eye and hand.
Having heard that the Unix way, though difficult, is superior, I seek
to cast aside all snares and delusions.”

“And what do you do in the world,” asked Master Foo, “that you must
strive with software?”

“I am a builder,” the end user replied, “Many of the houses of this
town were made under my chop.”

Master Foo turned back to the neophyte. “The housecat may mock the
tiger,” said the master, “but doing so will not make his purr into a
roar.”

Upon hearing this, the neophyte was enlightened.

http://catb.org/esr/writings/unix-koans/end-user.html
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Syntax error in pf rules

[Paul Suh]

> On Mar 30, 2016, at 10:58 PM, Adam Smith  wrote:
> 
> Are you the owner of misc@openbsd.org?
> 
>> --- dera...@cvs.openbsd.org wrote:
>> 
>> From: Theo de Raadt 
>> To: ken...@dcemail.com
>> 
>>> I know. Do you have proof that I hadn't put in my minimum effort
>>> before jumping to conclusions?

This guy has clearly just provided proof! :-D 

Now where did I put that spray can of troll repellent? 


--Paul

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Syntax error in pf rules

[Adam Smith]

Hi there,

>--- jub...@fastmail.com wrote:
>
>From: Jubjub Jenkins <jub...@fastmail.com>
>To: Adam Smith <ken...@dcemail.com>
>Cc: misc@openbsd.org
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 11:25:12 -0700
>
>
>The list owners are fascist anarchists and deem your "democracy" as
>bourgeois.

It's good to know that and that you're one of the fascists raving and 
demonstrating against poor Syrian refugees from war-torn Syria who are trying 
to find refuge in Europe.

People in the Linux community have warned me that there are far-right people 
with extremist views hiding within the OpenBSD community. I won't be surprised 
if you subscribe to the views of Greece's "Golden Dawn", Netherlands' "Partij 
voor de Vrijheid" and Germany's "Pegida" and 

Moreover your writing strongly indicates you're an Islamophobe as well.

In the meantime, please continue to be pro-fascist, anti-democratic and 
Islamophobic in whatever you do.
http://www.DCpages.com

Re: Syntax error in pf rules

[Theo de Raadt]

> I know. Do you have proof that I hadn't put in my minimum effort
> before jumping to conclusions?

Please stop picking fights with people.

The best approach is to leave the list.

Re: Syntax error in pf rules

[Adam Smith]

Are you the owner of misc@openbsd.org?

Who was trying to pick fights with me first? Have you investigated?

I feel sad for you and your OpenBSD project. Since its inception how much has 
the OpenBSD community grown? How much funds are there presently in your coffers?

In comparison FreeBSD has millions of fans and its foundation has received 
millions in donations from its members.

>--- dera...@cvs.openbsd.org wrote:
>
>From: Theo de Raadt <dera...@cvs.openbsd.org>
>To: ken...@dcemail.com
>cc: "Raf Czlonka" <rczlo...@gmail.com>, marko.cu...@mimar.rs, misc@openbsd.org
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 20:39:57 -0600
>
>> I know. Do you have proof that I hadn't put in my minimum effort
>> before jumping to conclusions?
>>
>Please stop picking fights with people.
>
>The best approach is to leave the list.
http://www.DCpages.com

Re: Syntax error in pf rules

[Adam Smith]

>--- rczlo...@gmail.com wrote:
>
>From: Raf Czlonka <rczlo...@gmail.com>
>To: Adam Smith <ken...@dcemail.com>
>Cc: Marko Cupać <marko.cu...@mimar.rs>, misc@openbsd.org
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 20:10:37 +0100
>
>
>
>Well, OpenBSD mailing lists have their own netiquette[0] so it would
>be nice if one did one's homework before posting such basic questions.

Do you've proof that I hadn't done my homework before posting basic questions? 

>Documentation (manual pages[1] and the FAQ[2]) is there for a reason
>and people work hard to write it all down and keep it up to date.

I couldn't find the answers to that particular question that I had asked in the 
manual pages and the FAQ.

>Minimum effort is a requirement.

I know. Do you have proof that I hadn't put in my minimum effort before jumping 
to conclusions?

Regards.

Adam
http://www.DCpages.com

Re: Syntax error in pf rules

[Kapetanakis Giannis]

On 30/03/16 17:05, Adam Smith wrote:

Hi Marko

In the rule below:

vpnip="{72.201.193.25,84.211.50.249,77.90.247.88,118.157.115.10,218.147.117.236}"


a. Must there be a space each before and after the = sign?
b. Must there be a space after the opening curly bracket and before the first 
IP address?
c. Must there be a space after the comma and before the next IP address?
d. Must there be a space after the last IP address and before the closing curly 
bracket?

Thanks in advance for your clarification.

Regards.

Adam




You can always test your config before applying it.
So, very easy to check it yourself.

pfctl -nf /etc/pf.conf

man pf

G

Re: Syntax error in pf rules

[Raf Czlonka]

On Wed, Mar 30, 2016 at 04:47:03PM BST, Adam Smith wrote:
> Hi Marko
> 
> Thank you for your detailed clarification. I really benefited from it.
> 
> >--- marko.cu...@mimar.rs wrote:
> >
> >From: Marko Cupać <marko.cu...@mimar.rs>
> >To: "Adam Smith" <ken...@dcemail.com>
> >Cc: <misc@openbsd.org>
> >Subject: Re: Syntax error in pf rules
> >Date: Wed, 30 Mar 2016 16:53:38 +0200
> >
> >
> >
> >There. I hope by posting this I didn't turn openbsd's misc@ into
> >askubuntu :)
> 
> Does it matter if misc@openbsd.org is an askubuntu of sorts?
> 
> I hope the person(s) in charge of this mailing list believes in
> democracy and freedom of speech and expression, provided that
> questions asked in the list pertain to OpenBSD and how to use it.
> 
> If people here are offended because they find my questions to be
> noobish, elementary, etc...they are welcome to press the "Delete"
> key to trash it.

Hi Adam,

Well, OpenBSD mailing lists have their own netiquette[0] so it would
be nice if one did one's homework before posting such basic questions.

Documentation (manual pages[1] and the FAQ[2]) is there for a reason
and people work hard to write it all down and keep it up to date.

Minimum effort is a requirement.

> Just so you know when I graduated from high school back in the
> early 70s, the personal computer, the pager or beeper, mobile or
> cell phone, internet, smartphones, Microsoft Windows, Mac OS, Linux,
> OpenBSD weren't invented yet. And in those days computing or IT
> wasn't taught in the high school curriculum.

Being an "old-timer" is not excuse for being a bit lazy ;^)

> Regards.
> 
> Adam
> http://www.DCpages.com

Regards,

Raf

[0] http://www.openbsd.org/mail.html
[1] http://man.openbsd.org/
[2] http://www.openbsd.org/faq/

Re: Syntax error in pf rules

[Jubjub Jenkins]

On Wed, Mar 30, 2016, at 08:47 AM, Adam Smith wrote:

> Does it matter if misc@openbsd.org is an askubuntu of sorts?
>

Yes, first off you have to understand that Ubuntu is geared towards the
retard market
that is why most of their userbase are refereed to as "Ubuntards". As
such, askubuntu
is for people that don't want to learn or read manuals they simply just
want to be 
spoonfed answers from anonymous drones. Ubuntu's "dad" actually escaped
into
space to avoid all the 'tards asking questions about video cards and
such. There is
no askubuntu in space.

This mailing list is for users who actually try to figure things out on
their own so
they can provide useful information and help, not just "Oh Ah-dumb, you
forgot to do this!!!"  
 
> I hope the person(s) in charge of this mailing list believes in democracy
> and freedom of speech and expression, provided that questions asked in
> the list pertain to OpenBSD and how to use it.

The list owners are fascist anarchists and deem your "democracy" as
bourgeois.
 
> If people here are offended because they find my questions to be noobish,
> elementary, etc...they are welcome to press the "Delete" key to trash it. 

We are offended because you think you can just dump a bunch of silly
questions on
us in the hope that we'll just answer 'em for ya instead of you reading
the manuals 
or trying to figure it out on your own.

> Just so you know when I graduated from high school back in the early 70s,
> the personal computer, the pager or beeper, mobile or cell phone,
> internet, smartphones, Microsoft Windows, Mac OS, Linux, OpenBSD weren't
> invented yet. And in those days computing or IT wasn't taught in the high
> school curriculum.

No one cares, and this is not a good excuse for not trying. When I was
young there were
no computers so I had to program in raw electricity. I would keep the
stack inside a 
bag of potatoes (they were called starch beans then) and the heap on a
blackboard
but of course, no one cares about that here.

Yours in Christ, 

JJ

Re: Syntax error in pf rules

[Adam Smith]

Hi Marko

In the rule below:

vpnip="{72.201.193.25,84.211.50.249,77.90.247.88,118.157.115.10,218.147.117.236}"


a. Must there be a space each before and after the = sign?
b. Must there be a space after the opening curly bracket and before the first 
IP address?
c. Must there be a space after the comma and before the next IP address?
d. Must there be a space after the last IP address and before the closing curly 
bracket?

Thanks in advance for your clarification.

Regards.

Adam

>--- marko.cu...@mimar.rs wrote:
>
>From: Marko Cupać <marko.cu...@mimar.rs>
>To: misc@openbsd.org
>Cc: <ken...@dcemail.com>
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 10:02:40 +0200
>
>
>As a side note, commas in pf macros appear to be optional. I prefer not
>to have them - they don't make rules more readable while consuming
>character space.
http://www.DCpages.com

Re: Syntax error in pf rules

[Adam Smith]

Hi Marko

Thank you for your detailed clarification. I really benefited from it.

>--- marko.cu...@mimar.rs wrote:
>
>From: Marko Cupać <marko.cu...@mimar.rs>
>To: "Adam Smith" <ken...@dcemail.com>
>Cc: <misc@openbsd.org>
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 16:53:38 +0200
>
>
>
>There. I hope by posting this I didn't turn openbsd's misc@ into
>askubuntu :)

Does it matter if misc@openbsd.org is an askubuntu of sorts?

I hope the person(s) in charge of this mailing list believes in democracy and 
freedom of speech and expression, provided that questions asked in the list 
pertain to OpenBSD and how to use it.

If people here are offended because they find my questions to be noobish, 
elementary, etc...they are welcome to press the "Delete" key to trash it. 

Just so you know when I graduated from high school back in the early 70s, the 
personal computer, the pager or beeper, mobile or cell phone, internet, 
smartphones, Microsoft Windows, Mac OS, Linux, OpenBSD weren't invented yet. 
And in those days computing or IT wasn't taught in the high school curriculum.

Regards.

Adam
http://www.DCpages.com

Re: Syntax error in pf rules

[Marko Cupać]

On Wed, 30 Mar 2016 07:05:56 -0700
"Adam Smith"  wrote:

> Hi Marko
>
> In the rule below:
>
>
vpnip="{72.201.193.25,84.211.50.249,77.90.247.88,118.157.115.10,218.147.117.2
36}"
>
>
> a. Must there be a space each before and after the = sign?
> b. Must there be a space after the opening curly bracket and before
> the first IP address? c. Must there be a space after the comma and
> before the next IP address? d. Must there be a space after the last
> IP address and before the closing curly bracket?

Adam,

all those are easy to test, but as I still remember lack of confidence
back in time when I was setting it up for the first time, but also warm
atmosphere and helpfulness of misc@ list back in a day, here you go:

a. Spaces are not required before and after the = sign, but I usually do
   the alignment using spaces for the purpose of readability, such as:

   users  = "{ 192.0.2.1 192.0.2.2 192.0.2.3 }"
   developers = "{ 192.0.2.1 192.0.2.2 192.0.2.3 }"
   ldap   = "{ 389 636 3268 3269 }"

b. Spaces are not mandatory after the curly bracket and first ip
   address, but I prefer to have them for the purpose of readability,
   as in example above.

c. Spaces after commas, before next ip addresses are not mandatory.
   However, I prefer to ditch commas entirely, separating ip addresses
   only with spaces as in example above.

d. Not mandatory, but nice to have IMHO.

Finally, `pfctl -nf' is your friend for testing ruleset before
applying it. In case you typed something incorrectly, it will spill
syntax error along with bad line numbers. If you are comfortable with
vi, you can jump to offending line by typing `:' (eg.
`:55') in command (default) mode. If not, you can paste complete ruleset
into editor you are comfortable with, which has line numbering (my
favourite is xfce's mousepad) and double-check offending line. Once you
have zero output of `pfctl -nf', load the ruleset with `pfctl -f'.

There. I hope by posting this I didn't turn openbsd's misc@ into
askubuntu :)
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Syntax error in pf rules

[Marko Cupać]

On Tue, 29 Mar 2016 08:45:11 -0700
"Adam Smith" <ken...@dcemail.com> wrote:

> Hi guys
>
> I have a syntax error in my pf rules. I hope you can help me fix it.
>
> Thanks.
>
> Adam
>
>
>
> -snippet of my pf rules-
>
> #This is where I change or add different IP addresses of VPN gateways
>
> vpnip="77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
> 66.85.14.205, 54.201.110.154"
>
>
>
> #Below is the rule that OpenBSD tells me there's a syntax error
>
> pass out quick on $wan proto tcp from any to $vpnip port 443 keep
> state
>
> -end of snippet-
> http://www.DCpages.com
>

As a side note, commas in pf macros appear to be optional. I prefer not
to have them - they don't make rules more readable while consuming
character space.
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Syntax error in pf rules

[Stuart Henderson]

On 2016-03-29, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> wrote:
> On 29/03/16 20:24, Adam Smith wrote:
>> Thanks, Taru, your solution works.
>>
>> Adam
>>
>> --- letcher.r...@gmail.com wrote:
>>
>> From: Letcher Ross <letcher.r...@gmail.com>
>> To: ken...@dcemail.com
>> Cc: OpenBSD Misc <misc@openbsd.org>
>> Subject: Re: Syntax error in pf rules
>> Date: Tue, 29 Mar 2016 08:55:32 -0700
>>
>> Per http://www.openbsd.org/faq/pf/macros.html
>>
>> It looks like your list should look like:
>>
>> vpnip = "{ 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
>> 66.85.14.205, 54.201.110.154 }"
>>
>> Taru
>>
>> On Tue, Mar 29, 2016 at 8:45 AM, Adam Smith <ken...@dcemail.com> wrote:
>
> You should better use a table and one rule than a list which will be 
> expanded to 6 rules.
>
> table  { 77.90.247.88, 112.119.192.26, 85.95.253.145, 
> 31.210.111.78, 66.85.14.205, 54.201.110.154 }
> pass out quick on $wan proto tcp from any to  port 443 keep state

With 6 addresses it will actually work due to the ruleset optimizer
collapsing them to a table, but you'll get very confused if you remove
one of the addresses as 5 *will* get expanded to multiple rules.

Compare:

echo 'pass from { 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78, 
66.85.14.205, 54.201.110.154 }' | pfctl -nvf -

echo 'pass from { 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78, 
66.85.14.205 }' | pfctl -nvf -

So yes it is definitely advisable to use an explicit table here.

Re: Syntax error in pf rules

[Kapetanakis Giannis]

On 29/03/16 20:24, Adam Smith wrote:

Thanks, Taru, your solution works.

Adam

--- letcher.r...@gmail.com wrote:

From: Letcher Ross <letcher.r...@gmail.com>
To: ken...@dcemail.com
Cc: OpenBSD Misc <misc@openbsd.org>
Subject: Re: Syntax error in pf rules
Date: Tue, 29 Mar 2016 08:55:32 -0700

Per http://www.openbsd.org/faq/pf/macros.html

It looks like your list should look like:

vpnip = "{ 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
66.85.14.205, 54.201.110.154 }"

Taru

On Tue, Mar 29, 2016 at 8:45 AM, Adam Smith <ken...@dcemail.com> wrote:


You should better use a table and one rule than a list which will be 
expanded to 6 rules.


table  { 77.90.247.88, 112.119.192.26, 85.95.253.145, 
31.210.111.78, 66.85.14.205, 54.201.110.154 }

pass out quick on $wan proto tcp from any to  port 443 keep state

G

Re: (2nd) Syntax error with pf rules

[Adam Smith]

Hi Bryan

Thanks for the link.

Yes, I am using the latest snapshot of OpenBSD.

Regards.

Adam

>--- br...@bsdjournal.net wrote:
>
>From: Bryan Vyhmeister <br...@bsdjournal.net>
>To: misc@openbsd.org
>Subject: Re: (2nd) Syntax error with pf rules
>Date: Tue, 29 Mar 2016 10:44:32 -0700
>
>Although you didn't specify (a dmesg would have been helpful), you are
>running -current that is post-5.8 and possibly close to what 5.9 will
>be. Although 5.9 is not officially released yet and this document is not
>necessarily complete, the issue is listed here:
> 
>http://www.openbsd.org/faq/upgrade59.html
> 
>It used to be listed at http://www.openbsd.org/faq/current.html
http://www.DCpages.com

Re: (2nd) Syntax error with pf rules

[Bryan Vyhmeister]

On Tue, Mar 29, 2016, at 10:26 AM, Adam Smith wrote:
> set debug urgent
>
> comes with the following error message:
>
> pfctl: unknown debug level "urgent"
> /etc/pfcustom.conf 13: error setting debuglevel "urgent"
> pfctl: Syntax error in config file: pf rules not loaded.
 
Although you didn't specify (a dmesg would have been helpful), you are
running -current that is post-5.8 and possibly close to what 5.9 will
be. Although 5.9 is not officially released yet and this document is not
necessarily complete, the issue is listed here:
 
http://www.openbsd.org/faq/upgrade59.html
 
It used to be listed at http://www.openbsd.org/faq/current.html
 
Bryan

(2nd) Syntax error with pf rules

[Adam Smith]

Hi guys,

I have another syntax error with one of my pf rules that I hope you will be 
able to fix.

Thanks.

Adam

-

The rule:

set debug urgent

comes with the following error message:

pfctl: unknown debug level "urgent"
/etc/pfcustom.conf 13: error setting debuglevel "urgent"
pfctl: Syntax error in config file: pf rules not loaded.
http://www.DCpages.com

Re: Syntax error in pf rules

[Adam Smith]

Thanks, Taru, your solution works.

Adam

--- letcher.r...@gmail.com wrote:

From: Letcher Ross <letcher.r...@gmail.com>
To: ken...@dcemail.com
Cc: OpenBSD Misc <misc@openbsd.org>
Subject: Re: Syntax error in pf rules
Date: Tue, 29 Mar 2016 08:55:32 -0700

Per http://www.openbsd.org/faq/pf/macros.html

It looks like your list should look like:

vpnip = "{ 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
66.85.14.205, 54.201.110.154 }"

Taru

On Tue, Mar 29, 2016 at 8:45 AM, Adam Smith <ken...@dcemail.com> wrote:

> Hi guys
>
> I have a syntax error in my pf rules. I hope you can help me fix it.
>
> Thanks.
>
> Adam
>
>
>
> -snippet of my pf rules-
>
> #This is where I change or add different IP addresses of VPN gateways
>
> vpnip="77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
> 66.85.14.205, 54.201.110.154"
>
>
>
> #Below is the rule that OpenBSD tells me there's a syntax error
>
> pass out quick on $wan proto tcp from any to $vpnip port 443 keep state
>
> -end of snippet-
> http://www.DCpages.com
http://www.DCpages.com

Re: (2nd) Syntax error with pf rules

[Otto Moerbeek]

On Tue, Mar 29, 2016 at 10:26:36AM -0700, Adam Smith wrote:

> Hi guys,
> 
> I have another syntax error with one of my pf rules that I hope you will be 
> able to fix.
> 
> Thanks.
> 
> Adam
> 
> -
> 
> The rule:
> 
> set debug urgent
> 
> comes with the following error message:
> 
> pfctl: unknown debug level "urgent"
> /etc/pfcustom.conf 13: error setting debuglevel "urgent"
> pfctl: Syntax error in config file: pf rules not loaded.
> http://www.DCpages.com

Ths is something you can find in the pf.conf man page very easily,
why bother us?

-Otto

Re: (2nd) Syntax error with pf rules

[Luis Coronado]

A much better approach is to do:

$ man pf.conf

This and the previous question will be easily answered by reading the
manual page.

-luis

On Tue, Mar 29, 2016 at 11:26 AM, Adam Smith <ken...@dcemail.com> wrote:

> Hi guys,
>
> I have another syntax error with one of my pf rules that I hope you will
> be able to fix.
>
> Thanks.
>
> Adam
>
> -
>
> The rule:
>
> set debug urgent
>
> comes with the following error message:
>
> pfctl: unknown debug level "urgent"
> /etc/pfcustom.conf 13: error setting debuglevel "urgent"
> pfctl: Syntax error in config file: pf rules not loaded.
> http://www.DCpages.com

Re: Syntax error in pf rules

[Letcher Ross]

Per http://www.openbsd.org/faq/pf/macros.html

It looks like your list should look like:

vpnip = "{ 77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
66.85.14.205, 54.201.110.154 }"

Taru

On Tue, Mar 29, 2016 at 8:45 AM, Adam Smith <ken...@dcemail.com> wrote:

> Hi guys
>
> I have a syntax error in my pf rules. I hope you can help me fix it.
>
> Thanks.
>
> Adam
>
>
>
> -snippet of my pf rules-
>
> #This is where I change or add different IP addresses of VPN gateways
>
> vpnip="77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78,
> 66.85.14.205, 54.201.110.154"
>
>
>
> #Below is the rule that OpenBSD tells me there's a syntax error
>
> pass out quick on $wan proto tcp from any to $vpnip port 443 keep state
>
> -end of snippet-
> http://www.DCpages.com

Syntax error in pf rules

[Adam Smith]

Hi guys

I have a syntax error in my pf rules. I hope you can help me fix it.

Thanks.

Adam



-snippet of my pf rules-

#This is where I change or add different IP addresses of VPN gateways

vpnip="77.90.247.88, 112.119.192.26, 85.95.253.145, 31.210.111.78, 
66.85.14.205, 54.201.110.154"



#Below is the rule that OpenBSD tells me there's a syntax error

pass out quick on $wan proto tcp from any to $vpnip port 443 keep state

-end of snippet-
http://www.DCpages.com

Re: Block IP with pf rules

[Peter N. M. Hansteen]

On 01/10/16 12:40, Gianluca D.Muscelli wrote:

Hi, I do not understand, I'm blocking some IP with these PF rules:


[ ... ]


  pass in quick on egress proto tcp \
   from  \
   to (egress) port smtp \
   rdr-to 127.0.0.1 port spamd

pass out quick on egress proto tcp to any port smtp

block return in quick from  to any


The traffic matches the first quick rule here, and the blacklist 
reference rule is never evaluated. Remove the 'quick's or move the 
blacklist check to somewhere earlier in your config.


--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: Block IP with pf rules

[Marko Cupać]

On Sun, 10 Jan 2016 13:36:44 +0100
"Peter N. M. Hansteen" <pe...@bsdly.net> wrote:

> On 01/10/16 12:40, Gianluca D.Muscelli wrote:
> > Hi, I do not understand, I'm blocking some IP with these PF rules:
>
> [ ... ]
>
> >   pass in quick on egress proto tcp \
> >from  \
> >to (egress) port smtp \
> >rdr-to 127.0.0.1 port spamd
> >
> > pass out quick on egress proto tcp to any port smtp
> >
> > block return in quick from  to any
>
> The traffic matches the first quick rule here, and the blacklist
> reference rule is never evaluated. Remove the 'quick's or move the
> blacklist check to somewhere earlier in your config.
>

I agree with Peter. I prefer to keep my 'block quick' rules at the top
of the ruleset. 'quick' means 'don't check after this rule'. You
already know you want to block from  without later
exceptions. Why waste resources on evaluating complete ruleset?

--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Block IP with pf rules

[Gianluca D.Muscelli]

Hi, I do not understand, I'm blocking some IP with these PF rules:


table  persist
table  persist
table  persist file "/var/db/blacklist”

block in log

block in quick from urpf-failed label uRPF

pass out all modulate state

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

pass in quick on egress proto tcp \
  from   \
  to (egress) port smtp \
  flags S/SA modulate state

 pass in quick on egress proto tcp \
  from  \
  to (egress) port smtp \
  rdr-to 127.0.0.1 port spamd

pass out quick on egress proto tcp to any port smtp

block return in quick from  to any


I add IP with pfctl -t blacklist -T add 119.81.219.7 or or by editing the
file, after I reload the table with:  pfctl -t blacklist -T replace -f
/var/db/blacklist
But these IP continue to connect again...

Jan 10 11:57:48 server spamd[7762]: (BLACK) 119.81.219.7:
<db2in...@eia.ibm.com> -> <i...@gianlucamuscelli.it>
Jan 10 11:59:33 server spamd[7762]: 119.81.219.7: To:
i...@gianlucamuscelli.it
Jan 10 11:59:33 server spamd[7762]: 119.81.219.7: Subject: Your PayPal account
has been limited
Jan 10 11:59:33 server spamd[7762]: 119.81.219.7: From: "PayPal"
<confirmag...@ppservice.com>
Jan 10 12:00:49 server spamd[7762]: 119.81.219.7: disconnected after 390
seconds. lists: uatraps blacklist

I don't understand, this address should no longer be able to connect to the
system?

Gianluca

[demime 1.01d removed an attachment of type application/pgp-signature]

Error loading pf rules: Device busy

[C. L. Martinez]

Hi all,


I have a strange problem. Every time that I try to reload my pf rules I see
the following error message:


pfctl: DIOCADDRULE: Device busy.


I am using OpenBSD 5.8 amd64 fully patched.


Any idea??

Re: Error loading pf rules: Device busy

[C.L. Martinez]

On 01/02/2016 08:33 AM, C. L. Martinez wrote:

Hi all,


I have a strange problem. Every time that I try to reload my pf rules I
seethe following error message:


pfctl: DIOCADDRULE: Device busy.


I am using OpenBSD 5.8 amd64 fully patched.


Any idea??



Sorry for the noise. There was an error in a customized anchor's rules.

Thanks.

pf rules for a (transparent) filtering bridge doing dns resolving/caching (unbound)

[Erling Westenvik]

Yo,

I'm somewhat used to set up OpenBSD gateways serving dhcp and doing dns
resolving/caching for local networks. However, when attempting to set up
a transparent filtering bridge between my ISP and my LAN, I run into
problems with unbound and pf.

The clients behind the bridge will get their dhcp leases from my ISP. Is
it possible at all to have this "filtering bridge" of mine "catching"
all the clients dns requests and let unbound deal with them?

Sorry for not being very specific. I've really tried to do my homework
here but have to admin that I'm lost so far. Could someone at least
point me to where to start?

Thanks in advance.

Erling

Re: PF rules block some websites (?)

[Piotr Kubaj]

On 11/01/15 11:51, Marco Prause wrote:
> Hi Piotr,
>
> just a guess, but you might hit some path mtu discovery issue.
> On customer paths with e.g. mtu less than 1500 it should help to
> discover the minimal mtu and while blocking the don't fragment bit,
> which is used for pmtud, pmtud won't work.
>
> In your case the redirect answer would fit in the maybe decreased mtu,
> but the "website" won't.
>
> Hope my guess was right. But it sounds like an often seen issue - often
> in conjunction with vpns.
>
>
> Regards,
> Marco
>
> Am 31. Oktober 2015 22:50:31 MEZ, schrieb Piotr Kubaj :
>
> Hi,
>
> I'm using OpenBSD 5.8 on a Ubiquiti Edgerouter Lite. It works great,
> apart from my customers reported that some websites don't work for them
> (I've verified that it's true).
>
> My /etc/pf.conf is:
> int_if="{ vether0 cnmac1 cnmac2 }"
> broken="224.0.0.22  127.0.0.0/8 
192.168.0.0/16  172.16.0.0/12  \
> 10.0.0.0/8  169.254.0.0/16
 192.0.2.0/24  \
> 198.51.100.0/24 , 203.0.113.0/24
, \
> 169.254.0.0/16  0.0.0.0/8 240.0.0.0/4
 255.255.255.255/32 "
> set block-policy drop
> set loginterface
> egress
> set skip on lo0
> match in all scrub (no-df random-id max-mss 1440)
> match out on egress inet from !(egress:network) to any nat-to
(egress:0)
> antispoof quick for (egress)
> block in quick on egress from { $broken no-route urpf-failed } to any
> block in quick inet6 all
> block return out quick inet6 all
> block return out quick log on egress proto { tcp udp } from any to any
> port 53
> block return out quick log on egress from any to { no-route $broken }
> block in all
> pass out quick inet keep state
> pass in on $int_if inet keep state
> pass on $int_if from any to { 224.0.0.2 , 239.0.0.0/8
 }
> pass in on $int_if inet proto { tcp udp } from any to ! 192.168.1.1
 port
> 53 rdr-to 192.168.1.1 
> pass in quick on $int_if proto udp from any to ! 192.168.1.1
 port
> 123
> rdr-to 192.168.1.1 
> pass in on egress inet proto tcp to (egress) port 2501 rdr-to
> 192.168.1.2  port 22
> pass in on egress inet proto tcp from any to (egress) port 2500
> pass in on egress inet proto tcp from any to (egress) port 9001
> pass in on egress inet proto tcp from any to (egress) port 9030
>
>
>
>
>
>
> The sites in question are nk.pl  (loads once in a while),
cyberbaba.pl 
> and phoronix.com . They all send 301 redirection
and that's it.
> Any ideas what might cause it?
>
> [demime 1.01d removed an attachment of type application/pgp-signature
which had a name of signature.asc]
>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
Thanks, but I guess it's not caused by blocking DF fragment. I've
cleared the whole /etc/pf.conf and left only. Since you've mentioned
MTU, I've read a bit about it and PPPoE (I need it for WAN) and found
that I need to add:
match on pppoe0 scrub (max-mss 1440)
to /etc/pf.conf. Thanks!

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

PF rules block some websites (?)

[Piotr Kubaj]

Hi,

I'm using OpenBSD 5.8 on a Ubiquiti Edgerouter Lite. It works great,
apart from my customers reported that some websites don't work for them
(I've verified that it's true).

My /etc/pf.conf is:
int_if="{ vether0 cnmac1 cnmac2 }"
broken="224.0.0.22 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 \
10.0.0.0/8 169.254.0.0/16 192.0.2.0/24 \
198.51.100.0/24, 203.0.113.0/24, \
169.254.0.0/16 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32"
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
antispoof quick for (egress)
block in quick on egress from { $broken no-route urpf-failed } to any
block in quick inet6 all
block return out quick inet6 all
block return out quick log on egress proto { tcp udp } from any to any
port 53
block return out quick log on egress from any to { no-route $broken }
block in all
pass out quick inet keep state
pass in on $int_if inet keep state
pass on $int_if from any to { 224.0.0.2, 239.0.0.0/8 }
pass in on $int_if inet proto { tcp udp } from any to ! 192.168.1.1 port
53 rdr-to 192.168.1.1
pass in quick on $int_if proto udp from any to ! 192.168.1.1 port 123
rdr-to 192.168.1.1
pass in on egress inet proto tcp to (egress) port 2501 rdr-to
192.168.1.2 port 22
pass in on egress inet proto tcp from any to (egress) port 2500
pass in on egress inet proto tcp from any to (egress) port 9001
pass in on egress inet proto tcp from any to (egress) port 9030






The sites in question are nk.pl (loads once in a while), cyberbaba.pl
and phoronix.com. They all send 301 redirection and that's it.
Any ideas what might cause it?

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Multiple VLANs PF rules

[Dot Yet]

Hello,

I am replacing a Cisco ASA at my home with an openbsd server. I've pf with
nat and some basic rules in place. my internal machines are able to reach
out to the internet with no problems. I've a separate lab network of
servers which are segregated into multiple VLANs. I've been able to create
the  various vlans on the openbsd server, but I am not sure how inter-VLAN
routing is suppose to work. The interface layout looks like this:

em0 - outbound to ISP
em1 - my home network
em2 - member of trunk0
em3 - member of trunk0
trunk0 - lacp trunk for my lab network
trunk0.vlan12 - vlan 12
trunk0.vlan15 - vlan 15

So, can one of you help me understand how I can write the pf rules to allow
communication between em1 and vlan 12/15 or communication between vlan 12
and vlan 15 etc.

Please let me know.

Thanks,
dot

Re: Multiple VLANs PF rules

[Dain Bentley]

I have multiple blans and a trunk port.  I have hostname.vlan100
hostname.200 in /etc.  then my pf.conf file uses packet tagging to separate
the vlan traffic

On Wednesday, August 19, 2015, Dot Yet dot@gmail.com wrote:

 Hello,

 I am replacing a Cisco ASA at my home with an openbsd server. I've pf with
 nat and some basic rules in place. my internal machines are able to reach
 out to the internet with no problems. I've a separate lab network of
 servers which are segregated into multiple VLANs. I've been able to create
 the  various vlans on the openbsd server, but I am not sure how inter-VLAN
 routing is suppose to work. The interface layout looks like this:

 em0 - outbound to ISP
 em1 - my home network
 em2 - member of trunk0
 em3 - member of trunk0
 trunk0 - lacp trunk for my lab network
 trunk0.vlan12 - vlan 12
 trunk0.vlan15 - vlan 15

 So, can one of you help me understand how I can write the pf rules to allow
 communication between em1 and vlan 12/15 or communication between vlan 12
 and vlan 15 etc.

 Please let me know.

 Thanks,
 dot

Re: Multiple VLANs PF rules

[Giancarlo Razzolini]

Em 19-08-2015 16:50, Dot Yet escreveu:
 So, can one of you help me understand how I can write the pf rules to allow
 communication between em1 and vlan 12/15 or communication between vlan 12
 and vlan 15 etc.

If all machines have OpenBSD as their gateway, simple pass rules should
do. No need for nat nor anything. Now, if some of these networks do not
have the OpenBSD machine as its gateway, but the OpenBSD machine has
access to the network, then you will need nat. You can have other things
such as routes being passed using DHCP, RIP (or other internal routing
protocol), etc. Assuming the OpenBSD machine can communicate with every
network and every machine on it, you have plenty of options.

Cheers,
Giancarlo Razzolini

Re: Multiple VLANs PF rules

[Giancarlo Razzolini]

Em 19-08-2015 18:25, Dot Yet escreveu:
 The machines are all pointing to the openbsd server as their default
 gateway.

Nice.

 the nat is only being used to get out to the internet (em0). internal
 subnets do not use nat to communicate.

So you have the setup I outlined.

 I don't want to use any routing protocol for this, but just simple
 firewall rules to allow or deny the traffic.

You won't need to. The pf man pages are great, and they provide lots of
examples. Also, if you take some time to learn BNF, it will surely help you.

Cheers,
Giancarlo Razzolini

Re: Multiple VLANs PF rules

[Dot Yet]

OK, great, that's helpful. The machines are all pointing to the openbsd
server as their default gateway. the nat is only being used to get out to
the internet (em0). internal subnets do not use nat to communicate. I don't
want to use any routing protocol for this, but just simple firewall rules
to allow or deny the traffic.

I'll read through some more docs to gain more information.

Thanks Giancarlo!




On Wed, Aug 19, 2015 at 5:14 PM, Giancarlo Razzolini grazzol...@gmail.com
wrote:

 Em 19-08-2015 16:50, Dot Yet escreveu:
  So, can one of you help me understand how I can write the pf rules to
 allow
  communication between em1 and vlan 12/15 or communication between vlan 12
  and vlan 15 etc.

 If all machines have OpenBSD as their gateway, simple pass rules should
 do. No need for nat nor anything. Now, if some of these networks do not
 have the OpenBSD machine as its gateway, but the OpenBSD machine has
 access to the network, then you will need nat. You can have other things
 such as routes being passed using DHCP, RIP (or other internal routing
 protocol), etc. Assuming the OpenBSD machine can communicate with every
 network and every machine on it, you have plenty of options.

 Cheers,
 Giancarlo Razzolini

Re: spamd pf rules

[Stuart Henderson]

On 2015-06-11, Jason Tubnor ja...@tubnor.net wrote:
 As Okan stated, your 5.6 man page is still correct for 5.7.  It is
 only of issue when you move to 5.8-Release in November.

correct.

 On 11 June 2015 at 11:51, Edgar Pettijohn III ed...@pettijohn-web.com wrote:
 On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote:

 On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf 
 and noticed that I had the following rules in regards to spamd.

 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp

 Everything seems to work correctly, but I was thinking the rdr-to rule was 
 wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When 
 I change it to divert-to I get the following error:

 # pfctl -vf /etc/pf.conf

 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded

 What should I do to fix this.  Is the rdr-to rule sufficient or do I need 
 to change it?

 Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.

Note that the address family mismatch error is because 5.7's pfctl parser
was stricter about address families than -current.

Previously it was a syntax error to specify redirecting to an IPv4
address if the other addresses on the line could match a v6 address;
it was changed post-5.7 to allow the syntax (adding an implicit 'inet').

Re: spamd pf rules

[Edgar Pettijohn III]

On Jun 11, 2015, at 6:42 AM, Stuart Henderson wrote:

 On 2015-06-11, Jason Tubnor ja...@tubnor.net wrote:
 As Okan stated, your 5.6 man page is still correct for 5.7.  It is
 only of issue when you move to 5.8-Release in November.
 
 correct.
 
 On 11 June 2015 at 11:51, Edgar Pettijohn III ed...@pettijohn-web.com 
 wrote:
 On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote:
 
 On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf 
 and noticed that I had the following rules in regards to spamd.
 
 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp
 
 Everything seems to work correctly, but I was thinking the rdr-to rule 
 was wrong so I looked at spamd(8) and it shows a divert-to rule instead.  
 When I change it to divert-to I get the following error:
 
 # pfctl -vf /etc/pf.conf
 
 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded
 
 What should I do to fix this.  Is the rdr-to rule sufficient or do I need 
 to change it?
 
 Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.
 
 Note that the address family mismatch error is because 5.7's pfctl parser
 was stricter about address families than -current.
 
 Previously it was a syntax error to specify redirecting to an IPv4
 address if the other addresses on the line could match a v6 address;
 it was changed post-5.7 to allow the syntax (adding an implicit 'inet').


Thanks for all the replies.  That was the conclusion I came up with.  However 
my system was out of whack a little, so at least this non-issue brought that to 
my attention.

Re: spamd pf rules

[Jason Tubnor]

As Okan stated, your 5.6 man page is still correct for 5.7.  It is
only of issue when you move to 5.8-Release in November.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf
- -current and 5.8, use/will use divert-to

(Can't give you a link to the online pf.conf man page for 5.7 as it
hasn't been snapped for 5.7-release) My man pages on my 5.7 hosts
specify rdr-to

Cheers,

Jason.


On 11 June 2015 at 11:51, Edgar Pettijohn III ed...@pettijohn-web.com wrote:
 On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote:

 On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf 
 and noticed that I had the following rules in regards to spamd.

 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp

 Everything seems to work correctly, but I was thinking the rdr-to rule was 
 wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When 
 I change it to divert-to I get the following error:

 # pfctl -vf /etc/pf.conf

 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded

 What should I do to fix this.  Is the rdr-to rule sufficient or do I need 
 to change it?

 Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.

 http://www.openbsd.org/faq/current.html#20150518

 Thanks

 I guess I missed that line.  However, I think my system is out of whack.  I 
 upgraded to 5.7, but the spamd man page is from 5.6.  Thanks for the lead.

 Edgar





-- 
If my calculations are correct, when this baby hits 88MPH, you're
gonna to see some serious shit - Emmett Doc Brown

spamd pf rules

[Edgar Pettijohn III]

I've been using spamd for a while now.  I was looking through my pf.conf and 
noticed that I had the following rules in regards to spamd.

table spamd-white persist
table nospamd persist file /etc/mail/nospamd
pass in log on egress proto tcp from any to any port smtp \
rdr-to 127.0.0.1 port spamd
pass in on egress proto tcp from nospamd to any port smtp
pass in on egress proto tcp from spamd-white to any port smtp
pass out log on egress proto tcp to any port smtp

Everything seems to work correctly, but I was thinking the rdr-to rule was 
wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When I 
change it to divert-to I get the following error:

# pfctl -vf /etc/pf.conf

/etc/pf.conf:19: address family mismatch for divert
pfctl: Syntax error in config file: pf rules not loaded

What should I do to fix this.  Is the rdr-to rule sufficient or do I need to 
change it?

Thanks,

Edgar

Re: spamd pf rules

[Okan Demirmen]

On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf and 
 noticed that I had the following rules in regards to spamd.
 
 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp
 
 Everything seems to work correctly, but I was thinking the rdr-to rule was 
 wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When I 
 change it to divert-to I get the following error:
 
 # pfctl -vf /etc/pf.conf
 
 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded
 
 What should I do to fix this.  Is the rdr-to rule sufficient or do I need to 
 change it?

Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.

http://www.openbsd.org/faq/current.html#20150518

Thanks

Re: spamd pf rules

[Edgar Pettijohn III]

On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote:

 On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf and 
 noticed that I had the following rules in regards to spamd.
 
 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp
 
 Everything seems to work correctly, but I was thinking the rdr-to rule was 
 wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When I 
 change it to divert-to I get the following error:
 
 # pfctl -vf /etc/pf.conf
 
 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded
 
 What should I do to fix this.  Is the rdr-to rule sufficient or do I need to 
 change it?
 
 Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.
 
 http://www.openbsd.org/faq/current.html#20150518
 
 Thanks

I guess I missed that line.  However, I think my system is out of whack.  I 
upgraded to 5.7, but the spamd man page is from 5.6.  Thanks for the lead.

Edgar

Re: Duplicate pf rules when using groupname

[Stuart Henderson]

Actually this is a bit odd, can't reproduce it here on 5.5 or -current.