-1

i`m trying to connect multiple subnets to one web server but these subnets should not be able to connect to each other.i cant make any changes on these subnets. I just have a lan cable from each subnet and my server. tnx

10
  • Does each subnet have a distinct IP address range or are there overlaps to deal with? What OS will the server be running? Oct 1, 2016 at 9:11
  • If I understand correctly all machines, including the server are connected to a single switch. Correct? What is this switch model and configuration?
    – JFL
    Oct 1, 2016 at 9:34
  • actually its not a server. its a stand alone dvr. subnets may have diffrent ip range or they may have not. there is no device as switch or hub. i have to use the right one.
    – b_maze
    Oct 1, 2016 at 12:22
  • How do all these subnets connect to the DVR? Do they use a single cable or does the DVR have multiple network interfaces, one for each subnet?
    – ojs
    Oct 1, 2016 at 13:38
  • First find out if the 2 networks have the same or overlapping ip range, and what network equipment is already in place (and that you can change the configuration of). Without that information the question is way too broad. If you really only have 2 cables and your server then the server needs to have 2 ports, or you need additional equipment.
    – hertitu
    Oct 1, 2016 at 20:12

3 Answers 3

1

Sure. Simply plug each cable into a multi-port Ethernet card on the Web server, or, into an Ethernet switch or bridge if your server has only 1 NIC. Configure the Web server with an IP address corresponding to the subnet on each cable if using a multiport NIC card. If using a switch or bridge and single server NIC, configure a secondary, tertiary, and quaternary IP addresses on the single NIC.

Note: in case of a single server NIC, an endpoint in subnet A could be configured with a secondary IP address in Subnet B and in that case it could communicate with devices on subnet B, so if security is a huge concern, you'll need a layer3 switch to assign a unique subnet for the server then use access lists to disallow inter-subnet (inter-vlan) routing.

4
  • It's not a web server, it's a DVR with one interface and one address.
    – Ron Maupin
    Nov 11, 2016 at 4:03
  • @RonMaupin "i`m trying to connect multiple subnets to one web server" Nov 11, 2016 at 4:11
  • "actually its not a server. its a stand alone dvr. subnets may have diffrent ip range or they may have not. there is no device as switch or hub. i have to use the right one. – b_maze Oct 1 at 12:22"
    – Ron Maupin
    Nov 11, 2016 at 4:12
  • sounds like he needs to update his question. In any case, my answers covers it. Nov 11, 2016 at 4:23
0

