Regarding segment of code in add-vpn-iptables-rules.sh
# Exempt the local VPN IPs
for addr in $(ip a show dev ${dev} 2>/dev/null | sed -En s/".*inet ([^ \/]+)(\/[0-9]+)? .*"/"\1"/p); do
add_rule IPV4 mangle "PREROUTING -d ${addr} -m mark --mark ${MARK} -j MARK --set-xmark 0x0"
done
for addr in $(ip a show dev ${dev} 2>/dev/null | sed -En s/".*inet6 ([^ \/]+)(\/[0-9]+)? .*"/"\1"/p | grep -Ev "^fe80"); do
add_rule IPV6 mangle "PREROUTING -d ${addr} -m mark --mark ${MARK} -j MARK --set-xmark 0x0"
done
I don't think this is necessary, at least not for internal nexthop. I'm not sure if needed for 'external' or other configurations. For internal nexthop configurations, the gateway/bridge that holds the VPN server on the LAN is never directly contacted by origin of the packets. Assuming VPN server is 192.168.42.42 on br0/192.168.42.1 the packets come in on (i.e. br9999) and then get routed to 192.168.42.42 directly via the routing table. They do not access 192.168.42.1/br0 itself.
Regarding segment of code in
add-vpn-iptables-rules.shI don't think this is necessary, at least not for internal nexthop. I'm not sure if needed for 'external' or other configurations. For internal nexthop configurations, the gateway/bridge that holds the VPN server on the LAN is never directly contacted by origin of the packets. Assuming VPN server is 192.168.42.42 on br0/192.168.42.1 the packets come in on (i.e. br9999) and then get routed to 192.168.42.42 directly via the routing table. They do not access 192.168.42.1/br0 itself.