UDP Associate and FFXI

[sodaboy581]

Here's my situation. I have a friend who's in College. For some reason at the dorm they have a really restrictive firewall.

I recently bought them a copy of FFXI, hoping they'd open the ports for them to play. (Really, there's no harm in this..) But they're being anal about it.

This is where I came up with the idea of using Wingate's SOCKS5 proxy service to allow them to play, since it has TCP and UDP capability.

I'm running Wingate on my home PC, and they connect to my SOCKS5 server from their dorm room over the internet. Specifying my public IP address and port, as well as their authorization information..

Looks like everything was going okay, they can use PlayOnline, download patches, create a character in game, but once they try to go into the game, I see a "UDP Associate 0.0.0.0" on the SOCKS5 server information.

However, only 14 bytes are sent, and 12 received (could be the other way around) then the connection drops. The game says it was unable to connect to the server.

Now, trying the same parameters on my local network to connect to my SOCKS5 server works.

I remember reading something about UDP over NAT, is this just not possible? I thought it wouldn't matter if I'm using a SOCKS5 proxy server.

They're connected to my SOCKS5 server just fine. They are using NAT at the college but are unable to get into the game.

Any ideas on how to make this work using Wingate?

(I'd like to mention I've tried various socksifier programs to connect to the Wingate server with the same results. Sockscap32, ProxyCap, and Freecap. They all connect just fine, as verified by being able to connect to PlayOnline plus Wingate saying so. Actually, Freecap crashes when trying to connect to POL, but whatever.. anyhow.. the Socks5 server is working fine as demonstrated by being able to connect and patch, plus create a character. The thing just falls through at "UDP Associate 0.0.0.0", though. With barely any data being transmitted.)

[adrien]

Hi

This should be working. The client end needs to send the first UDP packet on this, so that WinGate can learn the true IP:port of the client (especially since it is behind a NAT).

If you turn on debug logging on the SOCKS server, do you get any entries like:

"UDP Associate: received %u bytes from %s:%u"

Adrien

[sodaboy581]

Here's what happens when my friend tries connecting to my SOCKS5 server from their college.

Failure log.

And here's what happens when I connecting to my SOCKS5 server from my own internal network.

Success log.

What could be going wrong?

(BTW, debug logging turned on for both logs, although there's no "Debug: UDP Associate" in the failure log...)

[sodaboy581]

Just in case someone already read my last reply and is racking your brains at it, I just tried my SOCKS server and the game from another location.

I went to one of my clients I do some work for who also has a restrictive firewall. I brought my laptop and FFXI for some testing, to see what my friend from college sees when she tries.

Got another failure log for you.

If you want specifics on how I'm hooked up, the SOCKS5 server is running on a desktop at my house which is connected to a Linksys WRT54GS router. (It's wired and not wireless.)

The port I'm using is 53, and both UDP and TCP are forwarded to my desktop server's private IP address. The port forward is working, as you can see, because connection to the SOCKS5 server is allowed and data is transmitted.

Upon the point where "UDP Associate" occurs everything is okay. When it tries to do the UDP associate part, very little bytes are transmitted and it eventually times out with POL-3001 (which is could not connect to server) error.

It doesn't appear it's trying to make any weird connections, I typed NETSTAT on my laptop during the time it was trying to connect to the server after selecting the character. The output from that is seen as:

Active Connections

Proto Local Address Foreign Address State
TCP SODALAPTOP:1057 c-67-?-?-?.hsd1.ca.comcast.net:domain TIME_WAIT
TCP SODALAPTOP:1058 c-67-?-?-?.hsd1.ca.comcast.net:domain TIME_WAIT
TCP SODALAPTOP:1059 c-67-?-?-?.hsd1.ca.comcast.net:domain TIME_WAIT
TCP SODALAPTOP:1064 c-67-?-?-?.hsd1.ca.comcast.net:domain ESTABLISHED
TCP SODALAPTOP:20999 c-67-?-?-?.hsd1.ca.comcast.net:domain ESTABLISHED

The :domain, of course, is port 53, which is the port I'm running my SOCKS5 server on. I've tried other ports as well, 80 and 443, with the same amount of success. Able to use PlayOnline flawlessly, able to download patches, but once starting FFXI, you're able to get your character data from the server and what not.. but at the moment you try to connect to the Game World and the UDP Associate thing happens, you get POL-3001, unable to connect to server.

Any advice would be appreciated. =)

[adrien]

One thing

Do you get any firewall hits in WinGate when this happens? I'm wondering if perhaps the UDP associate socket is being blocked by the firewall.

Also, if you turn on logging for session termination, we can tell if the client closes the connection, or it times out.

Adrien

[sodaboy581]

No firewall hits, everything's clean.

Fresh failure log for you with the session stuff turned on.

I installed WinGate onto a Windows 2000 SP4 server and now I'm trying to use the SOCKS5 server on that from my house. I can remote into it and change settings, so that once I get it working from my house, I'll know it will work for my friend.

Experiencing the same thing they're experiencing now, though, when connecting to my SOCKS5 server.

I'm kind of out of ideas, haha.

I hope you're not mad, but I tried various other solutions too, after this didn't work.

I tried CCProxy, same result, stop @ UDP part with IP address:0

I tried socks2http in conjunction with a private gateway. Same result, die after picking character when the UDP part happens.

(Even tried changing the client socksifier from Sockscap32 to ProxyCap to even FreeCap, as I've stated earlier..)

Is there anything else I'm s'posed to forward in my firewall besides the TCP/UDP socks port to my machine that's running the SOCKS5 server?

I've done little fun tests with simple TCP programs like WinAMP streaming radio and other junk, they all work fine. Haven't tried any more UDP programs. I really just want to get this one to work and I'll be quite happy.

And, believe me, I have every intention of buying Wingate if this does the job for me. They'll be so happy it works..

Thanks a bunch for any help you can toss my way.

[sodaboy581]

Installed eEye Iris to do some network capturing. Noticed after selecting character, it tries to connect to random UDP ports on my SOCKS5 server machine.

Saw it do port 1090, 1095, 1098, 1104, 1112.. it seems to go up every time I change areas in the game... You'd think it'd lock everything down to TCP port 53, but it doesn't.

This is probably why it's not working. I s'pose I'll configure my outside machine as a DMZ and get everything not supported forwarded to that outside machine and see if it works.. *crosses fingers*

Screen shot for you!!!

Gunna try it from work today. Wish me luck, but even if it does work, is there anything I can do in Wingate to solve this problem without the use of DMZ?

I mean, 'cuz even if this works... My friend's restrictive firewall wouldn't allow connections to machines on these ports.. I want to keep all connections going to port 53... =\ I thought that was the point of a SOCKS5 server?

[sodaboy581]

Well, I think I found part of the problem.

When I'm on an external network connecting to my Wingate SOCKS5 server, at the UDP part, it tries to connect to my private IP address.

For example, my IP address at my office is 192.168.2.123

My SOCKS5 server is being hosted at my house on a network card with the IP address of 192.168.1.100 (The port for the SOCKS5 server is forwarded in my router..)

It seems to work pretty much okay, my laptop at my office, trying to connect on my public IP address and port for the SOCKS5 server. Everyone on TCP works.. HOWEVER, when UDP rears it's head, it IP address it tries to use is my private IP address.. I guess because that's what Wingate is sending out?

Is there a way to tell Wingate that the proxy user needs to use my public IP address instead of my private? Here's a screenshot of what's going on.

Click here.

EDIT: Okay, I've set it up again on a new network, Wingate that is... I've configured the SOCKS5 server again.

This time, the SOCKS5 server computer on the network has only an external IP address. It doesn't use NAT or anything. The firewall is also off.

Got the same error, but at least the IP addresses were right, I think.. well, I'll verify when I get home and test it. My friend tested it for me this time. Still get the problem going into the game.

If it's trying to initiate a UDP connection to a port that's not 53, then I think that could be a problem for the restrictive firewall.

I'll try connecting to my true external IP SOCKS5 server, to try and play FFXI, when I get home today from my NAT'd network and see how it fares.

[sodaboy581]

Well, guys, I've confirmed the problem. I tried to connect to my external SOCKS5 server which is on a true public IP, not NAT'd, from my home NAT network and attempted FFXI. The result? A success. But this is because my home NAT network is not really restrictive on outgoing ports.

You see, it seems to use port 53 (my SOCKS5 server port) for all TCP connections.. but when UDP comes into play, it still uses my SOCKS5 server's IP address, but the destination port seems to be random.

Check this out, a successful FFXI connect with a SOCKS5 server, got in game and everything.

Wingate Log from the sesssion.

At the point you select your character and try to go in game, an attempt to connect or transmit data occurs to my SOCKS5 server's IP address and a random UDP port. In the image above, it's port 4953.

First UDP transmission is from source 192.168.1.105:54090 to 207.*.*.*:4953

Why does this occur? Why can't it always try to use port 53? Or even if we could define a port to force UDP stuff to try to connect to, like a secondary one, such as 80 or 443, why can't this be done?

Since my friend's firewall is so restrictive, they have no hope of being able to connect to my SOCKS5 server for UDP on random ports. I thought the whole reason for SOCKS5 serverism was to force everything to connect to one port, TCP or UDP.

If this is not possible, is there some sort of workaround? What about VPN? Hopefully VPN communicates via TCP.. could you say, socksify a VPN client to connect to another network, then use random ports then?

Once again, any advise would be appreciated.

[adrien]

Hi

Basically with UDP associate, the client indicates a port number it will send UDP packets from, which is also where it wants return packets to be sent to. WinGate sets up another UDP socket, on a random port, and sends the IP and port number back to the SOCKS client. I guess we could allow an override port to be set, but then you could only have one SOCKS client at any one time doing UDP associate (since SOCKS clients can't share UDP associate ports).

So if the SOCKS server is behind a firewall, you will have the problems you are describing, since WinGate will send its own IP back, and the port number will keep changing.

You could run a VPN. If your friend sets up a VPN to your VPN server, then he should have no problems accessing your SOCKS server on the VPN. You can get the VPN server running on whatever port you like, so all traffic goes through that - that I presume is why you were running the SOCKS server on port 53 - so that your friend's firewall doesn't block it?

Adrien

[sodaboy581]

I guess we could allow an override port to be set, but then you could only have one SOCKS client at any one time doing UDP associate (since SOCKS clients can't share UDP associate ports).

This would be a nice feature, if you could implement it.

In the mean time, I'm going to try the VPN -> SOCKS server method. Running the VPN on port 53 and the Socks server on port 1080. I pray it works. ^_^

Thanks alot for the help.

(And yeah, I set it up on port 53 before 'cuz the firewall doesn't block it.)

[adrien]

In the mean time, I'm going to try the VPN -> SOCKS server method. Running the VPN on port 53 and the Socks server on port 1080. I pray it works. ^_^

No problem there - once you have a VPN set up, all traffic goes over it, but the only ports going through the firewall would be the VPN data and control channel ones.

Then connecting to a SOCKS server is real easy.

Adrien

[sodaboy581]

No problem there - once you have a VPN set up, all traffic goes over it, but the only ports going through the firewall would be the VPN data and control channel ones.

VPN data and control channel? So two ports? Are these two ports configurable? I'm going to try Wingate's VPN server program.

In addition to this, would I use the Wingate client to connect to this VPN?

(Well, I am confused, looking in the Wingate client only wants to connect to the Wingate service.. what VPN client would I use to connect to the VPN running on my machine? One where I could put ports in and what not?)

[Pascal]

WinGate as well. It can act as a server (VPN Host) or as a client (VPN Joiner) . Ports are configurable through the user interface (Check General tab of main VPN configuration).

[sodaboy581]

Okay, they've joined my network. It says their local network has joined...

But they can't ping my computer in my network with it's address? Is this normal? This was a simple test.

After they connected to the VPN, I had them type

"ping 192.168.1.100" from a command line, but request time out.. what's up with that?

That's not looking good for the SOCKS server.

Last lines in my VPN log are:

09/21/05 21:13:53 VPN Tunnels: Tunnel to node Local network of KASUMI (216.184.75.20:443) with ID 6 active and updated
09/21/05 21:13:53 VPN Connection: 'Local network of KASUMI' has joined 'FFXI-VPN'

Here's a picture of their network joined..

Last edited by sodaboy581 on Sep 22 05 5:32 pm, edited 1 time in total.

[Pascal]

There is a little bit of setup required to get the VPN running. Because it is a routing based solution both systems must be aware of where to route packets destined for the remote networks.

Can you briefly describe the network topology, please?

[sodaboy581]

Okay, here's the full scoop afaik.

My network consists of:

A Linksys WRT54GS router.
Wingate VPN running on a desktop with Control Port 80 and Data port 443. (IP address is 192.168.1.100 and the ports are forwarded in the router.)

Their network consists of:

I have no clue, but I know their machine's IP address is 172.16.100.77 (which is of course NAT'd)

They are able to connect to my VPN, as shown in this picture.

When they try to ping 192.168.1.100 after connecting to me or I try to ping their IP, no response. So, yeah, a routing issue, I guess.

What other information do you need?

[jamesc]

I notice in the image you showed that you have a Gateway on your network card that is marked as "Internal" and is called "Local Area Connection". If that is a gateway to your router, please see 1.) below. I have added a troubleshooting section for the VPN as well below.

VPN Troubleshooting check list.

1. On the WinGate VPN Host, check to see how the adapters were detected by WinGate. The network adapter pointing towards the internet should be marked as "External" and the one pointing towards the LAN should be marked as "Internal". GateKeeper --> View Menu --> Network




2. If you are not able to ping the VPN Host, please check your MTU settings. When you are connected into the host from the joiner, you can do a small test to establish your correct MTU (Maximum Transmission Unit). If the WinGate Hosts' internal IP Address is 192.168.0.1, then from the joiner, do the following.

(Windows) Start Menu --> Run --> cmd

Code:

ping -l 1500 -f 192.168.0.1

If you do not receive replys then lower the 1500 to say 1000

Code:

ping -l 1000 -f 192.168.0.1

If you do not receive replys then lower the 1000 to say 600

Code:

ping -l 600 -f 192.168.0.1

Once you start getting replys, edge the number up from 600 to say 800 etc etc... until you find your optimum setting. Once you have obtained it, download this utility: http://www.dslreports.com/drtcp

And if you have a dial up connection, you must place the MTU into the red box as shown in image below. Once done, restart your computer and try to connect to your database again.



You should test back from the host to the joiner too.


3. If you are unable to access computers behind the WinGate Host, or Joiner, then those computers must either:
1) Have the Wingate VPN server set as their default gateway
2) Make a route for it
3) Load the Qbik RIP2 Utility on each client machine (but not on the Wingate Joiner or Host). The RIP utility can be downloaded from here: http://www334.pair.com/qbiknz/downloads/ripv2client.zip


