Bug #2941
closedProhibit adding aliases containing FQDNs in static routes
100%
Description
aliases containing FQDNs cannot be used in static routes, need input validation to prevent that config from being used.
Files
Updated by Chris Buechler over 11 years ago
- Subject changed from aliases containing FQDNs are not usable in static routes to Prohibit adding aliases containing FQDNs in static routes
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 8543a5bbe2037c9214f967806f417c7c4ba3b062.
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to New
on system_routing_edit.php, this only works if the first item in the alias list is a hostname. It works correctly on firewall_aliases_edit.php.
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
Applied in changeset 5b431a20dead1128687453407a3b0c603154e773.
Updated by Josh Stompro over 11 years ago
I'm trying to confirm that this is fixed but I'm not having success. May 2nd 2.1 snapshot, well past when the change was made.
I create an alias with a single host FQDN, save it and apply the change. Then I go to the System Static Routes and add a route using that Alias. And the process completes without any trouble, no error is displayed.
I then deleted the route, and I went back to my alias and changed it to a network alias with a FQDN entry. And I could still use it in a static route.
Maybe I'm not testing the correct thing, could someone describe how to trigger this problem.
Here are the alias and static route config entries.
<route> <network>Testing</network> <gateway>Openvpn</gateway> <descr><![CDATA[test]]></descr> </route> <alias> <name>Testing</name> <address>firewall.larl.org</address> <descr><![CDATA[testing]]></descr> <type>network</type> <detail><![CDATA[larl.org]]></detail> </alias>
Updated by Renato Botelho over 11 years ago
Josh,
Are you using a recent snapshot?
Updated by Josh Stompro over 11 years ago
I'm running the May 2nd snapshot, which seems to have the patches listed in this ticket.
Was I testing correctly? Should I have hit the error message with my test?
Thanks
Josh
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to New
still the same as what I noted in an earlier update. It's correct on the alias edit screen, but on system_routes_edit.php it doesn't work.
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
Applied in changeset 0d59cc942f2ee225eccdb375e25f58a6f04fa9c4.
Updated by Renato Botelho over 11 years ago
Applied in changeset fcb1ccaf2d356148057e9a62a376ce3d4229e980.
Updated by Renato Botelho over 11 years ago
Applied in changeset 5e2df7fc1c71c2e876e8eb1f99f7b3c8419ea72c.
Updated by Renato Botelho over 11 years ago
Applied in changeset f0867239c1b15c711ea3c6eefd896c2d2aaefcae.
Updated by Josh Cavalier over 11 years ago
I have tested this with the latest build and it works as intended. I created two aliases, one with a FQDN and one with an IP4 IP. I could add the IP alias but not the FQDN alias. Error message is "The alias (test1) has one or more FQDNs configured and cannot be used to configure a static route."
Updated by Josh Cavalier over 11 years ago
Also, I have replicated the test by Josh Stompro above (changing an existing alias used by a static route from IP to FQDN) and firewall_aliases_edit.php now responds with "This alias is used on a static route and cannot contain FQDNs".
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to Resolved
confirmed fixed
Updated by Rahman Duran over 11 years ago
Hi,
It seems this fix broke using nested aliases for static routing as system_routes_edit.php line 131-138 assumes members of the alias are ipaddr. So please change the status of this bug.
Updated by Renato Botelho over 11 years ago
- Status changed from Resolved to New
Nested aliases are still broken, working on it
Updated by Renato Botelho over 11 years ago
- Status changed from New to Feedback
Applied in changeset 90bc28cc9d75c59efc06a3aa319239bf7aafa259.
Updated by Chris Buechler over 11 years ago
- Status changed from Feedback to Resolved