[SOLVED] Why does opkg update require WAN OUTPUT to be ACCEPT, but log server on port 514 does not require it?

My openwrt router is configured to send logs to a server on the LAN side. Updates must go out on the WAN side, of course.

I find I must leave the WAN OUTPUT to ACCEPT for opkg update to work. Yet, I do not seem to need to leave LAN OUTPUT to ACCEPT to send logs to the local log server.

Also, why is it OUTPUT that is required to be open, rather than INPUT?

If you do a search on "input output forward" or similar, you'll probably find some more in-depth discussion of the operation of the firewall. But fundamentally, output controls the ability for traffic to flow out of the firewall zone and thus out of the related interfaces. In the case you describe, setting output to drop or reject means that traffic cannot flow out of the wan interface at all (although this could be coupled with additional firewall rules to permit traffic to egress provided that it is explicitly defined in those firewall rules, all else would be blocked).

The other part of the equation is that the opkg requests are obviously initiated from OpenWrt (as an OS)... so for this, you have to remember that the firewall sits between OpenWrt (as a host OS) and networks to which it is connected, even though the firewall is running on OpenWrt. opkg (or even ping or other applications/services running on the router) initiates traffic, but that traffic is sent through the firewall before it goes out to the network(s). Thus, if traffic is not allowed out of the firewall on a given zone (output), no connections can be made on that zone.

Input, on the other hand, is traffic initiated from outside the router/firewall that is destined for the router itself. For example, when you connect with ssh or a web browser to your router, that traffic is being initiated from a host on the LAN that is intended for the router itself. If input is dropped or rejected, it would not be possible to connect to the router (except if coupled with other firewall rules to explicitly allow certain traffic). On the WAN zone (or any similarly untrusted networks/zones), input should always be dropped or rejected.

1 Like

Look so nice description we have for you to read :slight_smile:


OpenWrt reloads its firewall to apply changes without restarting it, so already established connections are recognized by the connection tracking module and may not be affected by the prohibitive policy.
You need to explicitly restart the router/firewall to reset connection tracking and enforce the policy, unless this is a RAW socket connection.

1 Like

Maybe I should clarify my inquiry.

I've been assuming that all packets/traffic that journey through the openwrt router must go through the firewall--are there exceptions?

If there are no exceptions to this rule, then how are packets able to go from the router, out to port 514 on the log server on the LAN? I have OUTPUT set to DENY. I am still getting logs from the router after OUTPUT has been blocked.

Did you restart the firewall service (vs reload) after you made the change? See @vgaetera's comment above

1 Like

I have rebooted said router several times.

Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have

ubus call system board; \
uci export network; uci export system;  uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru

Mea culpa, as you said. I had gotten my LAN and MNG mixed up for some reason. It works as advertised.

Sorry to bother you with my oversight.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

That's a good point, vgaetera, and I will keep that in mind in the future. But the whole problem was that I got myself confused between what I was doing with the LAN and MNG subnets. It had nothing to do with openwrt at all; more of a problem upstairs here. As I said in my solution post, it was entirely my own fault for not stepping back and considering what I was doing with each subnet--same problem as my previous topic concerning isolating the management subnet https://forum.openwrt.org/t/solved-lost-https-web-ui-access-edited/112827/6

Thanks for your help.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.