Server with multiple public IP

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>