I too have been struggling with this...had the old Hitron router but had to get the new xfi during our last contract renewal (a week ago).
I finally got port forwarding to work but admittedly it requires a factory reset I only have speculations as to what's going on (no root cause). Here's what I did that finally worked after trying many, many things.
First, my private network (from my Hitron setup) uses 192.168.0.x not 10.0.0.1 as the modem came in with at factory default so my approach was a bit different.
1) Kept my static IP of my server (no config change on the server at all).
2) Factory reset the XB7 (held down the WPS button for about a minute)
3) Waited like 10 minutes for the reset to finish (got email stating it had been reset)
In the Ignite Home Connect app
4) changed my LAN network to use 192.168.0.1 (from the default 10.0.0.1)
5) Looked in the Ignite Home Connect app and saw that my server was listed as under "Devices Not Connected" and waited for it to appear in the list of connected devices.
6) After about 5 minutes my server appeared as a connected device but still had a 10.0.0.206 from all my previous attempts (discussed at bottom).
7) This time waited patiently for the Home Connect app to finally poll the XB7 or be pushed the new static IP form the XB7 (however it works) and after about 5 minutes the IP address got updated for my server to the static IP it had all along.
😎 Went into Connect -> View WiFi equipment -> Advanced settings -> Port forwarding and proceeded to add a port for my device as I had tried so many times previously, but this time it ended up showing the correct IP.
9) Tested the connection to it externally to using my phone cell connection (off WiFi) to ensure it wasn't making a local connection through the XB7 WiFi and it worked.
Note: When I looked on the administration web page http://10.0.0.1 (in my case http://192.168.0.1) my server showed up with a "Host Name" set to it's MAC address and the "DHCP/Reserved IP) as to "Reserved IP". The details showed it had the correct IP but there was no way to edit the host name and I was going to f-with it because it was working (and because I had tried many combinations of setting up the device manually from scratch with a specific host name and setting it to a reserved IP). I'll be playing with this later once I back up my working config in the router.
The rest that follows is some of what I've found and my speculation as to what is going on...I provide it here in case those smarter than me can use it to determine root cause and hopefully find a more elegant way of doing this than a factory reset.
It appears as though there are 4 things that need to happen to have a device get the proper static IP and to set up a successful port forward:
1) The device should be initially set up with the desired IP
2) At some point the device will register with the XB7 (or the XB7 will perform a MAC scan of the network) - not sure what the polling interval is here.
3) At some point the XB7 will call home the the Ignite Home Connect servers to update the information in the database - not sure what the polling interval is here.
4) Create a new port forward rule for the device and if 1, 2, and 3 all complete successfully, the device should show up with the correct IP (which would be the same IP it shows up with when it appears as a connected device in the app).
I had tried many variations of disabling IPv6, rebooting (not factory reset) the modem, rebooting my server, disconnecting my server RJ45 cable hoping it would re-register with a correct IP, multiple times over and it always came back to the same thing...appearing to take a long time (5 - 10 minutes) after I made changes for them to have the server appear as a connected device, only to have an "old" IP.
I think what is going on is that the XB7 and app have been designed to abstract the need for having a destination IP address in a port forward rule (I think this is very silly but it appears to be proven by the fact you cannot set the destination IP address but rather have to select a device). This makes a bit more sense if they assumed most people would just use DHCP for most (all?) devices on their LAN. I didn't mention this above, but I had it working initially when I changed my server to use DHCP...I could actually connect to my server and I'm speculating it is because the request for a DHCP lease triggered an update of the IP address that was just granted to the device and this would in turn be pushed up to the Home Connect database. In my case, my is accessed internally both both Windows and Linux boxes and so it is just easier to set up my server(s) with static IPs rather than using DHCP and DNS.
One of my key issues was the fact that I was expecting it to behave like all other routers I've used in the past...change the setting, save the settings, wait a minute until the save is complete, and voila the settings are active. I was waiting a few minutes with each change and looking for it to be reflected in either the web console (10.0.0.1) or the Home Connect app without success. So I think I was not waiting long enough for the change to "propagate" through the router and up to the Home Connect app server. That would also explain why using DHCP worked as I didn't have to wait nearly as long...because changing the config on the server to use DHCP would have immediately forced a lease request from the router which I believe triggered an update as well in the Home Connect app server whereas using a static IP would not be something that would have to be monitored as often (and trigger an update).
This also lines up with my Linux servers...they are not very active and so I see them fall from the "connected devices" to offline/disconnected. I went back during writing of this and forced traffic (I have a Jellyfin server) but pulling up the main web page, and instantly it appeared in the Home Connect app as "Connected to Gateway" when just before I hit the web page it was in the not connected list. Now port forwarding has been set up and working for that as well.
All of these issues would go away if they just allowed the specification of a destination IP address (for static IPs) and keep the option to use DHCP (and then could still do a match of MAC against current IP to see if their old ip in the database needs update). I get this may appear to make it simpler for people who don't do much port forwarding but I think it's fair to say that most people who are, know, and expect, fundamental functionality (source/dest IPs and port numbers/ranges).
My Googling has shown that a couple years back there was a utility for the ComCast modems that would connect directly to the router to config it rather than relying on Cloud and it would have been nice if they could have still provided both options. I'm also not a big fan of the fact that the external port and internal port will have to be the same...this poses a bit of a security risk as it doesn't allow you to map an internal port (which may be a known listening port for a key service like RDP on 3389) to an arbitrary external port (i.e. 4123). Sure a port scanner will tell you what ports are open and more sophisticated scans can sometimes determine the protocol but it is much easier/quicker to scan a large range of IP address for a known port than it is to scan many thousands of ports for each IP address hoping that the service being targeted is running on it.
Another observation (for those of you who haven't fallen asleep...) don't trust the "Troubleshoot Device" option for a device, or, at least wait a while before trusting the details...I have waited upwards of 5 minutes for a server that I unplugged (that was previously appearing in the connected devices) and still the test showed a successful connection and that all the "services" were available. I would have expected it would have done an immediate connection to the target device but I'm guessing it just relies on the cached database information until it actually goes out and polls the device (or the device reports in) in the future.
