Hello,
</snip>
> >
> >
> > I'm not sure if proposed scenario real. Let's assume there
> > is a PF box with three NICs running on this awkward set up
> >
> > em1 ... 192.168.1.10
> >
> > em0
> >
> > em2 ... 192.168.1.10
> >
> > em0 is attached to LAN em1 and em2 are facing to internet which is
> > reachable with two different physical lines. both lines are connected
> > via
> > equipment, which uses fixed IP address 192.168.1.10 and PF admin has
> > no way to change that.
>
> in this scenario are em1 and em2 connected to the same ethernet
> segment and ip subnet?
em1 and em2 are connected to different wires (broadcast domains).
and I agree this set up is really awkward. not sure if it will work
because it also depends on how ARP table is organized. I think it
works on Solaris, but I have not tried that with OpenBSD.
>
> > the 'address@interface' syntax is the only way to define rules:
> >
> > pass in on em0 from 172.16.0.0/16 route-to 192.168.1.10@em1
> > pass in on em0 from 172.17.0.0/16 route-to 192.168.1.10@em2
> >
> > regardless of how much real such scenario is I believe it can
> > currently work.
>
> this is a very awkward configuration. while i think what it's trying
> to do is useful, how it is expressed relies on something i want to
> break (fix?).
yes I completely agree. I believe this 'awkward thinking' stems
back to ipf (ipfilter). I found my ancient notes to find some details
on this. My notes refer to ipf.conf(5) manpage [1].
If I understand the purpose of 'address@interface' syntax right,
it allows us to forward packets using explicit pair [ next-hop IP,
interface ]. Thus firewall can emulate a route, which might be missing in
routing table. It just 'blindly' sends matching packet to next-hop using
desired interface assuming that 'next-hop' host will do the right thing
with such packet.
>
> one of the original reasons i wanted to break this kind of config
> is because pfsync hasn't got a way to exchange interace information,
> and different firewalls are going to have different interface
> topologies anyway. one of the reasons to only use a destination/next
> hop as the argument to route-to rules was so pfsync would work.
yes I understand that. I'm not able to judge how many currently working
configurations will remain broken after we kill 'address@interface' form.
I'm sure many deployments will get fixed with simple tweak:
echo 'address@interface'|cut -d @ -f 1
but I'm not sure how many people do still need to order desired NIC.
>
> i'm pretty sure this is broken at the moment because of bugs in the
> routing code. it is possible to configure routes to 192.168.1.10
> via both em1 and em2 if net.inet.ip.multipath is set to 1, but im
> sure the llinfo (arp and rtable) part of this kind of multipath
> route setup does not work reliably. i guess i should try and get
> my fixes for this into the tree.
>
> there are two alternate ways i can think of to do this. the first
> is to configure an rtable for each interface:
>
> # route -T 1 add default 192.168.1.10 -ifp em1
> # route -T 2 add default 192.168.1.10 -ifp em2
>
> then you could write rules like this:
>
> pass in on em0 from 172.16.0.0/16 rtable 1
> pass in on em0 from 172.17.0.0/16 rtable 2
>
> the other is to add add routes "beyond" 192.168.1.10 and route-to
> them:
>
> # route add 127.0.1.10 192.168.1.10 -ifp em1
> # route add 127.0.2.10 192.168.1.10 -ifp em2
>
> then you can write rules like this:
>
> pass in on em0 from 172.16.0.0/16 route-to 127.0.1.10
> pass in on em0 from 172.17.0.0/16 route-to 127.0.2.10
>
> this will likely hit the same bugs in the rtable/arp code i referred
> to above though.
>
> also, note that i haven't tested either of these.
>
I think this sounds like a plan how to deal with edge cases,
which can't get fixed with simple 'cut -d @ -f 1'
thanks and
regards
sashan
[1] https://www.freebsd.org/cgi/man.cgi?query=ipf.conf&sektion=5&apropos=0
(search for reply-to)