5. Do you run any security suites on the machine that is not pingable? McAfee / Norton / ZoneLarm etc...


6.Some more information the team may require are if you cannot resolve:
route print
ipconfig/all
WinGate Config Report.

(Windows) Start menu --> Run --> cmd --> route print
(Windows) Start menu --> Run --> cmd --> ipconfig/all
GateKeeper --> Options menu --> Advanced --> Export Configuration

[sodaboy581]

Just to clear something up, the picture I sent before was from of my test machines, haha. A joiner not the host. But my host had it's network card set to Internal so I just changed it to External.

Does whether or not "Local Area Connection" is set to Internal or External matter on a VPN client machine? (Not the host..)

Another thing, if the rip thingy fails to make a route for the thing, how would I go about making a manual one? Like, what should it look like?

(BTW, no we have no security suites running at the moment... My machine is pingable from my internal network.)

[sodaboy581]

'k, it's still not working, even installed the RIP client on the VPN client machine.

Here's the files.

http://www.vengefulsoda.com/wingate_host.zip <-- Configuration stuff for the VPN server.

http://www.vengefulsoda.com/wingate_client.zip <-- Configuration stuff for the VPN client.

Both zips have the route table, IP configuration, and Wingate registry settings.

[jamesc]

Just to clear something up, the picture I sent before was from of my test machines, haha. A joiner not the host. But my host had it's network card set to Internal so I just changed it to External.

