Re: nat-to random : A couple of questions

[Bohdan Tashchuk]

> 1) Looking at tcpdumps, I've noticed (on 6.5 have no prior experience
> with nat-to random to compare against) that 'random' seems to operate
> more like 'round-robin'

I can't speak to the rest of your questions. But I can share something
about a very similar issue. A few releases ago I ran into a this same
bug, not with nat-to, but with rdr-to. I haven't confirmed this
behavior in the most recent release.

I am keeping locally generated ntp traffic from going out to Apple's
internet ntp servers, instead serving them locally from my OpenBSD
firewall. I use a pf configuration something like this:

   pass in quick on $iif proto udp from any
to "17.0.0.0/8" port ntp rdr-to "127.17.42.0/28" random

My local ntpd listens on those 16 ports. Here are some comments
from my pf.conf which summarize why, at least for me, round robin
behavior is better than random:

# Note that rdr-to with CIDR target address only works with random
# keyword, and behaves like round-robin. With all other keywords the
# target address is borked, behaving like 0.0.0.0, 0.0.0.1, 0.0.0.2,
# etc.
# However, rdr-to with a 16-entry table target, 16 distinct addresses,
# works correctly in all modes, random is truly random. N.B. we
# definitely don't want truly random, because it sometimes results
# in duplicate target addresses, which causes lost reply packets.


A restatement of the above pf file comment:

1) for rdr-to, for CIDR target addresses, only "random" works.
All other modes are borked. "random" behaves like "round-robin".

2) for rdr-to, when the target address is a table, all modes work.
"random" is truly random.

3) for some setups, truly random target addresses will cause
creation of duplicate target addresses. That's bad, because some
replies will be lost.


In conclusion:

Are you sure you really need random behavior for your application?
Depending on what you are doing, round-robin may actually be better!
You didn't post your pf configuration so I don't know what you're
trying to do.

I hope you can gleam something from my rdr-to issue to help you
with your nat-to issue.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Bohdan Tashchuk]

On Fri, 6/17/16, Marko Cupać  wrote:
     
> Perhaps it would be useful to add that 'set prio' does nothing
> unless "hardware is slower at transmitting packets than the
> thing that generates these packets to send", as stated here:
>
>  [http://marc.info/?l=openbsd-misc=145257356119612=2]
>
> ... thus making it inappropriate for solution of OP's problem.

Hi,

I'm the OP. I agree that a single VoIP session doesn't need
'set prio' in normal circumstances.

The reason I want to implement it in my home network is
because, occasionally, one of the kids will upload
something big, e.g. a few hundred megabytes of pictures,
to some social network.

When that happens, my Internet "goes to shit" for the
duration. The upload attempts to push 100 Mbit/sec
or more to my firewall. Which then tries to push
to the Internet over the 5 Mbit/sec uplink speed of my
cable modem. Which immediately saturates. Which results
in the usual problems, such as 2000 msec or longer ping
times. Etc. Of course, TCP eventually backs off, but things
remain quite unpleasant for the duration of the upload.

I don't want VoIP to suffer under those circumstances. So
if I can work around this with 'set prio' (and not need to
get queues involved), then it's certainly worth trying to do it.

I will, of course, do some tcpdump monitoring in the near
future, and report back to the list as to how successful I
was in solving my problem by simply using 'set prio'.

is 'set prio' in pf unidirectional or bidirectional?

[Bohdan Tashchuk]

Hi,

I'm trying to update my pf.conf to prioritize Ooma VoIP packets. My OpenBSD 
firewall sits between my Ooma on my internal network and the outside world.

It's hard to Google for this info, since the pf FAQ has so many mirrors out 
there, it's hard to separate the noise from the signal. I own The Book of PF, 
but it doesn't cover this specific issue.

First I need a pf rule from my firewall to the outside world:

 pass out quick on $ext_if proto udp from $ooma to any set prio 5 nat to 
($ext_if)

That rule is fine, it will prioritize Ooma outgoing packets from my firewall 
ahead of my other outgoing packets to the Internet.

My problem is with my other pf rule(s), which is how my Ooma packets get from 
my internal network to my firewall. I can make a rule like this:

 pass in quick on $int_if proto udp from $ooma to any set prio 5

This rule allows packets into the firewall, but the 'set prio' in the rule 
doesn't do anything (at least not immediately) since 'set prio' is intended for 
outgoing packets. However, this rule does create state. Once state is created, 
there is no further way to influence the priority of a returning packet, since 
it will no longer be subject to additional rules in pf.conf.

I.e. I can add an additional rule like this:

   pass out quick on $int_if proto udp from any to $ooma set prio 5

but, since state has already been created, that rule will never apply.

I can think of three ways to 'set prio 5' on packets from my firewall to my 
internal network:

1) Is the 'set prio 5' on incoming packets sticky to outgoing packets? I.e. is 
it unidirectional or is it bidirectional? If I have a rule like this for the 
internal interface:

 pass in quick on $int_if proto udp from $ooma to any set prio 5

