On 4/28/14, 7:06 PM, Dominic Froud wrote:
On 28/04/2014 11:15, Julian Elischer wrote:
replying to myself..
On 4/28/14, 6:11 PM, Julian Elischer wrote:
On 4/28/14, 5:44 PM, Andrea Venturoli wrote:
On 04/28/14 11:18, Andreas Nilsson wrote:
You could put all the services which are on 2.0.0.2 in a
separate fib and
there have another default-route.
Thanks, but unfortunately I can't, since some services must be
able to answer on both addresses.
the answer is to use the ipfw setfib rule for incoming packets on
the second interface.
setfib 1 ip from any to any in recv em0
In new freebsd kernels you can do this with ifconfig em0 fib 1 (I
think that's the syntax) without involving ipfw.
then the session will inherit that fib. Outgoing packets from that
session will use fib 1 while other outgoing packets will use fib0.
from the ifconfig man page. (FreeBSD 11 but I think it's in 10 too.)
fib fib_number
Specify interface FIB. A FIB fib_number is assigned
to all
frames or packets received on that interface. The FIB
is not
inherited, e.g., vlans or other sub-interfaces will
use the
default FIB (0) irrespective of the parent interface's
FIB. The
kernel needs to be tuned to support more than the
default FIB
using the ROUTETABLES kernel configuration option, or the
net.fibs tunable.
this can be simulated using ipfw setfib should you not have it in
the release you are running.
"Outgoing packets from that session will use fib 1 while other
outgoing packets will use fib0."
I haven't tried this but outgoing packets not associated with any
existing fib1 session (e.g. new TCP connections, UDP, etc.) could
also be attached to fib1 with a rule like this?
setfib 1 ip from 2.0.0.0/29 to any out xmit vlan2
Keeping all the rules in ipfw is one advantage but then you have to
maintain 2 sets of routing tables - one for each fib.
Doing source-routing with pf means two firewalls to manage but just
one routing table. You could argue that the routing table is
obscured by rules in pf though so doing "netstat -rnf inet" wouldn't
be authorititative.
I'd like to do something like this:
route add -srcnet 2.0.0.0/29 2.0.0.1
(kernel uses arp to translate 2.0.0.1 to an interface address like
vlan2)
ok so you have to make a decision on each session:
"which link should I use for outgoing packets?"
(You can't control incoming packets for sessions initiated remotely).
answers are:
(1) the one that the request came in on, so the session is symetrical.
(2) one selected for some other reason. In this case the session may
be asymetrical, and you need to pass out packets that appear to come
from the other interface... Your ISP may hate you for this and block
them as they are effectively
"spoofed packets" from their perspective and it may break you service
agreement.
For outgoing sessions option 2 works fine and you can just use a
single routing table to to this, or select which FIB to use with some
"undisclosed" decision, but for incoming sessions you really would do
best to make your outgoing packets go out the way the request came
in, and this is what option 1 does.. by setting up two fibs, each
with a separate default route, and just selecting the fib to use
depending on the incoming interface.
Some people (me) also sometimes use NAT as well so that the outgoing
packet is NAT'd to the correct address as it exits (has to be an
outgoing session though), but it can be from a computer behind you for
which you are routing.. that is how you can put a whole intranet out
on multiple ISPs. But you need a different NAT instance on each
external interface.
Dom
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
