-
-
Notifications
You must be signed in to change notification settings - Fork 794
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature request]: iptables rules #1623
Comments
Complete change: All other rules work - but if openvpn goes down or wg goes down, this will block any traffic attempting to bypass tunnel. |
This is implemented for WireGuard with PostUp / PreDown rules as described here. |
wireguard doesnt perform well for my use case as crazy as it sounds. Heres my final form of iptables kill switch. Its tested - if openvpn abends nothing passes. I've now used this ruleset for a couple months - its been reliable. Even swithing from openvpn config to openvpn config - if there is a hiccup in openvpn these rules prevent ANY leak. What would be nice is for this to be the default for openvpn, with an option to "reset firewall" in the event the user messed with firewall rules and wants to get back to working state. #RASPAP OPENVPN KILL SWITCH# NOTHING passes if openvpn tunnel drops.Previously, masquerade would pass traffic from interface to interface, bypassing TUN if tunnel disappeared.My use case is TUN or nothing.These rules stop masquerade from forwarding without passing thru tunnel first.***** First: clear every possible user setting ******Accept all traffic first to avoid ssh lockdown via iptables firewall rulesiptables -P INPUT ACCEPT Flush All Iptables Chains/Firewall rulesiptables -F Delete all Iptables Chainsiptables -X Flush all counters tooiptables -Z Flush and delete all nat and mangleiptables -t nat -F **** Now apply tight firewall rulesRASPAP relies on Masquerading - which means forwarding.Do not allow any forwarded packet that doesnt travel thru a wg+ or tun+ interfacelo traffic very okiptables -A INPUT -i lo -j ACCEPT #All local lan traffic ok - assumes 192.168.1.1 to 192.168.255.255 #Emergency override - put your mac address here #Do not allow tun to tun packets - this is a probing attack #Do not allow anything from TUN to hit local network - this is a probing attack #Very ok - tun to wlan - this is what we want #Very ok wlan to tun #very ok eth to tun #Very ok tun to eth #very ok - any established connection from tun to wlan #very ok all output packets #NAT rules (forwarding) #iptables are cumulative - final rule - drop every forwarded packet that doesnt meet any rule above |
sorry for formatting bill - i didnt realize markdown would make my comments show like that |
added branch and merge request - i know its not right place but its a cleaner file to review firewall rules |
Code of Conduct
Issue reporting checklist
Operating System
Raspberry Pi OS (64-bit) Lite Bookworm
Quick install or Manual setup?
Quick install
Onboard wireless chipset or external adapter?
Onboard wireless chipset
Hardware
Raspberry Pi 4 Model B
RaspAP version
3.1.3 (Latest)
Other software or services running with RaspAP?
Yes (specify below)
Contact details (optional)
[email protected]
Bug description
I think there is an issue with iptables on set up - ive logged a few cases on this before, but i think i now have an answer.
And it could just be my issue -
Masquerade means "just try to send that packet no matter what" - the default is to just forward packet any way possible.
The default is to forward everything and anything.
If the behaviour is not to want that you have to explicitly state this in a DROP rule.
I struggled with this for a while before finally realizing that without the DROP rule, if any of the configured vpn's (openvpn, wireguard, nord, etc) go down, packets are automatically forwarded OUTSIDE the tunnel.
This is absolutely not the behaviour i personally want.
The change is simple - add:
-P FORWARD DROP
With the installer prompt "Block anything that doesnt go thru VPN?"
If yes, plop that rule in.
This means if WLAN0 tries to send packet to WLAN1 directly as a FORWRD it gets blocked immediately.
local net traffic is unaffected.
Only WLAN0 -> (whatever tunnel wg0, tun0, etc) -> WLAN1 will flow (as well as local traffic)
I have an external iptables ruleset that i've tested this on.
Im betting most users are unaware that if the vpn tunnel goes down traffic still goes thru - and im guessing thats a very undesirable configuration.
I think the files impacted are:
installers/configauth.sh
installers/uninstall.sh
config/iptables_rules.json
A nice to have would be a switch in admin panel to be able to turn this on or off and maybe a monitor on dashboard that displays a warning if the switch is on and the tunnel isnt passing traffic for easier diagnostics to non-technical users.
Steps to reproduce
install with openvpn
install openvpn provider and bring up openvpn interface.
install iptraf and open a seperate window with iptraf watching general interfaces
disable openvpn
Traffic still flows.
Screenshots
No response
Additional context
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: