I just read some tutorials and (again) the "Book _great_ Book of PF" and
simplified my
pf.conf and still everthing works fine:
int_if = "{ vlan32, vlan64 }"
int_lan = "{ 10.10.10.0/24, 10.64.0.0/10}"
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 pppoe from $int_lan nat-to (pppoe)
# VOIP Prio
match on vlan32 proto { tcp udp } to port { 5060 5064 } set prio 7
match on vlan32 proto udp from port 11780:12780 set prio 7
#Internal prio
match on vlan32 set prio 5
block in quick on pppoe from <martians> to any
block return out quick on pppoe from any to <martians>
block in
pass out on egress
pass quick on vlan32 to vlan32:network
pass quick on vlan64 to vlan64:network
block return in on vlan from vlan64:network to vlan32:network #no guests to
office
block return in on vlan inet proto tcp from any to any port 25 #avoid spam
out
pass in on $int_if route-to { (pppoe0 pppoe0:network), (pppoe1
pppoe1:network) } least-states sticky-address
pass in on egress inet proto icmp all
pass in on pppoe0 proto tcp from any to (pppoe0) port ssh
> > 1. Somtimes the traffic is not even distributed between the uplinks.
> > My guess is this is due to the source-hash method which
> > - when I understand correctly - distributes traffic per IP and not per
> > connection.
> > When I use [round-robin | least-state] sticky-address i´ve problems with
> my
> > VoIP.
> > An maybe some guests have problems with "secure" web apps* too.
> > Anybody an Idea how to do prober loadbalancing with almost only https
> > traffic?
>
> The only way you're likely to do better is to tunnel the traffic
> to another machine on decent bandwidth using a multilink protocol
> that knows how to deal with this - mlvpn comes to mind (it's in
> packages).
>
I gues a clean and simple solution here would be a
"Provider Independent" IPv6 Range and mulit-path routing or I´m missing
something with this concept?
> > 2. I tried to custumize this rules to also include vlan[3|4] to the
> > load-balancing.
> > 2.1. use egress-group instead of the pppoe-group for nat-to:
> >
> > match out on egress from $int_lan nat-to (egress) source-hash
> >
> > 2.2. add vlan[3|4] to the route-to rule:
> >
> > pass in on $int_if route-to { (pppoe0 pppoe0:network), (pppoe1
> > pppoe1:network),\
> > (vlan3 vlan3:network), (vlan4 vlan4:network) } source-hash
> >
> > But it didn´t work: No internet connection from vlan32 and vlan64
>
> It's been a long time since I had to do this but at least you'll need to
> nat on each pppoe interface individually to the correct address for that
> interface. e.g. "match out on pppoe0 from ... nat-to (pppoe0)"
>
> What you are doing now will rewrite the address to *one* of the egress
> interface addresses. Which will only be correct if the packet is being
> sent out of the interface with that address.
>
> > 3. ping with the -I flag is strange.
> > To see if my uplinks are working I used to:
> > # ping -I [assigend or static IP] 8.8.8.8
> > somtimes it works for an IP and doens´t for another like:
> > #ping -I [my static IP] 8.8.8.8 works
> > #ping -I [my static IP] 1.1.1.1 doesn´t work
> > #ping 1.1.1.1 works
> >
> > #ping -I [dynamic IP] 8.8.8.8 doesn´t work
> > #ping -I [dynamic IP] 1.1.1.1 works
> > #ping 8.8.8.8 works
>
> I never came up with a satisfying way to do this. Dirty method is to
> find some specific "always on" addresses and direct one to one isp,
> another to another isp, etc, and ping those ..
>
> There's another method of diverting traffic over multiple ISPs,
> using multiple route tables + rdomains, but the selector in PF is a
> bit simpler, to achieve balancing you can use the "probability"
> modifier, but there's no stickiness so you are likely to have the
> problem with voip and banks etc.
>
I just need that for testing purpose and was not sure if I do something
wrong with the ping command. But doesn´t seem so.
But it seems, that this issue is related to my ssh-connecting issue.
I tried to connect from somwhere else. It didn't work directly, but
going through my openbsd.amsterdam-vm worked...
kind of strange.
So basically, I'm again into getting up the pppoe connection for uplink
3 and 4 within the OpenBSD box and hope that loadbalancing works when
extending the pf-rules with this two (pppoe2, pppoe3) interfaces.
Thanks again Stuart and everybody else.
Thomas