i`m trying to connect multiple subnets to one web server but these subnets should not be able to connect to each other.i cant make any changes on these subnets. I just have a lan cable from each subnet and my server. tnx

The obvious solution to this would be a multihomed server. The server has a NIC on each subnet and responds to requests from all of them.

However your clarifications in comments show that this solution won't work in your specific case.

actually its not a server. its a stand alone dvr.

Ok. So presumablly it only has one network port and can only have one IP address.

So we will need some sort of box to go between the dvr and the networks. This answer explores the possibility of using a linux box for that role. In general linux boxes are often an economical solution for complex network tasks.

It's fairly easy to put a substantial number of NICs in a linux box. For example the ASUS P9D-M micro ATX motherboard has two onboard Intel NICs and four expansion slots suitable for quad NICs giving a total of up to 18 ports. If you need more than that then I would suggest using a managed switch as a port multiplier.

If the subnets are non-overlapping then it's easy enough. The linux box gets a network port for each network and one for the DVR. DNAT is used to forward connections to the DVR. Firewall rules would be set up to allow all of the networks to communicate with the DVR but not with each other.

Since iptables NAT is connection based it can happily handle translating multiple original destinations to the same translated destination.

some subnets have same ip range

This makes life trickier.

On a multihomed linux box provided the linux box has a different IP on each interface you can use policy routing based on the source IP to deal with multiple interfaces in overlapping subnets.

Unfortunately in my testing (on linux 3.14) it appears that policy routing selects which routing table to use before the NAT machinery performs it's reverse translation.

To workaround this we need to pass the traffic through the network stack twice. The first time through the NAT machinery will do it's thing. The second time through policy routing will do it's thing.

On the second time through the stack we need to stop the traffic hitting the NAT machinary again and confusing it. We can achieve this through the NOTRACK target in the PREROUTING chain of the raw table


What follows is a worked example demonstrating the concepts described in the post above. It is a cleaned up version of some tests I did to prove that the concepts actually worked.

In the example all the network roles are played by network namespaces. Obviously in a real scenario most of those would be physical boxes ("bounce" would still likely be a network namespace). The roles of the network namespaces are.

  • "client1" and "client2", two clients on different networks but with the same IP address.
  • "server" the box that performs DNAT and policy routing
  • "natted" the box with a single interface and IP address behind the DNAT (i.e. your DVR)
  • "bounce", the "bounce box" to work arround the issue with policy routing and DNAT.

Note that this example has no firewalling, in a practical implementation you would want to add that.

ip netns add server
ip netns add client1
ip netns add client2
ip netns exec
ip netns exec server ip addr list
ip link add veth1client type veth peer name veth1server 
ip link set veth1client netns client1
ip link set veth1server netns server
ip netns exec server ip addr add 10.0.0.1/24 dev veth1server
ip netns exec server ip link set veth1server up
ip netns exec client1 ip addr add 10.0.0.2/24 dev veth1client
ip link add veth2client type veth peer name veth2server 
ip link set veth2client netns client2
ip link set veth2server netns server
ip netns exec server ip addr add 10.0.0.3/24 dev veth2server
ip netns exec client2 ip addr add 10.0.0.2/24 dev veth2client
ip netns exec client2 ip link set veth2client up
ip netns exec server ip link set veth2server up

This first block of commands sets up the client and server network namespaces and establishes links between them.

At this point client1 can ping the server (on 10.0.0.1) but client2 fails to ping the server (on 10.0.0.3), we have a routing conflict and it seems that client1's route wins.

To fix this lets add some policy routing.

cp /etc/iproute2/rt_tables /etc/netns/server/iproute2/rt_tables
echo $'1\tclient1' >>  /etc/netns/server/iproute2/rt_tables
echo $'2\tclient2' >>  /etc/netns/server/iproute2/rt_tables
ip netns exec server ip rule add from 10.0.0.1 lookup client1
ip netns exec server ip rule add from 10.0.0.3 lookup client2
ip netns exec server ip route add 10.0.0.0/24 dev veth1server table client1
ip netns exec server ip route add 10.0.0.0/24 dev veth2server table client2

Now client1 can ping the server on 10.0.0.1 and client2 can ping the server on 10.0.0.3 despite the fact that the two clients share the same IP address.

That's cool and all but our aim was to get the clients to talk to a single-homed box behind our multi-homed server. Lets add the single homed box, enable IP forwarding and set up NAT.

ip netns add natted
ip link add vethnserver type veth peer name vethnnatted
ip link set vethnserver netns server
ip link set vethnnatted netns natted
ip netns exec server ip link set vethnserver up
ip netns exec server ip addr add 10.0.1.2/24 dev vethnserver
ip netns exec natted ip link set vethnnatted up
ip netns exec natted ip addr add 10.0.1.1/24 dev vethnnatted
ip netns exec server iptables -A PREROUTING -t nat -d 10.0.0.1 -j DNAT --to-destination 10.0.1.1
ip netns exec server iptables -A PREROUTING -t nat -d 10.0.0.3 -j DNAT --to-destination 10.0.1.1
ip netns exec server sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
ip netns exec natted ip route add default via 10.0.1.2

Unfortunately due to the policy routing/DNAT issue described above only one of the clients works. To workaround this we add the "bounce box".

ip netns add bounce
ip link add vethbserver type veth peer name vethbbounce
ip link set vethbserver netns server
ip link set vethbbounce netns bounce
ip netns exec bounce sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
ip netns exec server ip link set vethbserver up
ip netns exec server ip addr add 10.0.2.1/24 dev vethbserver 
ip netns exec bounce ip link set vethbbounce up
ip netns exec bounce ip addr add 10.0.2.2/24 dev vethbbounce
ip netns exec bounce ip route add default via 10.0.2.1
echo $'250\tbounce' >>  /etc/netns/server/iproute2/rt_tables
ip netns exec server ip rule add from 10.0.1.1 lookup bounce
ip netns exec server ip route add 10.0.0.0/24 via 10.0.2.2 table bounce
ip netns exec iptables -t raw -I PREROUTING -i vethbserver -j NOTRACK

and finally lets check it actually works, not just for pings but for http.

ip netns exec natted python -m SimpleHTTPServer &
sleep 1
ip netns exec client1 wget 10.0.0.1:8000
ip netns exec client2 wget 10.0.0.3:8000
0

To accomplish this requirement create a Vlans for each segment and isolate traffic . And further create a access-list that web server is accessible from each Vlan segment independently .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.