Showing results for 
Search instead for 
Did you mean: 

Rogers Ignite Portforwarding not Working

I've been around

Hi, I'm trying to open a couple of ports on my router for my PC for gaming. I tried open the ports on the app  through the phone, it says the ports were opened, but when I check if the ports are open via 'telnet' command in cmd, they say it's closed, futhermore they don't work for the game. My modem is CGM4140COM. I tried contacting support but they said it's out of range of their scope of support. What can I do to fix this?


**Labels Added**




Re: Rogers Ignite Portforwarding not Working


Hello @shrekitnam, and thank you for posting your inquiry in the community!


I'll tag in some of our Resident Experts in hopes that they'll be able to help you troubleshoot this issue further. 🙂


@-G- , @Datalink , @Gdkitty 







Re: Rogers Ignite Portforwarding not Working

@RogersYasmine wrote:

Hello @shrekitnam, and thank you for posting your inquiry in the community!


I'll tag in some of our Resident Experts in hopes that they'll be able to help you troubleshoot this issue further. 🙂

This is not something that I can test at the moment; my Ignite Gateway is in Bridge Mode and I run on my own network gear.


Port Forwarding can be flakey with the Ignite Gateways.  The good news is that your were able to set up the port forwarding in the app.  Often, the first hurdle is getting the Gateway to see the device as connected and online.  If the device is currently up and running, the port forward is set up in the gateway but the device itself does not show up in the list of connected devices in HomeConnect, the gateway will not forward traffic to the device.


(Port forwarding only works with IPv4.  The Ignite Gateway supports both IPv4 and IPv6.  Most modern devices also support both IPv4 and IPv6, and they typically (and correctly) prefer IPv6, but this behaviour can also cause them to appear to be offline in the HomeConnect app.)


FYI, hairpinning / NAT loopback is also kinda broken, so you may have trouble testing the port forward (using the public IPv4 address) from within your home network.


Another thing to confirm is that you can connect to those ports on your PC from another device on your in-home network, and that connections to those port are not being blocked by a firewall running on your PC.


If the port forward is configured on your gateway, the device shows as online in HomeConnect, and the device itself can accept incoming connections, then port forwarding to that device should work.


One more thing: if you have Advanced Security enabled, this can also cause issues with Port Forwarding; Advanced Security will block port forwarding if it considers the incoming connection to be a threat.

Re: Rogers Ignite Portforwarding not Working

I've been around

Don't understand why Rogers as made this so difficult. So I need forward port 32400 for a PLEX server.

First, I assigned the reserved IP for the device named "DESKTOP" to I confirmed through ipconfig, plex and the connected devices on the rogers app that it is in fact .200 and it is set to "Reserved IP".

Next I go into the app and go to port forwarding. I select "DESKTOP" from the drop down menu, choose manual port and enter 32400. The problem is after I click save and check the port forward list, it says the reserved IP is Where did .39 come from?

Port 32400 from .200 machine continues to be closed.

I know I know, bridge mode and use my own router. If I have to go down the road I will, but this should be a fairly simple procedure.

Re: Rogers Ignite Portforwarding not Working

Resident Expert
Resident Expert

@adblink wrote:

Next I go into the app and go to port forwarding. I select "DESKTOP" from the drop down menu, choose manual port and enter 32400. The problem is after I click save and check the port forward list, it says the reserved IP is Where did .39 come from?

I have no idea why this happens, but you are not the first (or only) person to see something like this:


I don't know what to say but with the Ignite Gateways, there are a number of bugs related to device management and port forwarding. I don't know where things stand in terms of a fix from Comcast or of any workarounds.

Re: Rogers Ignite Portforwarding not Working

I've been here awhile

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 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 (from the default

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 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 (in my case 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 ( 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.


Re: Rogers Ignite Portforwarding not Working

Update: Just checked to see if port forwarding was working...and it is but oddly, the IP address now for my server (connected device) is in the Home Connect app but is still the correct server IP of in the web console ( in my case).  So I guess the Home Connect app is flakier than first expected - almost like the change when initially done and recognized in the router (via the command console) did update the Home Connect app but for some reason a while later it reverted back to what the old setting was.  Port forwarding is still working so it tells me that there is a viable network path and I'm just going to ignore what the Home Connect app shows.   This just gets better and better!!!

Re: Rogers Ignite Portforwarding not Working

If I go to 'what's my ip' and try to ping that it just times out.  The reason I'm trying this is because I have set up a couple of port forwarding entries on my router & everything external just times out & when I run a port open check it states they are closed.  

For trouble shooting purposes I've turned off the firewall on the modem & router, enabled the pinging & it's still just a  black box.


Is anyone else able to do this or is this another add-on or something that  has to be setup on rogers side?


Thanks for reading.


Re: Rogers Ignite Portforwarding not Working

I've been here awhile
Ended up solving the problem by putting the modem into bridge mode.

Re: Rogers Ignite Portforwarding not Working

I've been around

Unable to port forward - nmap reports "admin-prohibited":


So I'm running into a strange issue with port forwarding.  My port forwarding setup had worked flawlessly over the years until yesterday (Oct 8th, 2023).


I have the white rogers mode - Technicolor CGM4331COM.  It's running in bridge mode.  I use EERO 6E router in the back to do port forwarding. 


I have a home automation system setup at home that uses Home Assistant UI.  So I had been forwarding port 443 to get to my HA setup whenever I need to access it from outside my LAN.


I can't access this since yesterday.  So I have run lots of tests and all points to "something" (Rogers?) blocking all inbound ports.


To simplify the entire troubleshooting exercise, I unhooked my EERO router and plugged my desktop directly into the modem (which is still in bridge mode).  All outbound internet traffic worked well.  I ran a simple web server on my computer using python:


python -m http.server 9000


Yes, I'm 100% sure there is no firewall on my computer as I disabled everything (its Mac).  I tried hitting my public facing IP address using my phone (which isn't on the LAN.. it's using LTE connection).  And I couldn't reach port 9000.  I even tried port 80 among other ports.


Then I ran nmap from an external machine (a Linux VM on cloud).  I wanted to see what the heck is going on with packets.  Nmap reported "admin-prohibited" under response.  It sounds like something or someone is explicitly blocking all traffic.


nmap -d -sS -PN -n -p9000 MY.WAN.IP.ADDRESS
Overall sending rates: 9.11 packets / s, 400.76 bytes / s.
Nmap scan report for MY.WAN.IP.ADDRESS
Host is up, received user-set (0.074s latency).
Scanned at 2023-10-10 02:15:36 UTC for 0s
9000/tcp filtered cslistener admin-prohibited


It's the same result no matter which port I try.  Is anyone else running into this?  I called Rogers tech support and they basically denied filtering any ports where as I can clearly see something is blocking traffic.





Re: Rogers Ignite Portforwarding not Working

I've been here awhile

I can confirm that I am in bridge mode with my own firewall (Sophos) behind the Rogers modem and inbound traffic is not reaching my firewall. I did the same tests as you with nmap and I did not get "admin-prohibited" but I did receive "no-response". I was watching a tcpdump on the firewall and no traffic was received.

Re: Rogers Ignite Portforwarding not Working

I've been around

I had a very similar thing happen to me.  Port forwards that had been working for years suddenly stopped.   I just figured out a fix.   First, I shut off the firewall (Gateway > Firewall > IPv4 - from minimum to custom - disable entire firewall).    All but one of my port forwards started working.   The one that wasn't I deleted and re-added, then it was fine.   Then I re-enabled the firewall (returned to minimum).    All good now. 


Hope this might help someone.

Topic Stats
  • 11 replies
  • 9 in conversation