Suddenly can't connect to Internet on 360

Just to rule out the possibilty of the HDD being the culprit, could you have your console powered off, and safely remove the HDD from your console. Insert a USB flash drive (configured
for use with the Xbox 360) to a USB port on front of your console.

Turn on your console (with HDD removed) and apply the system update to USB drive, and let me know if this behavior can be reproduced.

If this appears to be an issue between the Xbox 360 and linux's miniupnpd (IGD, NAT-PMP) version 1.8.1, try a more recent version of miniUPnPd for Linux.

Keep us posted!

 

Weird result. When I pulled the HDD, the Xbox couldn't even connect to download the update. Deleting update data from the USB & flash storage did nothing, the 360 wouldn't connect period.

Reinserted the HDD and found that it didn't help at all. My 360 still wouldn't connect with uPnP active, even after deleting the update data (which had worked before). I had to disable uPnP and get the Xbox 360 to connect / download the update under strict
NAT and then re-enable uPnP afterwards.

Since doing that, deleting the update data has started working again to get myself reconnected.

It isn't really feesible for me to update to a later version of miniupnpd. 1.8.1 is the most recent version released for IP Fire through their release channel.

 

Just to clarify, the USB drive is FAT32 formatted?

What about if you could try to reinstall your version of miniupnp?

 

The drive is FAT32 formatted. This is a slim 360, so it also has a 4GB internal flash drive that I can't remove, but I tried removing update data from that as well, no luck.

Tried reinstalling miniupnp and flushed it's IP Table. When I try to connect, I see uPnP add an IP Table entry for UDP port 3074 pointing to my 360, but nothing else. Checking it a day later showed entries renewed for my nVidia Shield, so I know uPnP is
working correctly.

I should point out that an IP Table entry shouldn't even be necessary to connect to Live. It is only necessary for gamers to connect to me during gaming sessions. My firewall is not configured to drop any outgoing connections. In fact, if I disable uPnP,
the 360 works fine even without any port forwarding set up. The connection tests passes, it just gives me a warning about strict NAT. When I enable uPnP, it fails altogether at the internet step or (occasionally) the Xbox Live step.

 

And both your playstations are being diagnosed with an Endpoint-Indepedent mapping, or NAT type 1?

And you don't have any manually forwarding port rules applied for port 3074 (TCP, UDP) and port 88 (UDP)?

 

Both PS3's, the PS4, and my Vita report NAT type 2 (i.e. Moderate), which is the correct NAT type. Type 1 is a direct internet connection with "NO NAT", which would mean me connecting my console directly to the internet or doing a DMZ host type scenario,
which could only be done for one console, forcing all the others to NAT type 3 (i.e. strict, No port forwarding).

Interesting caveat, the PS3 downstairs is reporting uPnP as disabled but still reporting NAT type 2. That seems odd, the other PS3 reports it as enabled. The one reporting it as disabled is connected wirelessly, the other is wired but both are connecting
to the R7000, same as the 360.

 

Oh I see! They (Playstation/Sony) use a different analogy then Xbox/Microsoft, regarding the wording of different NAT types (MS: Open, Moderate, Strict).

It must have something to do with miniupnpd suite that you've installed.

Do you have Port Forwarding (manually) disabled?

Is this the current version of miniupnpd you're using, 1.8.20130730-2?

Have you tried asking in the,
http://forum.ipfire.org/ or
miniupnp.tuxfamily.org/forum to see if this require some fine tuning, to have it work seamlessly?

Please, keep me updated and let me know what you find out.

 

The version I'm using is labeled miniupnpd-1.8-1. There is no way that I'm aware of to install anything but that version. There is nothing to configure when it comes to upnp. I have only the option of starting or stopping it as a service. Through the
command line, I can manually flush the ip table entries made under upnp, but I've already tried that. There's really nothing else to try, especially since it seems to be working properly in any other manner I can use to test it.

I do not have port forwarding "disabled". I can manually port forward if I like, and the 360 will connect under moderate NAT just fine as long as uPnP is disabled. If uPnP is enabled, the 360 still will not connect, even if I have the ports manually forwarded.
If uPnP is disabled and the ports are NOT forwarded, the 360 STILL connects, as I said it SHOULD, it just does so with strict NAT.

IOW, no matter what I do, if uPnP is enabled, the 360 won't connect AT ALL (aside from using trickery on the 360)

With uPnP disabled, the 360 WILL connect and manual port forwarding will determine whether it detects strict vs moderate NAT. However, I do not wish to do this as there are about half a dozen different devices I have that rely on uPnP to function properly,
so disabling uPnP isn't a long term solution.

 

If you could confirm, that you currently don't have any entries for your console's ports that you've manually forwarded, and that your console's network settings are set to obtain IP settings from the DHCP server (automatic).

 

Yes... this feels like we're going around in circles rather than forward.

If DHCP wasn't enabled, or was disabled but had incorrect manual settings, the 360 wouldn't connect at all no matter what I did. In fact, it wouldn't make it past the "Network" step of diagnosis.

I've already explained that I tried all manner and combination of manual port forwarding / no manual port forwarding / upnp and detailed the results in previous posts.

Even if I had both manual port forwarding AND upnp enabled, it shouldn't matter because it would just result in duplicate IP Table entries that would both be correct and the firewall would simply use the first one it found on the list.

 

What's the reason why you can't run your Netgear router as NAT and UPnP, instead of your IP Fire device, and have it setup as the firewall/IPS/IDS without doing IP translation?

I'm not referring to the DHCP server itself, being turned on, or off, I'm strictly referring to your console's IP settings, being set to Automatic, and not Manual (static). I hope you understand that static IP settings on a client shouldn't involve the DHCP
server, or its pool of addresses at all.

You shouldn't use Port Forwarding and UPnP at the same time, as UPnP (IGD) tend to overwrite static NAT.

 

The Netgear is in a central location on the top floor and doubles as a switch for the entertainment system I have in the living room. The IP Fire is located in the utility room downstairs where it is surrounded by concrete and metal ducts/pipes (bad for
WiFi) and serves gigabit ethernet for the entire house.

If I ran NAT through my Netgear, it would kill internet access for everything in my house except the entertainment center and wireless devices. That's not acceptable.

I'm familiar with DHCP vs Static. As I said in the previous post, if these settings were incorrect on my 360, it would NEVER connect. It wouldn't even make it far enough on the connection test to fail where it is failing, period, let alone connect and
work fine with me disabling uPnP or doing magic tricks with the system update file.

I already explained why port forwarding and uPnP simultaneously wouldn't matter... why port forwarding in GENERAL doesn't matter. These are things that are only necessary for INCOMING CONNECTIONS. None of it would cause the 360's OUTGOING connection to
fail... period... I can disable uPnP and have ZERO ports forwarded and the 360 will connect just fine, it just wreaks havoc for the rest of my devices that need uPnP to function (i.e. nVidia Shield, PS4 remote play, etc).

 

Ah, ok, that put things in a different perspective.

So, there is no feature to telnet, or SSH, to bring up a CLI and see how the miniupnpd.conf file is configured?

I do think it's a bit odd that you're able to connect to Live (part from moderate, or strict NAT), but only without the implementation of miniupnpd. It would be interesting to see what an analyze of the Xbox traffic would show.

Is it possible to downgrade the miniupnpd version to the previous version?

I'm sorry if I confused you with the console's network settings, being set to automatic. I was only referring to these settings, as to be set to automatic. I could simply omit the wording of DHCP being involved in this process.

UPnP's fundemental role rely on DHCP, therefore, it can't do its work properly without DHCP implementation. So, from my perspective, I don't really see the purpose of having Port Forwarding/Virtual Server (static translation) and UPnP running at the same
time.

Have you tried posting in the
miniupnp.tuxfamily.org/forum

 

miniupnpd.conf is setup like this:

port=0

upnp_forward_chain=UPNPFW

upnp_nat_chain=UPNPFW

bitrate_up=1000000

bitrate_down=10000000

secure_mode=yes

system_uptime=yes

notify_interval=60

clean_ruleset_interval=600

serial=12345678

model_number=1

allow 0-65535 0.0.0.0/0 0-65535

Don't know if anything there stands out, as I'm unfamiliar with their options and haven't touched them from their defaults.

Considering that miniupnpd is so WIDELY utilized, I don't see any reason to post on there until I have verified the issue is not just a bad flash on my console. I'd assume they'd have tons of posts if EVERYONE's 360 stopped working on miniupnpd.

 

After following the phone support person's advice and waiting until the December dashboard update, it seems like my 360 can connect again. It did fail 2 connection tests in a row at the internet phase again (6th and 7th tests out of about 10 tests run)
but had 3 successful tests afterwards without any trickery. I'm guessing that the 2 failures could be due to the service alert that is active right now. I'll post back if issues come up again and mark this as resolved later if I don't have any further issues
for a while.