NAT Loopback for Opensim
-
Well no one has responded to this so I've decided to attach my config.xml file that has been cut down to the appropriate sections.
I guess what I really want to know is what NAT loopback looks like in the config.xml file. I see nothing that would make me believe that rules are being generated to allow for loopback on ports 9000-9003
-Mike
Hi,
I am using opensim server and client on the same side of the router. I know the client and server are functioning properly since I can access the server with the same client when the client is not behind the same router as the server.
I have tried virtually everything and nothing seems to be working. All the messages regarding this seem to be old and outdated. I finally set up a second subnet with its own interface hoping that would make it easier.
What needs to occur is the external IP on port 9000 needs to forward to the server. Somehow, when the client is on the same side of the router, responses from the server don't seem to make it back to the client. The client continues to send requests and the server says it's ignoring the multiple requests.
I have the box unchecked the says to Disable NAT Reflection. In theory, this is all that needs to be done to make this work according to others that have a similar setup. I am using DDNS for my external IP.
Ideas?
-Mike
[My config.xml.txt](/public/imported_attachments/1/My config.xml.txt) -
Bump
-
I'm having trouble parsing your description. What do you mean by "NAT loopback"? If you want to be able to have the client access the server using the WAN IP when the client is behind the firewall too, you need NAT reflection enabled, not disabled.
-
Yes, the checkbox on the Advanced menu is unchecked to enable loopback rule creation. Sorry if I was confusing.
In the config file, I see nothing that appears to do anything for loopback and it's not working.
I am trying to access a server on the same side of the router as the client and it's not working.
-
Can you post /tmp/rules.debug?
-
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 :)
