[SOLVED] How do we manually modify firewall rules?

Started by interfaSys, January 25, 2016, 11:33:29 AM

Previous topic - Next topic
January 25, 2016, 11:33:29 AM Last Edit: January 27, 2016, 01:57:56 PM by franco
Due to a bug in the GUI, I can't modify a linked rule (for squid), so how do I modify it from the console? I couldn't find a pf.conf, so I'm assuming rules are stored elsewhere.

Hi,

I'm not an expert here but it seems that the firewall rules and all the configuration stuff are stored in /conf/config.xml

I couldn't find a pf.conf either.

Well ... makes sense for easier exporting and importing the configuration for backups etc. :-)

Regards

If there is a bug it should be fixed. Which bug are you referring to?

Quote from: franco on January 25, 2016, 02:02:30 PM
If there is a bug it should be fixed. Which bug are you referring to?
Of course, but it may take 6 months to land if it's targeting 16.7 per example, so I was wondering if there was a manual alternative which didn't involve taking the risk of breaking the whole config.

The bug I'm referring to: https://github.com/opnsense/core/issues/695

I am unsure where you get "6 months to land" given our history of speedy bug fixes. I find the notion a tad dramatic and maybe also a bit offensive.

We're in the middle of finishing up a major release that is due tomorrow, which takes consideration, moderation of issues and focus to not end of with thousands of trashed installations right after release.

There has never been a guarantee for fixes (or timeframes for said fixes) within this project, except through proper support channels. Anything that lands in the forum or the bug tracker is a best-effort scenario. The fact that it doesn't seem to work for you now doesn't mean that this won't work out pretty well in general.

Please be kind.

I apologise if I offended you. I was referring to the milestone cycle. 16.7 is due in 6 months isn't it? And it's perfectly normal to assign enhancements and bug fixes to the next milestone, which means people on the stable branch will have to wait to get some of the changes.
I wasn't implying that you weren't quick enough or that we deserved free priority support. It's just the nature of software development.

Thank you. 16.7 means "on our way to 16.7". We try all changes in the development version and backport them as soon as we can. This usually takes a stable release or two (one or two weeks). Only incompatible changes like the captive portal rewrite or FreeBSD 10.2 take 6 months to materialise.

The issue has been fixed. The entries ended up in the normal rules screen, but are actually NAT rules and you can edit them there. Doesn't work for gateways. In a normal setup the default gateway (group) policy will pick up the NAT rules as well. If not, a manual gateway rule needs to be added.

Quote from: franco on January 27, 2016, 01:57:47 PM
Doesn't work for gateways. In a normal setup the default gateway (group) policy will pick up the NAT rules as well. If not, a manual gateway rule needs to be added.
So instead of using that NAT port forwarding rule, I should manually create a rule in the VLAN to proxy all traffic intended for a specific gateway then? I guess it would look like the rule which currently leaks.

I'm getting confused. The default gateway should probably be used so that traffic reaches the Proxy instead of being sent to a WAN interface, but then how does the proxy know which interface to use to send traffic?

The port forwarding rule is saying:
LAN to !LAN on 80, send to proxy

The LAN rule says:
LAN to proxy, use default gateway

But I don't see any rules for the proxy and since no interface is given in the LAN rule, the proxy has no way of knowing where to forward the request and prolly just uses the default gateway, which isn't what we want.

Are there any good examples out there?

Quote from: interfaSys on January 27, 2016, 02:38:09 PM
The LAN rule says:
LAN to proxy, use default gateway

No, gateway is for outbound traffic, not traffic redirected to the proxy. If you use this rule worst case the traffic is moved away from the box and never reaches your proxy, if it hits at all, because this is only true after redirection (traversing the NAT rule first) or when you manually configure hosts to access the proxy port (no redirection).