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

Firewall Extension does not handle port or protocol changes across change and repair #5869

Open
dyhims opened this Issue Aug 30, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@dyhims
Copy link

dyhims commented Aug 30, 2018

The wix firewall extension does not work correctly across change/repair, and is likely broken in some upgrade scenarios as well. Port and protocol do not update when new values are passed to the custom action. Essentially I have the issue described here: #5675

Bugs

If this issue is a bug:

  • Which version of WiX are you building with?

3.10.3007.0

  • Which version of Visual Studio are you building with (if any)?

VS 2017 15.8.1

  • Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

0.9.21.62588

  • Which version of .NET are you building with?

4.5.2

  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 10 (10.0.17134)

  • Describe the problem and the steps to reproduce it.

If the only change in a firewall exception is the port (for example), it does not update during change or repair. The old port stays open on the system.

Add a firewall exception, to your wix source, e.g.

<Component Id="OpenFirewallPort" Guid="*" KeyPath="yes">
        <fw:FirewallException Id="FwOpenPort"
                              Description="!(loc.FirewallRuleDescription)"
                              Name="InboundOpenException"
                              Port="[MY_PORT]"
                              Scope="any"  />
</Component>
  • Install the product.
  • Then run Change, providing a new value for MY_PORT
  • In the verbose logs, you will see that the new port is passed to the firewall extension when it runs.
MSI (s) (7C:58) [13:48:43:169]: Executing op: CustomActionSchedule(Action=WixExecFirewallExceptionsInstall,ActionType=3073,Source=BinaryData,Target=ExecFirewallExceptions,CustomActionData=3 SmeInboundOpenException 2147483647 * 0 1 6515 6 Windows Admin Center inbound port exception)
----
ExecFirewallExceptions:  Installing firewall exception2 SmeInboundOpenException on port 6515, protocol 6

See the comment on this issue: #5675 (comment). The code only re-enables a disabled rule, it does not perform other updates.

  • Describe the behavior you expected and how it differed from the actual behavior.

Expected: The port is updated to match the supplied number when the action runs.
Actual: The old parameters for port and protocol remain installed.

@barnson barnson changed the title Bug: Wix Firewall Extension does not handle port or protocol changes across change and repair Firewall Extension does not handle port or protocol changes across change and repair Sep 13, 2018

@barnson barnson added this to the v4.x milestone Sep 13, 2018

@chrpai

This comment has been minimized.

Copy link

chrpai commented Dec 6, 2018

Should it? I would think it's the job of the MSI author to implement a remember me property type pattern. I don't expect other Windows Installer tables to automatically remember properties.

@dyhims

This comment has been minimized.

Copy link

dyhims commented Dec 6, 2018

@chrpai This is not about remembering the old property, this is about honoring the values that are passed in when the component is reinstalled (for example).

Under the current implementation, if do a clean install with MY_PORT=443, I get a firewall rule called "MyRule" for tcp/443. If I then run repair with MY_PORT=5000, the component will say that it is installing with the new port value, but the firewall rule will not be changed. Port 443 will still be open, 5000 will be blocked.

In my own project I ended up supporting the behavior we needed entirely through custom actions.

@chrpai

This comment has been minimized.

Copy link

chrpai commented Dec 6, 2018

Ah, thanks for the clarification. Can you put a little more context around this for me? What if you install MY_PORT=443, manually change the port to 442 and then do a repair with MY_PORT=5000. Does it still go back to 443 or does it stay at 442?

@dyhims

This comment has been minimized.

Copy link

dyhims commented Dec 6, 2018

I believe (but haven't executed the code!) that it will keep 442 open.

The underlying problem is that the firewall API only does lookup by the rule name. I appreciate that there are probably backward compatibility concerns with what I'm asking for here. If I understand the code correctly then it seems like nothing will get installed if there is a name collision, even with a clean install.

@Firewire2002

This comment has been minimized.

Copy link

Firewire2002 commented Jan 2, 2019

Scope of firewall rules is also affected.
It occurs also if the rule already exists before MSI package is installed.

For example:
Some one create manually a firewall rule "Rule A" with scope/remote-Adress 127.0.0.2 and install a MSI Package that should create also a firewall rule "Rule A" but with scope/remote-Adress 127.0.0.1. Then the rule will keep 127.0.0.2.
If you rename the existing rule to "Rule B" and start a repair installation of MSI package, than there will be 2 rules:
Rule B - 127.0.0.2
Rule A - 127.0.0.1

So it seems that there is a generally issue with overwriting of existing rules by msi packages. Not sure if this an issue with WiX or with Implementation in Windows.

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