Bug #4269
closedModifying port forwarding rule to invalid IP kill the firewall until reboot
0%
Description
First, this is using invalid actions, so this is not so critical, but doing so will result in denial of service.
--SETUP--
I start with 3 interfaces + 1 VPN interface.
WAN -> em0 -> 192.168.10.66/24
LAN -> le1 -> 192.168.1.1/24
MGMT -> le0 -> 192.168.20.66/24
VPN -> ovpnc1 -> <VPN interface IP>
So, basic setup with traffic from LAN is NATted to VPN. Everything working fine as initial condition.
--PROBLEM--
If I create a port forwarding rule (So VPN traffic on port 1234 get forwarded), but I select an invalid (user make a mistake) IP address to forward to, and set for example destination as 192.168.0.123 (mistakenly typed instead of 192.168.1.123), and apply, then the rules somehow get trashed and the firewall no longer respond.
Sometime this happen after deleting the above NAT rule.
For example, with initial setup, add port forward rule:
- Interface: VPN
- Destination: VPN address
- Dest port: 1234~1234
- Redirect target IP: 192.168.0.123
- Redirect target port: 1234
- Description: ...
- Filter rule association: Add associated filter rule
- Save, Apply.
If the firewall is still accessible, delete the NAT rule you created.
When the issue occurs, all traffic on the firewall is blocked. Only the console is available. If you disable packet filtering (pfctl -d), the the firewall is reachable, but as soon as filtering is re-enabled, traffic stop. This condition persist until reboot.
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Feedback
it's certainly not possible to kill a system by putting an incorrect IP into a port forward. maybe if you managed to create a traffic loop in the process.
when the traffic stops, check the output of 'pfctl -si' and 'pfctl -ss | more' at the console. Guessing you created it in such a way that traffic is looping endlessly somehow, those would help determine.
Updated by Eric Hoffman almost 10 years ago
Well, indeed, not 'dead', but traffic is stopped.
I did what you suggested and e don't see any loop. However, I see states on WAN and VPN only. So I guess that WAN and VPN are still up (confirmed by doing a ping to the VPN DNS).
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Not a Bug
- Affected Version deleted (
2.2)
haven't gotten info to replicate, and no one else has reported same.
Eric: if you can provide specifics to replicate, please follow up.