Skip to content
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

[Net] Firewall IP Forwarding rules entered in the Web UI lost on reboot #1195

Closed
cdealti opened this issue Mar 14, 2017 · 2 comments · Fixed by #3334
Closed

[Net] Firewall IP Forwarding rules entered in the Web UI lost on reboot #1195

cdealti opened this issue Mar 14, 2017 · 2 comments · Fixed by #3334
Assignees

Comments

@cdealti
Copy link
Contributor

cdealti commented Mar 14, 2017

Affects Kura 2.0.2. Not checked against Kura 2.1.0.

The use case is configure IP forwarding between wlan0 and ppp0 but without NAT.
This can be achieved by setting IP Forwarding rules in the Web UI.

When you save the IP Forwarding rules, they are correctly saved in the snapshot and in the firewall configuration file /etc/sysconfig/iptables. They are also correctly listed with iptables --list.
The above network configuration works nicely.

Then two things happen:

  1. In the Web UI if you click outside the IP Forwarding tab and you go back to it, the rules are no longer there.

  2. If you change the network configuration, the /etc/sysconfig/iptables and the snapshot are rewritten and the IP forwarding rules are deleted. The above network configuration stops working.

As a workaround we added the IP forwarding rules to the firewall custom script which triggered another bug fixed by #1194.

There is another issue, difficult to describe:
If you use the firewall custom script, /etc/init.d/firewall_cust, on the next configuration change, the custom rules are saved also /etc/sysconfig/iptables.
If you change the configuration again the custom rules are removed from /etc/sysconfig/iptables.
So, if the custom rules are not present in /etc/sysconfig/iptables, they are added. If they are present then they are removed.
This is weird but it does not cause any troubles

@cdealti cdealti added this to the KURA-3.0.0 milestone Mar 14, 2017
@MMaiero MMaiero modified the milestones: KURA-4.0.0, KURA-3.0.0 Apr 27, 2017
@cdealti cdealti removed this from the KURA-4.0.0 milestone Jun 9, 2017
@cdealti cdealti added this to the Sprint 22 milestone Nov 13, 2017
@cdealti cdealti removed the bug label Nov 13, 2017
@markoer
Copy link
Contributor

markoer commented Nov 21, 2017

I can confirm that the behavior is similar in 3.2.0-SNAPSHOT on RPi3. And it happens both if NAT is enabled on wlan0 and if it is not.

Note that the initial forwarding rule from wlan0 to eth0 that is set up in /etc/sysconfig/iptables is not set up in snapshot 0 and is not visible in Firewall->IP Forwarding/Masquerading tab.

I can proceed to adding an additional rule that forwards from eth0 to wlan0 (ppp0 is not available). The change is visible in the new snapshot, in /etc/sysconfig/iptables and in output of iptables -L -n -v. Now for the part where the behaviors differ: I can leave the firewall page and return and the rule will still be visible. When I reload the page the rule changes a bit - source and destination networks are now displayed (0.0.0.0/0). If I restart Kura, the rule disappears from the table, but it's still in the snapshot and file and is applied on the gateway.

Change of eth0 from Using DHCP to Manually will remove the rule from the file and the system.

As far as the custom script is concerned, the observed behavior is this:

  • /etc/sysconfig/iptables will be updated with its rule (only one used in the test)
  • its rule is not initially displayed in Kura
  • its rule is not initially in the snapshot

When Kura is restarted, the custom rule shows up in web UI. When configuration is updated, the rule is added to the new snapshot and applied on the system one more time. It is now also present twice in the file.

@MMaiero
Copy link
Contributor

MMaiero commented Jan 18, 2018

@ibinshtok Can you take a look at this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants