Local only Z/IP client, remove the ethernet port from br-lan
04/121/2020 | 05:29 PM
In some cases, a solution may be running a zip client locally. In these cases, perhaps you wish to prevent zip traffic from leaving the gateway.
The quickest solution to keeping zip traffic on the gateway, is to take the default lan configuration, and simply delete the ethernet port from the br-lan, leaving all other configuration constant.
Make sure your zipgateway is configured for local-only mode
#reconfigure the zipgateway package
sudo dpkg-reconfigure zipgateway
On the 'Enable Wireless configuration of Z/IP Gateway' screen, select 'wired'
Remove your LAN interface from /etc/network/interfaces.d/br-lan created by the zipgateway package, for example in ubuntu my setup has ethernet interface 'enp0s3' change this to 'none':
auto br-lan
iface br-lan inet dhcp
bridge_stp on
# bridge_ports enp0s3 # <- The original line installed by zipgateway
bridge_ports none
bridge_fd 2
Restart networking
sudo systemctl restart networking
Restart zipgateway
sudo service zipgateway restart
Because the zipgateway controls ipv6 address assignment, a local zip client should now be able to use ipv6 addresses to control end nodes.
But what if you need IPv4 control? You will need to run a dhcp4 server on your gateway. In this example, I am using isc-dhcp-server
Download a dhcp server
sudo apt update; sudo apt install isc-dhcp-server
Bind the isc-dhcp-server to the br-lan by modifying /etc/default/isc-dhcp-server and adding to the "INTERFACESv4" entry.
INTERFACESv4="br-lan"
Using the bridge as our binding interface gives us an added benifit of a constant interface name. If we were to try and rely on our tap in this case, then if zipgateway changes the tap name we run into problems of our dhcp server failing to bind to the correct interface.
If you're feeling adventurous, you can leave this as "", but be advised, if any interface gets an address in a range you specify in dhcpd.conf (later) you will begin serving dhcp requests on that interface. Probably not what you want.
In order to host dhcp on an interface, that interface needs a static IP address. Let's modify /etc/network/interfaces.d/br-lan to use a static address; Pick your favorite local subnet, here - I've used 192.168.123.X/24; Note that we change the top line to 'static' rather than 'dhcp'
auto br-lan
#iface br-lan inet dhcp # <- the old line we're replacing
iface br-lan inet static
bridge_stp on
# bridge_ports enp0s3
bridge_ports none
bridge_fd 2
#modifications for static ip4 mode:
address 192.168.123.1
broadcast 192.168.123.255
netmask 255.255.255.0
gateway 192.168.123.1
Now that our dhcp server has a static address, let's configure a range for our zip devices...
add the following to /etc/dhcp/dhcpd.conf; Be sure your range matches a subnet that your static address is in
Note that 200-1 = 199 ipv4 addresses; Not enough ipv4 addresses if you were to have the maximum 2^8=255 nodes; If you need ipv4 addresses for every possible node ID, you will want to change your netmask above to 255.255.254.0 and be aware that your static address should also widen its netmask
Next, enable the dhcp server on reboots
sudo systemctl enable isc-dhcp-server
At this point, you should reboot and confirm everything is working. You should now be able to control zip nodes with ipv4 addresses.
Local only Z/IP client, remove the ethernet port from br-lan
In some cases, a solution may be running a zip client locally. In these cases, perhaps you wish to prevent zip traffic from leaving the gateway.
The quickest solution to keeping zip traffic on the gateway, is to take the default lan configuration, and simply delete the ethernet port from the br-lan, leaving all other configuration constant.
Because the zipgateway controls ipv6 address assignment, a local zip client should now be able to use ipv6 addresses to control end nodes.
But what if you need IPv4 control? You will need to run a dhcp4 server on your gateway. In this example, I am using isc-dhcp-server
Bind the isc-dhcp-server to the br-lan by modifying /etc/default/isc-dhcp-server and adding to the "INTERFACESv4" entry.
Using the bridge as our binding interface gives us an added benifit of a constant interface name. If we were to try and rely on our tap in this case, then if zipgateway changes the tap name we run into problems of our dhcp server failing to bind to the correct interface.
If you're feeling adventurous, you can leave this as "", but be advised, if any interface gets an address in a range you specify in dhcpd.conf (later) you will begin serving dhcp requests on that interface. Probably not what you want.
In order to host dhcp on an interface, that interface needs a static IP address. Let's modify /etc/network/interfaces.d/br-lan to use a static address; Pick your favorite local subnet, here - I've used 192.168.123.X/24; Note that we change the top line to 'static' rather than 'dhcp'
Now that our dhcp server has a static address, let's configure a range for our zip devices...
add the following to /etc/dhcp/dhcpd.conf; Be sure your range matches a subnet that your static address is in
Note that 200-1 = 199 ipv4 addresses; Not enough ipv4 addresses if you were to have the maximum 2^8=255 nodes; If you need ipv4 addresses for every possible node ID, you will want to change your netmask above to 255.255.254.0 and be aware that your static address should also widen its netmask
Next, enable the dhcp server on reboots
At this point, you should reboot and confirm everything is working. You should now be able to control zip nodes with ipv4 addresses.