Multiple NIC/Multiple Subnet Question

[dark_avenger]

Hi,

 

I'm running unRAID 6.1.8 with two NIC's both are on separate subnets:

192.168.1.* and 192.168.100.* ranges.

 

After reading through the forum I found some older posts and can bring up the second NIC manually with

ifconfig eth1 192.168.100.200 netmask 255.255.255.0 up

 

The suggestion was to include this command in the go script however in doing so it changes the default routes to use that subnet and the interface can no longer be accessed from the 192.168.1.* subnet until commenting out the line in the go script, restarting and then manually running the command after login.

 

The second problem being when I want to add dockers by creating the bridge it seems to get both NIC's and then I cannot access the NAS from the second NIC.

 

Is there a way that I can set the bridge just to use the first NIC and just manually configure the second NIC by perhaps adding something to the network config file?

 

Thanks in advance,

David.

[dark_avenger]

Anybody got any suggestions?

[ken-ji]

Wait you need to access the 192.168.100 netwrok/interface from the 192.168.1 network? so you're trying to use unraid as a router?

I don't quite get you there... the command you provided doesn't change the default routes it just makes 192.168.100.x accessible via eth1 and that network can talk to your unraid via the same eth1. there should be no impact to eth0 and the 192.168.1.x network

 

your second issue is that there is no ui for limiting the members of the bridge.

so you add this to your go script:

brctl delif br0 eth1

which frees up eth1 from the bridge

 

[dark_avenger]

Both networks are completely separate. The 192.168.100.x network is used in the workshop and is an "untrusted" network and the 192.168.1.x network is the internal network.

Neither need to talk to each other but both need to talk to the unRAID machine.

 

The go script now reads:

brctl delif br0 eth1
ifconfig eth1 192.168.100.200 netmask 255.255.255.0 up

 

Which brings up the 192.168.100.x interface no problem and I can access the web interface no problem however the 192.168.1.x network then has no access at all.

 

Without the bridge simply bringing up eth1 now seems to work and doesn't change the default route, not quite sure what was causing that previously.

 

Thanks in advance,

David

[ken-ji]

can you run the following on the command line and post back the results?

ip addr
ip route
netstat -lntp
brctl show

 

I'm rather confused on why you are having access problems.

 

[dark_avenger]

This is with the bridge disabled.

 

 

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN
    link/ipip 0.0.0.0 brd 0.0.0.0
3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN
    link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: ip_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN
    link/ipip 0.0.0.0 brd 0.0.0.0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 1c:6f:65:25:c3:7c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.15/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 1c:af:f7:70:c8:cf brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.200/24 brd 192.168.100.255 scope global eth1
       valid_lft forever preferred_lft forever

 

ip route
default via 192.168.1.1 dev eth0  metric 206
127.0.0.0/8 dev lo  scope link
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.15  metric 206
192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.200

 

netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Progra          m name
tcp        0      0 0.0.0.0:53569           0.0.0.0:*               LISTEN      1365/rpc.s          tatd
tcp        0      0 0.0.0.0:37              0.0.0.0:*               LISTEN      1375/inetd          
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1430/smbd           
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1361/rpc.p          ortmap
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9510/emhtt          p
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1375/inetd          
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1385/sshd           
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      1375/inetd          
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1430/smbd   

 

brctl show
bridge name     bridge id               STP enabled     interfaces

[ken-ji]

while the bridge is disabled, I don't see any reason why you should have access issues.

default route is via the 192.168.1.1 network, so internet and other trusted resources should be there, and they can access via 192.168.1.15

192.168.100.x is isolated to the interface, so the untrusted can access via 192.168.100.200.

 

so going back to your issue, you can enable the bridge, and put this in your go file

brctl delif br0 eth1
ip addr add 192.168.100.200/24 dev eth1

 

this will disconnect eth1 from the bridge and give it the address 192.168.100.200 and recognize the subnet.

 

the ip command is the equivalent to the ifconfig command so I'm not really sure why you are having issues.

After placing these changes in and it still don't work, please run the commands again (while the bridge is enabled) and that may shed light on what exactly is going wrong.

 

[dark_avenger]

I've updated the go script and re-enabled the bridge and now all seems to be working fine 

 

Not sure what was causing it before, thank you very much for your help

[WTF?]

Hi dark_avenger! (and ken-ji and anyone else with relevant knowledge/interest),

 

I'm a newb and interested also in segregating nic's to represent trusted and untrusted subnets that access UNRAID, but not each other.  Is this more secure than just setting up user and user access (secure or private, write only, e.g.) to various shares and if so please explain the why's and how's (e.g. besides setting up the subnets what else does one need do?).

 

Thanks in advance!

 

WMW

[bonienl]

Networking functionality has much more expanded in unRAID 6.4. I recommend you use that version.

 

Edited December 3, 2017 by bonienl