3 Nics - Dual (Tripe) Homed Host

[Pavel Duda]

Steven N. Fettig wrote:

> Travis Troyer wrote:
> 
>> I have a FreeBSD system that acts as a NAT Gateway, currently 
>> providing on LAN with access to the Internet.  I have added a third 
>> NIC, connected to a second LAN.  The second LAN does not need internet 
>> access, but I would like it to be able to communicate with the first 
>> LAN.  I have tried reading various sources, but have not found 
>> anything dealing with this situation. I would appreciate any help.  
>> Below is a diagram of my current setup and the output of ifconfig.
>>
>>                             Internet
>>                                 |
>>                 [ xl0: DHCP assigned ]
>>                            Router
>>                             |      |
>>             [ xl1: 10.0.0.1]  [ xl3: 192.168.1.10]
>>         10.0.0.0/24 LAN  192.168.1.0/24 LAN
>>
>> Output of ifconfig:
>> xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>        options=8<VLAN_MTU>
>>        inet 24.33.126.252 netmask 0xffffff00 broadcast 255.255.255.255
>>        ether 00:60:97:74:35:b0
>>        media: Ethernet autoselect (10baseT/UTP)
>>        status: active
>> xl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>        options=b<RXCSUM,TXCSUM,VLAN_MTU>
>>        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
>>        ether 00:01:02:37:93:eb
>>        media: Ethernet autoselect (100baseTX <full-duplex>)
>>        status: active
>> xl2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>        options=b<RXCSUM,TXCSUM,VLAN_MTU>
>>        inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
>>        ether 00:01:02:cc:63:d2
>>        media: Ethernet autoselect (100baseTX <full-duplex>)
>>        status: active
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
>>        inet 127.0.0.1 netmask 0xff000000
>>
> Travis,
> 
> Although I have been dealing with routing for years, I can't claim I 
> really understand it well, so my advice may not be so intelligent, but 
> here's a stab at it anyway:
> I think what you want to do is to bridge both LAN's.  You need to tell 
> your gateway that in order to get to 10.0.0.0/24 from 192.168.1.0/24, 
> you need to tell the routing tables that the route to 10.0.0.0/24 is via 
> xl1 and vice versa.
> route add 10.0.0.0/24 -interface xl1
> 
> and vice versa:
> 
> route add 192.168.1.0/24 -interface xl2
> 
> In the handbook, it says 
> (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bridging.html): 
> 
> <--begin quote-->
> 19.5.4 Enabling the Bridge
> 
> Add the line:
> net.link.ether.bridge=1
> 
> 
> to /etc/sysctl.conf to enable the bridge at runtime, and the line:
> net.link.ether.bridge_cfg=if1,if2
> 
> 
> to enable bridging on the specified interfaces (replace if1 and if2 with 
> the names of your two network interfaces). If you want the bridged 
> packets to be filtered by ipfw(8), you should add:
> net.link.ether.bridge_ipfw=1
> 
> 
> as well.
> 
> For FreeBSD 5.2-RELEASE and later, use instead the following lines:
> net.link.ether.bridge.enable=1
> net.link.ether.bridge.config=if1,if2
> net.link.ether.bridge.ipfw=1
> <--end quote-->
> 
> I am not sure if this will work, though, because I'm not sure what 
> effect (if any) it would have on the NAT from the 192.168.1.0/24 
> network.  You might want to first try this approach while NAT and the 
> firewall are turned off.  I have a similar situation that I want to 
> test, so I'd be curious if you succeed and how.
> 
> Steve Fettig
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at freebsd.org"
> 

This should work fine with NAT. I was using similar setup during tests 
with wi-fi : server with wi-fi card (hostap and DHCP - 192.168.1.xxx 
range), one NIC connected to local LAN (192.168.0.xxx range) and one NIC 
for connection to my ISP ( to cable modem to be more specific ). Only 
people on local lan were able to connect to internet - this was 
controlled via ipfw rules.