Outbound UDP on Port 5050 Is Not Working

How have you tested this?

How have you eliminated that the problem is at the other end?

How have you eliminated the chance that the problem in in your network?

What have you tried to correct this?  Factory resetting your gateway?

Hi @JefferMC - thank you, pls see my replies on each question you asked, over the next few comments:

@JefferMC This chat is not accepting more than tiny posts from me; please see your questions answered here: https://www.reddit.com/r/ATTFiber/comments/1b7bmgr/comment/kthu1bg/?utm_source=share&utm_medium=web2x&context=3

Okay, working with what I see there:

1) You have your own router, which needs to be eliminated as a possible source of the issue, if possible. I see that you connected your system directly to the BGW320 via Wi-Fi and attempted your nc command, which failed.  This does seem to eliminate your own router.  I assume that you know that the nc command failed because no data arrived at the server?

2) FTR, Port Forwarding rules should only affect incoming traffic.  If the direction of the connection is outgoing, then there is no need to open a pinhole for that traffic.  NAT gateways keep a state table for open TCP connections to allow the return traffic, and keep them open for a period of time for connectionless UDP traffic, in the event you're trying to allow return traffic on the same port.

3) FTR, IP Passthrough is not needed to allow outgoing traffic under the same reasons as above.  However, if you have your own router, then you should have the Gateway in IP Passthrough mode to your router.  Note that if you have IP Passthrough mode on your Gateway, you should not be setting up Port Forwarding/Pinholes on the Gateway for any device located behind the router; the router is the correct place for that.

4) You tested the remote end by using a terminal on the same device.  That does not exercise anything outside that server's internal processes, including any firewall rules that deal with external traffic or any security processing in their network otherwise.  That the "cloud server provider" verifies it's open does not give me any warm fuzzies about what and how they tested.  Ideally it would help if you had a third computer somewhere on a distant network where you could test this, either as a separate receiver from your network or a separate sender to the remote network (or really, ideally, both). 

I currently don't have a second connection here, or the wherewithal to open up servers on arbitrary ports on any remote environments so that I can verify that UDP (or TCP) 5050 flows out of my connection.

Hi @JefferMC - Problem solved; it was an invalid test at my remote end that was giving a false negative.  Details here: https://www.reddit.com/r/ATTFiber/comments/1b7bmgr/comment/ktoe44m/?utm_source=share&utm_medium=web2x&context=3 

Thank you!

I suspected something like that. Thanks for letting us know how it worked out.