will the 'set prio' be part of the state created by the incoming packet? Does 
pf work that way? If so, would the return outgoing packets automatically have 
the higher priority?

or 2) I can write rules with no state for the internal interface. Something 
like this:

 pass in quick on $int_if proto udp from $ooma to any no state
 pass out quick on $int_if proto udp from any to $ooma set prio 5 no state

But using 'no state' seems so inefficient. The pf rules need to be evaluated 
for every packet.

or 3) I can write rules like this for the internal interface:

 pass in quick on $int_if proto udp from $ooma to any no state
 pass out quick on $int_if proto udp from any to $ooma set prio 5 keep state

What I think happens here is that the very first packet from Ooma to the 
firewall is 'no state'. But shortly thereafter there will be a return packet 
from the outside world to Ooma, and that return packet will create state. From 
that point on, all further Ooma packets on the internal interface will have 
state. Am I correct in that conclusion?

Is this all too confusing? Have I been able to explain myself clearly enough?

Thanks in advance for any help.

Re: bug / misunderstanding in how pf interacts with dhclient

[Bohdan Tashchuk]

--- On Mon, 1/28/13, Andres Perera andre...@zoho.com wrote:

 more than that, really, why should you or anybody care

 using bpf or not should be an implementation detail. no one should 
 be making decisions as far as their pf config goes based upon 
 whether dhclient uses bpf or not

Thanks for your comments on the source code. I briefly looked thru
/usr/src/sbin/dhclient, but there were 6289 lines of *.c code there.
I'm not that familiar with networking code so there was too much 
for me to easily comprehend.

I agree that bpf is simply an implementation technique; I don't really care 
*how* dhclient does what it does. But I want to understand the required pf
rules for two reasons:

1) there have been people who have said (e.g. in the thread I quoted):

   Using DHCP is not possible, pf block it, and i don't understand why

Missing pf rules are one reason why dhcp would fail. Many people search
for similar problems years later; I don't want them to be confused as I was.

2) This is the important one for me. I want to be a good Internet citizen. 
So I try to write my pf rules to be as restrictive as possible. I want to 
keep machines behind my firewall from being bad Internet citizens. 
Right now my outgoing UDP below port 1024 is restricted to ports domain, 
kerberos, and ntp. I will add dhcp to that list.

I know I'm being a little quixotic (or perhaps pedantic) here. If there's 
a misbehaving machine behind my firewall, I don't think that restricting 
its UDP ports is going to make a whole lot of difference to the Internet 
at large. But I'm trying to do what I can. 

bug / misunderstanding in how pf interacts with dhclient

[Bohdan Tashchuk]

Hi guys,

For many years, I've read pf and dhcp related threads like, e.g.:
http://marc.info/?l=openbsd-miscm=125907434809727w=2

