Bug 11695

Summary:	Adding/editing rules with preset broken
Product:	IPFire	Reporter:	erikvl <erik>
Component:	---	Assignee:	Stefan Schantl <stefan.schantl>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	Minor Usability
Priority:	- Unknown -	CC:	erik, michael.tremer, peter.mueller, stefan.schantl
Version:	2
Hardware:	unspecified
OS:	Unspecified
See Also:	https://bugzilla.ipfire.org/show_bug.cgi?id=11413
Bug Depends on:
Bug Blocks:	12278

Description erikvl 2018-04-09 14:26:04 UTC

Try adding a firewall rule with destination NAT (port forwarding). You will need to set the protocol, which can be selected from a drop down list. Select preset and you will be asked to select a service or service group.

Now select SMTP and save the rule. Note that the external port is set to 25 and the destination port to SMTP.

Next edit the rule, change SMTP to HTTP and save. Note that the external port is still set to 25, but the destination port changed to HTTP.

Obviously, at least the external port should have been changed too.

But this appears to be a symptom of the fact that you cannot independently set either port, nor the source port, when selecting preset.

I would expect that choosing destination NAT would enable 3 fields for which you could select a preset or manually enter a port number independently.

I did not check source NAT. Maybe that has the same defect.

Comment 1 Alexander Marx 2018-05-24 12:48:13 UTC

Well The Presets affect only the destination port.
Sense of DNAT is to be flexible with source and destination ports.

If we would change this, you wont be able to set the source port to another Value than the given preset. 

I dont think this is a bug.

other opinions?

Comment 2 erikvl 2018-05-24 13:02:58 UTC

You can't change(In reply to Alexander Marx from comment #1)
> Well The Presets affect only the destination port.

No, they don't. They also affect the external port in the resulting rule.

> Sense of DNAT is to be flexible with source and destination ports.

Indeed. With a preset you are not.

> 
> If we would change this, you wont be able to set the source port to another
> Value than the given preset. 

Right now, you can't set the source/external port when using a preset.

> 
> I dont think this is a bug.

When one sets the preset to SMTP, the resulting rule translates external port 25 to internal port 25, as expected. When one changes the preset to HTTP, the resulting rule translates external port 25 to internal port 80. That is clearly not as expected. I would call that a bug.

Comment 3 Michael Tremer 2018-05-24 13:06:41 UTC

When using the preset the first time, the external port setting should be left
empty. Port 25 will be forwarded to port 25 then which is what people want in
this case.

Then it should not be a problem any more when the service is being changed to
something else. External port should still be empty then.

Alex, this is a bug.

Comment 4 Alexander Marx 2018-05-24 14:27:06 UTC

please test this patch

https://patchwork.ipfire.org/patch/1783/

Comment 5 Peter Müller 2019-10-13 10:20:10 UTC

Has this patch every made it into the repository?

If yes, please mention it. If no, do not set this to ON_QA or MODIFIED.

Comment 6 Michael Tremer 2019-10-13 13:19:28 UTC

No, I posted a question which was never answered.

Comment 7 Stefan Schantl 2021-07-14 10:19:09 UTC

I've tried to reproduce this issue on a Core 157 and Core 158 system by creating a DNAT rule with a preset (DNS).

After saving the rule the config and iptables rule contained the correct port (53). After editing this rule and switching to HTTPS and saving, the config file and iptables rule showed the corrent port (443).

So I'm unable to reproduce this issue anymore.

Any suggestions, otherwise I'm going to close this bug.