For some reason I mistakenly had it in my head that what I wanted to do wasn't possible.... based on a previous firmware query:
HTML / .asp modification but clearly (in this specific requirement) I can influence the desired script behaviour that is executed, and that D'oh!
I was already hacking GUI HTML e.g. '
/www/require/modules/menuTree.js' etc. see
RefreshWWW.sh HTML patch for @kvic NTPD Tools TAB
Now ideally each row to be added should preferably be implemented by a drop-menu for the desired field layout (since we write to the same
NVRAM vpn_clientX_clientlist variable anyway)
'Desc/SourceIP/TargetIP/IFACE'
Code:
Description xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx VPN/WAN
'IPSET/Dimension/Dimension/Dimension'
Code:
IPSET_name SRC/DST SRC/DST SRC/DST
but being too lazy to compile a custom firmware I'd rather hack a solution, so although IPSET fwmark routing can be achieved surreptitiously in the background, it is convenient (in the GUI) to at least quickly review (i.e. add/remove) what I've
actually currently got selectively routed!
There are far better web-hosted tutorials on using
multi-dimension IPSETs but rather than describe
'src,dst' I'll describe -
e.g. a 3-dimension IPSET
Code:
ipset new test hash:ip,port,ip hashsize 64
ipset add test 10.0.0.1,tcp:8080,7.7.7.7
ipset list test
Name: test
Type: hash:ip,port,ip
Revision: 5
Header: family inet hashsize 64 maxelem 65536
Size in memory: 136
References: 0
Number of entries: 1
Members:
10.0.0.1,tcp:8080,7.7.7.7
So using iptables rule '
-m matchset test src,dst,dst -j MARK --set-mark $FWMARK_OVPNC4', means LAN device
10.0.0.1 (
src) traffic to
7.7.7.7 (
dst) using
TCP Port
8080 (
dst) is via
VPN Client4.
Suppose I add
Code:
ipset add test 10.0.0.2-10.0.0.10,udp:4444,4.4.4.4
Now using the
same IPSET I could use another iptables rule '
-m matchset test dst,dst,src - j ACCEPT' and any
UDP Port
4444 (
dst) traffic from
4.4.4.4 (
src) to any LAN device in the range
10.0.0.2-10.0.0.10 (
dst) is allowed!
NOTE: Clearly some combinations are not bidirectional
e.g.
src,dst is invalid for the 2-dimensional IPSET
as MACs can only ever match on
'src'.
I assume the
dnsmasq 'ipset=' directive only allows a 1-dimensional but allows both a 'src' and 'dst' so either will match?, but iptables could capture the
src,dst pair by writing
direct to the IPSET
(That is what I do in
PortScanBlocking.sh)