Some text from that post:
dhcp packets are grabbed by dhclient or dhcpd before pf sees them.

My understanding, based on comments in a number of threads like that,
is that NO MATTER WHAT IS IN PF RULES, that dhcpd and dhclient should
both work fine. This is because dhcpd and dhclient both use bpf to
completely bypass pf.

However, I'm running OpenBSD 5.2 release, and I don't think dhclient
is able to renew its lease without pf cooperation. I recently tightened
up my pf rules, which is how I ran into this.

Here's what I see, based on tcpdump and daemon logs:

1) on startup, my dhclient negotiates with my ISP's dhcp server properly.
It makes a request, it gets a lease, as logged in /var/log/daemon:
Jan 27 02:55:00 (myname) dhclient[24372]: DHCPREQUEST on em1 to 
255.255.255.255 port 67
Jan 27 02:55:00 (myname) dhclient[24372]: DHCPACK from 73.88.146.1 
(00:1d:70:af:ec:e2)
Jan 27 02:55:00 (myname) dhclient[24372]: bound to 76.27.218.121 -- 
renewal in 116353 seconds.

2) this lease is properly recorded in my dhclient.leases.em1 file:
lease {
  interface em1;
  fixed-address 76.27.218.121; 
  option subnet-mask 255.255.252.0;
  option routers 76.27.216.1;
  ...
  option broadcast-address 255.255.255.255; 
  option dhcp-lease-time 232706;
  option dhcp-message-type 5;
  option dhcp-server-identifier 76.96.95.6;
  renew 1 2013/1/28 19:14:13;
  ...
}

3) but when it comes time to renew, my pf rules block outgoing UDP to port 67,
so the following is in pflog:
Jan 28 11:14:13.977566 rule 73/(match) block out on em1: 
76.27.218.121.68  76.96.95.6.67: xid:0x2530b3a4 C:76.27.218.121
ether 00:07:e9:1a:37:6b [|bootp] [tos 0x10]

4) I see a corresponding message in /var/log/daemon:
Jan 28 11:14:13 (myname) dhclient[27723]: DHCPREQUEST on em1 to 
76.96.95.6 port 67
Jan 28 11:14:13 (myname) dhclient[27723]: send_packet: No route to host

5) My dhclient.leases.em1 file is not updated. My dhclient is unable to renew
its lease. As time goes on, dhclient makes more and more DHCPREQUESTs at
shorter and shorter intervals.

6) So, is this a bug in the dhclient implementation, or am I misunderstanding
something? Either way, it's not a big deal, I can just allow DHCP packets in
the firewall like I was doing until just recently.

Thanks,
Bohdan

Re: Differences between www.openbsd.org and openbsd.org

[Bohdan Tashchuk]

 The server openbsd.org is actually cvs.openbsd.org,
 that is the main machine in Theo's basement.
 Nobody should ever use that one for anything.

For many many years I've been typing

   example.com

without leading www. Back in the 1990s nytimes.com didn't work, and 
www.nytimes.com did. But since then it's very rare for a major site to expect 
people to type the leading www.

I've been tracking/using OpenBSD since around version 2.4 and I wasn't aware of 
the non-www distinction until the issue came up recently on misc.

I suggest that there are many clueless people like me out there. The default 
behavior should be changed. opendbsd.org should redirect to www.openbsd.org, 
and the people who need to access the machine in Theo's basement should go to 
cvs.openbsd.org.

: File Server: fsck, memory requirements and large disk drives

[Bohdan Tashchuk]

 Not true. fsck will only do a parallel check
 the partitions are on a separate device. 

That makes sense. You would have a lot of disk thrashing if you tried to check 
two partitions in parallel on the same drive.

Re: File Server: fsck, memory requirements and large disk drives

[Bohdan Tashchuk]

 The 1.5 TB hard drive is partitioned in three equal partition
 so I have a chance to pass the fsck if ever needed.

You may still have difficulty passing fsck.

By default OpenBSD will attempt to fsck all three partitions in parallel. See 
this thread from last month where I mentioned a change to /etc/rc which will 
help.

http://kerneltrap.org/mailarchive/openbsd-misc/2010/1/5/6318963

Re: another hint for fsck for large filesystems

[Bohdan Tashchuk]

--- On Wed, 1/6/10, Alexander Hall alexan...@beard.se wrote:
 You should be able to get the same result
 using proper values for fs_passno in /etc/fstab.

One would hope so, but I don't think that's the case.

First, the man page says 

   the root filesystem should be specified with
   a fs_passno of 1, and other filesystems
   should have a fs_passno of 2.  Filesystems
   within a drive will be checked sequentially,
   but filesystems on different drives will be
   checked at the same time to utilize
   parallelism available in the hardware.

Second, in fsck/preen.c I see a construct like this

  for (passno = 1; passno = 2; passno++) {
  ...
  ... if (passno == 2  fs-fs_passno  1) {

For some reason, many years ago, fsck was optimized to run in parallel for 
efficiency. It's unfortunate that the fstab file can't be used to provide 
better control over the parallelism.

another hint for fsck for large filesystems

[Bohdan Tashchuk]

Sorry I'm not subscribed to the misc@ list, I read on a web archive. So I can't 
reply directly to the recent discussion about how to do newfs / fsck etc on 
large file systems (memory issue).

I have one box with relatively limited memory and had to make a change directly 
to /etc/rc (yes, horrors)!.

The change is

fsck -p -l 1

This keeps fsck from checking more than one disk in parallel.

explanation of pf state-policy floating vs if-bound?

[Bohdan Tashchuk]

I'm running OpenBSD 4.1 release.

Does anyone have a definitive explanation of the difference between pf 
state being floating vs if-bound, and when one or the other should / 
must be used?


The rest of this email is just explaining why I'm asking the question.

I've seen Henning Brauer say use floating unless you absolutely need to 
use if-bound.


http://archive.openbsd.nu/?ml=openbsd-pfa=2005-08t=1255924

Claudio Jaker's paper on multipath routing specifically shows if-bound 
as part of the mimimum rule set.


http://cvs.openbsd.org/papers/opencon06-network/mgp9.html

Also, recently I had a question about multihoming. People pointed out 
the pf reply-to feature and the route command -mpath feature and I was 
able to make multihoming work for me using those techniques. Thanks for 
your help.


But then I realized I don't want to be multihomed in the sense that my 
cable modem interface is so much faster than my DSL inteface that I want 
to ignore DSL except for limited circumstances.


All I wanted to do was to allow limited inbound access to my DSL 
interface. In my case, just SSH. Also by DSL ISP blocks inbound SSH so I 
needed to move the port.


So I didn't need to say: route xxx -mpath

I also didn't need to set: net.inet.ip.multipath=1

I wound up with these rules, which seem to work:



set state-policy if-bound

pass in quick on $cable_interface \
reply-to ( $cable_interface $cable_gateway ) \
proto tcp from any to any port { $cable_sshd } \
keep state ( floating )

pass in quick on $dsl_interface \
reply-to ( $dsl_interface $dsl_gateway ) \
proto tcp from any to any port { $dsl_sshd } \
keep state ( floating )



But here's the trick: If my entire pf.conf rule set is if-bound then it 
fails. Packets inbound on DSL are routed outbound on CABLE (which is my 
one-and-only default route). It's only when I added keep state 
(floating) to the above two rules that things started working the way I 
expected them to, e.g. inbound on DSL caused replies to be sent back out 
to DSL.


So state-policy is a magic, magic thing with non-obvious (to me at 
least) side effects. It's counter-intuitive to me that a floating 
policy allows packets to go back out the interface they arrived at.


I'm hoping someone will reply with a more detailed explanation of what's 
going on here.

trying to be multi-homed, impossible without routing daemon?

[Bohdan Tashchuk]

I'm running OpenBSD 4.1 release.

I've had a DSL connection, just added a cable modem. DSL has static IP, 
cable modem IP assigned by DHCP (which becomes default route).


Now, when I receive ICMP echo request on DSL the ICMP echo reply goes 
back via cable modem (and has cable modem source address, not DSL source 
address). Of course incoming services such as SSH on DSL interface have 
same problem, outgoing reply packets go to cable modem instead.


I can't convince OpenBSD to return an echo reply via the interface the 
request arrived at. Is this just not possible? I've Googled for so many 
variations of multihomed, same interface, reply packets, but can't 
find anything definitive.


Is there any way for the machine to learn what interface a packet 
arrived at and send replies there? I can't run anything like BGP or even 
RIP since my ISPs don't speak those with me. Is there a program that can 
watch incoming packets and update routing table accordingly so outgoing 
packet go out the right interface?


Things work great for incoming requests if I delete the default route, 
but that makes outgoing requests pretty worthless since most packets 
have nowhere to go.


Is this just how routing works? Is OpenBSD more restricted than other 
OSes for this issue? Can anyone recommend a good book? I've read TCP 
Illustrated vol 1 but Stevens doesn't disuss this much, he says it would 
take a book to cover.


Having multiple interfaces to the Internet just seems useless for a 
typical small network. It seems like this should be an FAQ but maybe 
people are just smarter than I am and either figure out the answer or 
decide it is impossible.


Thanks for any help or advice.

Re: trying to be multi-homed, impossible without routing daemon?

[Bohdan Tashchuk]

Die Gestalt wrote:


Do you have pf enabled and if yes can you share with us your pf.conf?

It sounds like you nat everything including one of your incoming
connection. When the request arrives on one interface it gets natted
to the other.


My pf.conf is quite cluttered. So thanks for the first hint. I should 
debug with the *minimum* pf.conf that shows the problem.


I didn't expect NAT to enter into anything at all because I was only 
going to the firewall itself, not to an internal network. But I've 
reproduced my NAT rules below and *YES* NAT was screwing things up.


The way that happened is I modified my NAT when I went from 1 external 
interface to 2 external interfaces. But I didn't modify it correctly, so 
NAT was occurring.


I'll keep working on a simpler pf.conf. But as of right now my outgoing 
packets are still being sent out the default interface rather than the 
one they came in on.



iif = em0   # inside  interface
cif = em1   # cable modem interface (default route)
dif = xl0   # dsl interface

set block-policy drop
set state-policy if-bound
set loginterface $cif
set optimization normal
set require-order yes
set skip on lo

scrub in all fragment reassemble

 BELOW TWO RULES WERE BAD X
 THEY ARE NOT SUFFICIENT WHEN USING 2 EXTERNAL INTERFACES XX

nat on $cif from !($cif) - ($cif:0)
nat on $dif from !($dif) - ($dif:0)

XX I NEED TO CHANGE TO SOMETHING LIKE THIS X

nat on $cif from ($iif:network) - ($cif:0)
nat on $dif from ($iif:network) - ($dif:0)

Re: OpenBSD 4.1: pf is not blocking anything

[Bohdan Tashchuk]

Marcos Laufer wrote:


Hello,

I am testing pf in an OpenBSD 4.1. This same configuration works fine on
OpenBSD 3.9, but in 4.1 it is not filtering anything, everything is passing
thru,
just like as if there was no 'block all'. What worries me most is that
anyone
on the outside can see my ssh service .
Is there anything wrong with the state of my rules? If i didn't
misunderstand ,
this rules should work just fine

Any ideas?
Thanks in advance,

Marcos




# good guys
table goodhosts persist
pass in quick on egress from goodhosts to any keep state


I'm no pf expert, so here's a simple question. What, if anything, is in 
table goodhosts? Maybe you're allowing everything in because of that 
table, or maybe you're testing from an IP defined as OK in that table?