-
Notifications
You must be signed in to change notification settings - Fork 16
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
[FEATURE] Adding suggested ApprovedIP when adding peer #145
[FEATURE] Adding suggested ApprovedIP when adding peer #145
Conversation
@theonemcdonald, think this PR is ready to review. Any suggestions on consolidated / centralised methods for all CIDR / subnet validating, enumerating (subnet IP, broadcast IP, etc)? I've written out some "hacky" methods to achieve it but feel there must be better methods built into pfSense (I've tried looking but couldn't see any). |
@theonemcdonald Is the refactor ongoing regarding this repo? I'm failing to build main branch now due the function Couldn't find it anywhere in the main branch. |
@GenericStudent Sorry about that, yeah that was an oversight on my part. You should be able to build now. |
No worries, thanks for the quick resolve. |
…he next IP or a new peer
…erface address is found
…rate addresses, not interface assigned
3f7641d
to
e885b64
Compare
Please note I've refactored this codebase to use one of the composer added libraries, it sits on the branch feature/peer-endpoint-suggestion-using-composer however I'm unsure how to get the |
This PR should resolve RM ticket 11588.
It adds a new setting option
Suggest Next Approved IP
.If the above setting is enabled, when a user creates a new peer (for an existing tunnel atm, need to look at breaking out to JS so we can pick it up when the user navigates to Add New Peer page without pre-selecting a tunnel) it will work out what the next available IP address is.
It does this by working out the subnet value, broadcast value, and any existing peers. Once we have these values we can iterate from the subnet + 1 up until broadcast - 1, the first available IP address is "taken".
So we have the following examples of expected behaviour:
Tunnel's assigned interface has static IPv4 address of
192.168.100.1
with cidr range of/24
192.168.100.2, 192.168.100.3, 192.168.100.4, 192.168.100.6, 192.168.100.7
192.168.100.5/32
given it's available. Doing this a second time (if we create.100.5
) will result in the IP address192.168.100.8/32
being suggestedTunnel's WG specified IP address of
192.168.150.254/24
192.168.150.1/32
In this PR I'm iterating from subnet to broadcast as we can't assume the interface address is always lowest (
.1/24
for example) as it could also be highest (.254/24
for example).This is currently a work in progress and should not be deployed.