Doesn’t peer-to-peer work behind a firewall?
I thought it wouldn’t, then early in 3.1 it did. I just grabbed 3.1.11 and it gives the IP address of my firewall.
I have some free time to finish up a module I’ve been dabbling with and wanted to do some final testing. Unfortunately, the tester I had moved 10 time zones away and it’s a bit hard to hook up. I can get to your server, but that seems a bit wasteful…
Ok, did a little triage this morning, and I misremembered version numbers. It may have been somewhere in 3.0 this worked. Although I don’t have any of the versions which might have.
Is this behaviour desirable to anyone else? From memory of looking over the code about a year and half ago, getting lan p2p working breaks or disables the current scheme of using the firewall/router’s IP. I would think it needs some sort of 3rd inherited connection class for this (sorry, don’t have the source right now, so don’t know any names).
Thus spake “man”:
If you’re NATed behind a firewall, then your firewall’s IP probably is
the routable IP via which you talk with the net.
Are you intending to do peer-to-peer with someone on your side of the
firewall, or on the internet-facing side?
It’s not, relally. The amount of data transmitted is pretty small.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “man”:
Hmm. I’ve looked at this now, and it’s a bug. It should be possible to
specify your IP address, or otherwise you can’t use a private IP for
peer-to-peer on a LAN, or over a VPN.
Thanks for noticing this. It’s been added to the bug tracker as Bug 2881397.
sourceforge.net/tracker/index.p … tid=594231
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yup, from memory (been around a year and a half since I looked at the source), it asks the server what it thinks the client’s IP is. That would be the firewall/NAT box.
On the internal LAN. Thing is, I know this worked at one point (I distinctly remember 2 players, each with their own view, and an ‘observer’ running on the pvr connected to the big tv). For the life of me, I can’t remember the nuances of this working though: for example, did it beak the current functionality? I don’t think it did. Worse, I don’t remember which version did work. None of the ones I have do, and it looks like most of the older versions have been purged from sf.
Yeah, turns out that doesn’t work anyway (from behind a firewall). I’m guessing the server ties whatever data to the IP address…
Thanks for filing the bug.
Thus spake “man”:
Are you saying that it doesn’t work for two machines behind the same firewall
both to connect to the server? If so, that’s a big problem.
Brent says he’s going to work on this one for 3.2, so you’ll have a fix
in a few months.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Hi Joel, Man,
I am doing a lot of work on the Server implementations for 3.2 and would like to revisit this topic.
After much investigation and tinkering, I am thinking that there is no actual problem with the Peer to Peer server itself. The only problem is that it suggests an IP address for you to communicate to the owners of the other Peers, and this suggested IP address is not correct in all cases.
If you are running a P2P server inside a NAT, then another peer inside the same NAT would use an address such as 192.168.0.3:5050 to connect to you. At the same time, a peer outside the NAT would use the IP of the NAT router such as 115.32.150.44:5050 to connect to you (assuming the NAT router is port-forwarding port 5050 to your machine).
So the ‘bug’ is that Vassal is telling you the wrong address to tell other clients to connect you. If you ignore this ‘suggested’ IP and work it out for yourself, you can get it to work.
Therefore, the fix is to report 2 different addresses on the invite screen:
Local Address for machines on your LAN, (obtained by calling InetAddress.getLocalHost().getHostAddress(); )
Internet address by the method it uses now (Asking a Vassal webservice what it is) for machines outside your LAN.
Brent.
Brent,
Thanks for looking into this. Your description of the problem is good. Multiple clients behind a NAT/firewall won’t work. The IP addressses of the private clients are always the single address of the public side of the firewall. I briefly looked at the source about a year and half or 2 years ago, and this is because the clients ask vasselengine.org what their address is. That’s always going to be the public address.
Not sure what to think of the suggested fix. I haven’t spent much time with the code base (and, as noted, it was a while ago), but what kind of problem is this for the ‘invited’ client? When I looked, I thought a third option in the server prefrences option and connection (sorry, don’t remember the names) class hierarchy would be a little cleaner from the user’s side. And wouldn’t change the invite code at all.
I’m not a maintainer, and have no idea how much grief this causes just for a single IP address check. And, in this case, calling the current scheme “Direct Peer-to-Peer” seems counter-intiutive. A good name for the new way might be “Private Peer-to-Peer”.
Hope this doesn’t muddy things up to much.
Oh, one other thing to further confuse the issue. I wouldn’t expect multiple clients behind the same firewall to be able to connect to vassalengine.org. That sounds like a real headache.
Thus spake “man”:
I don’t see why this should fail, even as it is now. The connections will be
on different local ports in almost all cases. I can’t say exactly what will
happen if they’re not—maybe that isn’t even possible?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
Here’s my suggestion, formed after staring at the Direct Connection dialog
for a few minutes:
There are two cases:
(a) You are connecting to a machine on your LAN which has a private IP
(something in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16), or
(b) You are connecting to a machine with a publicly-routable IP address.
In case (a), we need to use whatever private IP we have; in case (b), we
need to use whatever public IP we have. Any other way will not work.
Therefore, we can detect what IP address to tell the user is his based
on the one he types into the text field.
That said, why are we showing the user his IP address in that dialog? What
are we expecting the user to do with that information? (This is not
rhetorical, I really don’t know what the rationale for it is.)
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yes, exactly. The display of the IP address here is in fact for you to use if you DON’T want to Invite other players, but it is for you to email to the other person to connect to you!
Some background:
The P2P client/server is better named ‘Private’ Server. When you ‘connect’ to the P2P server, you are starting up a private Vassal server running on your machine. At this point, you are neither a client nor a server. There are 2 ways that connections between machines are made:
You click the Invite players button and then type in the address of another players machine. As Joel mentions, you will need to use their LAN address if they are on your LAN, or their public Internet address if they are not. As man points out, there is a problem if you need to connect to multiple clients behind the same NAT router. In this case, you do what you always do in this situation, the owner of the router will need to set up port-forwarding on their router and provide a unique port on the router forwarding to port 5050 on each machine. So the Inviting player would use addresses like 215.34.55.62:5050, 215.34.55.62:5051, 215.34.55.62:5052 where ports 5050, 5051 and 5052 are being forwarded to port 5050 on each of 3 machines.
This starts your machine acting in the ‘Server’ role and the invited machines acting in the ‘client’ role.
You do NOT click on the Invite Players button, but instead wait for another player to Invite you, using the IP address that you inform them of via email. How do you know what IP address to tell them? In the past, you clicked on the Invite Players button and told them the address displayed there.
There are a number of issues with the current system:
a) IP display confusion.
The only place your client IP address is displayed is on the Invite dialog after you click the Invite Players button. However, if you want to be a client, then you should not be pressing the Invite Players button - it doesn’t make sense.
I have addressed this in my latest version by displaying the IP address(es) when you first start up your local P2P server. I can also display the address(es) on the P2P server configuration dialog.
b) Cannot determine correct Port if behind a NAT router.
When we start up a P2P server and want to run in client mode (i.e. be connected to by someone else), we need to display both the local LAN address and the discovered internet address. It is up to the user to determine which is the correct address to communicate to the player running the server.
We can correctly obtain and display both IP numbers with not problem.
However, if we are behind a NAT router, it is impossible to determine the correct port number that the server should use to connect to us. We know what port number we are listening on, but the NAT router could be port-forwarding any port number at all to use.
There is no programmatic resolution for this, it is a documentation and display issue:
c) Client and Server - illegal network topologies.
Currently, when you start a P2P server, it runs in both Client and Server modes at the same time and you can both accept and make invitations. This allows a group of players to inadvertantly create illegal network topologies where not all clients can talk to each other . The only valid topology is a star :- One machine is the ‘Server’ and Invites all other machines to become ‘clients’.
My initial thought was to have two P2P options in the preferences, ‘P2P Client Mode’ and ‘P2P Server Mode’.
However, thinking about it, I think it can be dynamic:
If you ‘Invite’ another player and connect to them, then you go into ‘Server’ mode and reject any further invitations made to you.
If you receive an invitation and connect to a ‘Server’, then you go into ‘Client’ mode and the ‘Invite Players’ button is disabled so you can not invite any other players.
d) Unwanted connections.
Also, because a machine can run in both Client and Server roles simultaneously, a malicious player, knowing your IP address, can connect to you as a Server, even while you are in Server mode.
My initial thought was to be able to password your P2P server, but I think the dynamic client/server idea would resolve this problem also.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
This seems reasonable to me. The one thing we have to be careful of is to
make sure that we properly handle the situation where you send an invitation
and then receive an invitation before the one you sent is accepted.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
So, here’s a big d’oh moment. If one were to muck around with routing (say, set www.vassalengine.org), but I wasn’t looking to do that…
Thus spake “man”:
Hmm. That might work, but it’s not a very robust solution… It will
prevent VASSAL from connecting to the game server, as well as checking
for updates.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yeah, not very robust nor even the right solution. It doesn’t seem to sync quite right at startup, but is a way to get things going. At least, until a better solution can be implemented…