RunUO Port-Forward

[LizzyBELL]

Hello all! I need some help here. I'm using RunUO Version 2.2, Build 7786.854

New to this whole thing. But lets get to topic,

I already Port-Forwarded the decided server host and I got the firewalls done too. I went into ServerList I changed

public static readonly string Address = null;
public static readonly string ServerName = "Test":
public static readonly bool AutoDetect = false;
to false like it said


I can connect to from my home computer, but can't get passed when you select the server... Then I get this error in the console.




I honestly don't really know what to do. Help would be apparated!

 

[Marcel]

You sure your using the right Login Informations?

 

[Kaniva]

I don't think its a router issue cause it looks like you're connecting to the server. As Marcel pointed out, make sure you have the credentials correct and you are using the correct client. Does it just hang up when connecting?

 

[FollowFluffyBunny]

Not to Necro an old thread, but did you find a solution to your problem?
I'm running into similar behavior where my clients dissconnect almost instantly after correct creds.

 

[dagid4]

The problem is:

public static readonly string Address = null;

It goes like this:

1. Client -> I want to connect to this shard.
2. Server -> Sure, this shard has Address null.
3. Client -> Connecting to Address null... failed.

I have simplified the problem. If the Address is null, server will use its LAN address. But if the server and client are not in the same LAN (always the case, when you need port forwarding), it cannot work.

You have two options:

1. Enable auto detect.
2. Specify the address manually.

 

[FollowFluffyBunny]

I'll keep playing around with it. I think I have an internal network issue. People can reach my IP externally but on my local network I'm having problems connecting to the shard. I appreciate the insight and if I can't get it working I'll open a new thread.

 

[dagid4]

This is problem of Accessing Port Forwards from Local Networks. You need to enable NAT Reflection to make it working.

 

[FollowFluffyBunny]

Interesting. I looked up what this means on a Meraki FW, and it seems I need to do 1 to many Nat mapping.
I've tried a few different renditions of this and still the same errors occure, credentials are verified and then clicking on the shard instantly disconnects on the server side, and the client side sits and times out.
Here's a screenshot of a few different renditions of the 1 to many Nat rules I created.... the UO server is 10.10.18.10 in the DMZ, and the local network is 192.168.128.0/24 The server logs each connection as the FW IP of 10.10.18.1, which I find strange and I think that adds to your point @dagid4
I'll keep chipping away at this... it is driving me crazy.

When running a WireShark captures, it seems the client reaches out but the server only provides resets

Adding even further to my confusion using the Classic UO Launcher, I receive Socket Error on my first login, but my second login I'm able to connect. I'm not sure why that is able to get through upon retry when a classic Uo Razor client won't work.
And it's working... Not sure exactly where the issue was, but it seems like Meraki doesn't like putting Group Policy Firewall rules, in conjunction with MX firewall rules.
This thing has been a hoot to deal with...
Thank you everyone for the assistance and support.

 

[dagid4]

In typical scenario, you have FW with one public IP address (WAN address) and one LAN space. This is obviously not your case, because both 10.10.18.10 and 192.168.128.0/24 are private.
If you want me to help, I need to know your network topology.

From what I read about Meraki, it cannot do NAT reflection (Hairpin routing), unless you have multiple public IP adresses:

As with 1:1 NAT, a 1:Many NAT definition cannot use an IP address that belongs to the MX.

 

[FollowFluffyBunny]

Well... crap. my last message didn't go through.
It is working! I'm not sure exactly how, but I had conflicting firewall rules which caused UO traffic to be seen as P2P. I spent some time cleaning up and simplifying the rules and everything is working like a charm.
I can't say I'm a fan of the Meraki world, it wasn't clear that Group Policy placed on a WIFI SSID caused a majority of my headaches. What also wasn't clear with their system is their Client page doesn't indicate group policies enforced at the Wifi or VLAN level. Oh well. It is fixed and running.
Thank you everyone!