February 18, 201610 yr 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.
March 2, 201610 yr 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
March 3, 201610 yr Author 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
March 3, 201610 yr 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.
March 17, 201610 yr Author 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
March 17, 201610 yr 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.
March 24, 201610 yr Author 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
December 3, 20178 yr 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
December 3, 20178 yr Networking functionality has much more expanded in unRAID 6.4. I recommend you use that version. Edited December 3, 20178 yr by bonienl
Archived
This topic is now archived and is closed to further replies.