NAT Loopback for Opensim
-
Here is my rules.debug file
-
For the rules.debug file, PLEASE NOTE! I just realized I made some changes since my original posting.
I moved the server back under the same LAN since the separate LAN was not solving the problem. The server is on 192.168.2.157 ports 9000-9005.
-
Can anyone please verify that NAT loopback is set up to work? I have my config file in the 1st post and the debug.config in a latter post.
The best I can tell is the loopback is not working. The only way I can connect to my server is to get my client out from behind my router. Like using my neighbor's wireless.
Thanks!
-
This is odd - the rdr rules look okay. I noticed you have two LANs, not one (not mentioned originally.) Are the client and server on the same LAN? If you try connecting to one of the ports from the LAN using telnet, what happens? e.g. something like "telnet WAN_IP 9000"? does it hang? What happens if you run a packet trace on the LAN when you try to connect?
-
Sorry about the confusion on the LANs. I have been trying so many things in order to get this to work. Right now, the client and the server are on the same LAN. I tried creating a 2nd LAN with a separate LAN card to try and get around this problem. No luck.
I tried using TightVNC to connect to the server from my client. I set the VNC server to use port 9000 since that is one I am forwarding and should have loopback on. When connecting to 192.168.2.157:9000 I connect fine and see my server's desktop. If I try connecting using sixteentrees.homeip.net:9000, It says connection established, but I never get my desktop (it hangs).
If I connect to my neighbor's wireless, I can connect to sixteentrees.homeip.net:9000 just fine.
I used VNC since I have it set up and I couldn't figure out how to get a telnet server running on XP soon enough.
-
okay, that is not a nat reflection issue then - if it were not being properly reflected, you would not even get 'connection established'.
-
Any idea then why it's not working? Loopback was the only explanation I could think of. It has to be a router issue since it works from my neighbor's LAN.
-Mike
-
One difference: if he connects from outside, it gets forwarded to your inside host, and the source IP is his WAN IP, so it is all consistent. With reflection, your inside host sees a source IP of the LAN IP of the pfense, and maybe it doesn't like that? Can you run a packet capture on your VNC server (or whatever) and see what happens when you try the connect?
-
I've not gone this deep before into networking and I did a search for packet capture and downloaded Wireshark. I started the capture and then tried connecting with TightVNC. I looked in the file and I can see the request from 192.168.2.119 (client) to the DNS getting back my WAN IP. I then see a request from .119 to the WAN IP port 9000 and I see what looks like a response. Then I have no idea what I'm looking at.
I have attached the Wireshark file in hopes you can read it. If not, please direct me to a packet capture tool you can use. FYI - the IPs in the 20s are printers on my LAN and the .200 is a file server. Maybe this needs to be run on the server side as well. Please let me know the next step.
Thanks again for all,
MikeP.S. In order to attach the file, I added the .txt extension. It is, however, a .pcap file.
-
the file is corrupt (too short).
-
Hopefully this will work. My guess is that the "text" file had characters in it that showed end of file. I'll try saying it's a jpg and maybe that will work. It's beyond me that the forum will not accept .zip.
I am also working on capturing from the server side and I can attach that in a later post.
-
This is a capture from the server side when I try to access VNC through sixteentrees.homeip.net:9000.
Again the file extension .jpg was added to make the upload work.
-Mike
[Through DNS.pcap.jpg](/public/imported_attachments/1/Through DNS.pcap.jpg)
-
What do you mean by 'server side'? I looked at that trace and there are no TCP packets at all. The client side trace was useless because it just shows the 3-way handshake. Remember that the reflector process on pfsense talks to the VNC server on a different port. Look at the /tmp/rules.debug and see what the reflected port is (something around 19000 or so I think?)
-
I'm sorry, I'm trying to be as much help as possible. What I meant by server side is I ran the packet capture on the the server PC itself. I'm simply choosing Start capture in Wireshark and then saving the captured packets.
I'm getting pretty confused right now as you talk about reflected ports. I included my rules.debug file for you to look at since now I don't know what I'm looking for.
I feel like we're real close now.
Thanks again so much for your help.
-Mike -
Sorry, I mixed this thread with another NAT reflection thread. In a nutshell: NAT reflection works by having a process started on the firewall which accepts input on 127.0.0.1:P2 where P2 is a specially chosen port. A rdr rule is put in which redirects access to port P on the WAN to the localhost on P2. The process then opens a connect to the real LAN host on port P. This is all necessary because you can't redirect a packet back out the same interface with the same port number :( So, that all said, this is the line from rules.debut which we care about:
rdr on $lan proto tcp from any to 24.21.73.53 port { 9000 } -> 127.0.0.1 port 19016
this means the reflector process is splicing together 127.0.0.1:19016 to the real LAN IP, port 9000. What that means is: run wireshark on port 19016 :)
-
Well, now I'm at a complete loss again. Just as I thought I was closing in, it works. I have no idea why. Why is this a problem? Because it works with VNC but not with opensim which is the original problem. So now that it's working and opensim isn't I don't know where to go next.
What I do know is that it's the router. Anyone else that has this problem solves it either by enabling loopback or buying a router that supports it. Like a D-Link gaming router. So I'm back at square one and don't know what to try next except give up on pfSense. It's too bad because I liked having a VPN option.
Maybe you have another thing for me to look at, I don't know. I'm still willing to try if you are.
-Mike
-
Best bet I can think of: the opensim server is not happy seeing the connection coming from the pfsense LAN IP. Question: is there a reason you have to use the WAN IP? Why can't you connect on the LAN IP? You could have a name opensim.yourdomain.com (or whatever) with your external DNS provider that points to the pfsense WAN IP, and a name opensim.yourdomain.com on the pfsense (under DNS forwarder, I believe). That way, your client can reference the name and it works wherever you are. This is called split DNS and is preferable to reflection.
-
I have tried to do what you're saying about a split DNS, but I'm not sure I have implemented it correctly.
I do have a dynDNS of sixteentrees.homeip.net that points to my WAN and I have the DNS forwarder enabled for sixteentrees.homeip.net -> 192.168.2.157 (opensim server).
My DHCP server sets 192.168.2.1 as the DNS server so my clients should start there. My general setup has the DNS servers of 208.67.222.222 & 208.67.222.220. I guess, from my understanding, if my client wants sixteentrees.homeip.net, the router should provide 192.168.2.157 as the IP instead of the WAN.
For shits & giggles, I've attached my current config file. This time I'll send the whole file instead of editing out what I thought was irrelevant. In the process of editing the file to hide names and pswds, I saw that the DNS forwarder was using my other dynDNS. I changed it, tried it, and it still didn't work. I may try restarting the router.
-
I tried the reboot and it didn't fix it. I forgot to answer you question about why I can't use the local IP of the server.
Best I can tell, I have no control over that. With the opensim simulator, I log into a grid that hosts users and their inventory. One can run a server and connect it to the grid for anyone to access that is on the grid. So when I connect to the grid and then teleport to my sim my client and the grid doesn't know that the server is mine and on the same side of the router as my client. I believe it is the client accessing the grid and the grid then accessing my server, but since both are behind the same router, the router is not handling it properly.
I don't fully understand this communication protocol, but only from what I've gotten from the opensim forums. They have a set of recommended routers that properly handle the loopback needed. They are listed on this page "http://opensimulator.org/wiki/NAT_Loopback_Routers" and they are "gaming" routers. I believe what they mean by "gaming" is that gamers have the exact situation I have with opensim. A user accesses a group server and may serve their own region as well to the group. Therefore, for them to access their own region, they need the same NAT loopback.
I hope I'm making some sense and not either or both confused or confusing due to my lack of a full understanding of what's really going on.
-
It sounds like a real mess (and a badly designed system, IMO, not your fault.) And another reason to get rid of NAT and to to IPv6. Yeah, I know some NAT implementations work, but… Sounds like you are screwed, since the client seems to get the IP from the server, ugh :(
