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.
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?
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.
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.
please test this patch https://patchwork.ipfire.org/patch/1783/
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.
No, I posted a question which was never answered.
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.