So does the pinging now work?

Does whether or not "Local Area Connection" is set to Internal or External matter on a VPN client machine? (Not the host..)

Its best to set things up correctly, so on the joiner the same applies. Especially if machines on the Joiners network need to participate in the VPN.

Another thing, if the rip thingy fails to make a route for the thing, how would I go about making a manual one? Like, what should it look like?

You would want to use the RIP client because it will add new routes automatically.

[sodaboy581]

So does the pinging now work?

You would want to use the RIP client because it will add new routes automatically.

Well, as I've said, pinging doesn't work and we did install the RIP client on the client machine. The routes don't appear to be added, as you can see in the files up there...

The VPN client's internet adapter was set to "Internal", so I just had them set it to External.

Will wait a little to see if the RIP client adds the routes and see if that make sany difference.. I doubt it will, but eh, we'll see.

If it doesn't I was just wondering what I should put in as a route, the information for it, you know.. depending on the configuration data I uploaded in my previous message.

Well, I changed everything to External now. Ping still doesn't work.. Routes are pretty much looking the same...

However, I notice some computers on their network now don't have "Not accessible" next to them.. Still, IP communication isn't working =P That's all we really need working, so they can connect to my SOCKS server on my network.

I've tried to manually add routes, but not sure what routes..

I had them type on their computer:

route add 192.168.1.0 MASK 255.255.255.0 172.16.100.77

Then on the VPN server, I typed in:

route add 172.16.0.0 MASK 255.255.0.0 192.168.1.100

Then I had them try to ping 192.168.1.100 but still failed.. I don't know what else to do.. boohoo.

Latest picture from a locally connected VPN client. (This shot isn't from the server).

[jamesc]

Would you like me to give you a call? Send me your phone number via sales@wingate.com and reference this forum post. I will also send you an updated driver file; tell me what OS the joiners and host is running.

Also, the RIP2 client should not be placed in the locations that are running the VPN software. It only needs to placed on computers behind either side of the VPN Host or Joiner "IF" they do not have the WinGate VPN server as their gateway (And they need to participate in the VPN).

[sodaboy581]

I've sent my information to that e-mail address...

It's about 12am now, though, haha. I don't know what time it is there, probably like 1pm.. (Since the default time was what +13 GMT on this forum? I'm GMT-8)

Is it possible to call at another time? I have to sleep for work tomorrow soon. Like maybe we can do it a little earlier I guess if you guys open at 8am at your time, that'd be 7pm my time, which would be more than fine.

[sodaboy581]

Got everything working!!!!

Not sure if changing data port from 443 to 53 or updating the drivers from e-mail are what fixed it.

Thanks for ALL THE HELP you've given me throughout this time. Definitely going to purchase this product.

Now which products would I have to purchase to have this working?

I have the Wingate server running on the desktop. Services I'm using are VPN and SOCKS5 server for ONE user.

Then my friend is running the VPN only client on their machine.

[MattP]

If you need to give VPN access to a machine behind the WinGate server then you'll need a VPN gateway license at your end.

So, you'll need a 3 user WinGate Standard license, plus either a 3 user VPN Gateway license, or a single user VPN license.

Then your friend will need a single user VPN license also.

[sodaboy581]

The VPN server and SOCKS server are running on the same machine. The same Wingate install.. So shouldn't it just be 2 user, I guess? There's only 2 machines involved.

The server:

VPN + SOCKS

The client:

VPN client.

[MattP]

WinGate VPN licensing is based on licensing each end of the VPN.

At your end you have the host server, so you will need a VPN license for that.

Your friend at the remote end will also have a VPN server, so he will need a license for that.

Isn't the game running on a machine on your LAN behind the WinGate server? If so you will need a gateway license on your server to grant access to the machines behind the server.

If the game is running nn the WinGate machine then a single user license should be fine.

So depending on where you run the game you'll either need a 3 user VPN gateway license, and no matter what your friend will need a single user VPN license.

If you would like to read more about the way our licensing works please see this link

[adrien]

If all your friend needs access to is the SOCKS server which is running on the VPN server, then as Matt says a single license on that end should work fine.

the client just won't be able to have routed access to other machines on that LAN, but will be able to go through the proxies or SOCKS server fine.

Adrien

[Linxeos]

I'm sorry but I must ask this:

I'm having the same troubles as you did, I read through your posts and others posts here. I'm not 100% positive on the programs that u used and how you set them up. If I could get a guide and I'm sure it would not only help me but others who come looking for a way to tunnel through to play ffxi it would be appreciated.