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"

Reply via email to