You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Regarding segment of code in
add-vpn-iptables-rules.sh
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.
The text was updated successfully, but these errors were encountered: