RaspAP
[Feature request]: iptables rules
Code of Conduct
- [X] I agree to follow this project's Code of Conduct.
Issue reporting checklist
- [X] I have read and understand the issue reporting policy.
- [X] I observed this bug on a clean install of a supported OS.
- [X] I have followed the project prerequisites.
- [X] I have searched this repository for existing issues.
- [X] I checked the FAQ and official documentation.
- [X] I am using an external wireless adapter.
- [X] I have generated a RaspAP debug log and performed a self-diagnosis.
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)
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
Complete change: iptables -P FORWARD DROP iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -o tun+ -j ACCEPT iptables -A FORWARD -i wg+ -j ACCEPT iptables -A FORWARD -o wg+ -j ACCEPT
All other rules work - but if openvpn goes down or wg goes down, this will block any traffic attempting to bypass tunnel. Tested and confirmed.
wireguard doesnt perform well for my use case as crazy as it sounds. Only openvpn with tcp - im on a slow, distant link.
Heres my final form of iptables kill switch. Its tested - if openvpn abends nothing passes. Current config for raspap would allow traffic to pass if openvpn abends, revealing sensitive geoip information.
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# #Tested on OPENVPN#
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 rules
iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT
Flush All Iptables Chains/Firewall rules
iptables -F
Delete all Iptables Chains
iptables -X
Flush all counters too
iptables -Z
Flush and delete all nat and mangle
iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -t raw -F iptables -t raw -X
**** Now apply tight firewall rules
RASPAP relies on Masquerading - which means forwarding.
Do not allow any forwarded packet that doesnt travel thru a wg+ or tun+ interface
lo traffic very ok
iptables -A INPUT -i lo -j ACCEPT
#All local lan traffic ok - assumes 192.168.1.1 to 192.168.255.255 iptables -A INPUT -s 192.168.0.0/16 -j ACCEPT
#Emergency override - put your mac address here iptables -A INPUT -m mac --mac-source MACADDRESS -j ACCEPT
#Do not allow tun to tun packets - this is a probing attack iptables -A FORWARD -i tun+ -o +tun+ -j DROP
#Do not allow anything from TUN to hit local network - this is a probing attack iptables -A FORWARD -s 192.168.0.0/16 -i tun+ -j DROP
#Very ok - tun to wlan - this is what we want iptables -A FORWARD -i tun+ -o wlan+ -j ACCEPT
#Very ok wlan to tun iptables -A FORWARD -i wlan+ -o tun+ -j ACCEPT
#very ok eth to tun iptables -A FORWARD -i eth+ -o tun+ -j ACCEPT
#Very ok tun to eth iptables -A FORWARD -i tun+ -o eth+ -j ACCEPT
#very ok - any established connection from tun to wlan iptables -A FORWARD -i tun0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#very ok all output packets iptables -A OUTPUT -j ACCEPT
#NAT rules (forwarding) iptables -A POSTROUTING -j MASQUERADE iptables -A POSTROUTING -o tun0 -j MASQUERADE
#iptables are cumulative - final rule - drop every forwarded packet that doesnt meet any rule above iptables -P FORWARD DROP
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 https://github.com/RaspAP/raspap-webgui/pull/1640/commits/62978a7755bdba4250d20381c569cdbbea468772