On 17 February 2018 at 23:07, Richard Procter <richard.n.proc...@gmail.com>
wrote:
>
>
> On 18/02/2018, at 8:39 AM, Richard Procter wrote:
>
> > Hi,
> >
> > I've never attempted such a setup so the following are general pointers
> > which may be mistaken.
> >
> > On 18/02/2018, at 3:08 AM, miraculli . wrote:
> > [...]
> > I would attempt a simpler config first. I suspect you're following
> > the advice in https://www.openbsd.org/faq/pf/pools.html - which is
> >
> > pass in on $int_if from $lan_net \
> > route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } \
> > round-robin
> >
> > Only once this is working attempt to use the egress group as a
short-hand.
> >
> >> # START: here I want to block wifi-guests to have access to office-lan
but
> >> doesn´t seem to work too.
> >> block return out from vlan64:network to vlan32:network
> >> #END
> >
> > I would block this on the input side -- IIRC by the time the packet
> > has reached the output side it has already had its source address
> > rewritten by NAT. e.g.
> >
> > block in on $wifi_if to $office_if:network
> > block in on $office_if to $wifi_if:network # probably also want this
converse
>
> actually a simpler way to achieve this would be to preface the rules with
>
> block
>
> and then explicitly allow the traffic you want to pass, e.g.
>
> pass out inet
> pass in on ${int_if}
>
> (these rules apply only to new flows; e.g. if you make an outbound
> TCP connection, and the rules allow it, pf will then create a state that
> allows traffic in the reverse direction through; there's no need to
> specify this explicitly in the rules, and in fact the rules won't be
> consulted if a matching state already exists for a packet. One way to
> inspect existing states is via # systat state).
>
> >
> >> pass in on egress inet proto icmp icmp-type $icmp_types
> >
> > the icmp_types are probably too restrictive. e.g. TCP relies on
> > ICMP fragmentation-needed messages to implement MTU path discovery
> > over IPv4. OpenBSD implements secure defaults in its own handling
> > of ICMP so far as I know. e.g. it ignores ICMP redirects by default.
> >
> > $ sysctl net.inet.icmp.rediraccept
> > net.inet.icmp.rediraccept=0
> >
> > I myself am comfortable with
> >
> > pass inet proto icmp
> >
> > at the end of my pf.conf. (but I do not consider myself an
> > authority on pf configuration!)
> >
> >
> > good luck!
> >
> > Richard.
> >
Hi Richard,
and misc,
thanks for your advice and motivation to tinker a little bit more!
I think i got it working... at least tcpdump and pftop show something is
going on on both pppoe-links.
Just for the record, here is my new pf.conf which is also simplified and
made it more explicit.
It seems to work with interface-groups like vlan, pppoe.
Maybe I missunderstand what egress is meant for but anyways, I could
achieve the same with pppoe
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
203.0.113.0/24 }
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 pppoe0 from vlan:network nat-to (pppoe0)
match out on pppoe1 from vlan:network nat-to (pppoe1)
block in quick on pppoe from <martians> to any
block return out quick on pppoe from any to <martians>
block all
pass out on vlan to vlan:network
pass in quick on vlan from vlan:network to vlan
pass in on vlan route-to {(pppoe0 pppoe0:network), (pppoe1 pppoe1:network)}
round-robin
pass out on pppoe
block return in on vlan from vlan64:network to vlan32:network
pass in on egress inet proto icmp all
pass in on egress inet proto tcp from any to (egress) port 22
Still one thing to achieve: prefer vlan32 packets over vlan64.
Thanks a lot so far
Thomas
