NAT not working correctly?
-
That seems to be UDP, nat reflection and udp don't really work if I recall the threads.
Why not just use the internal IP and go direct to 5060?
-
NAT+Proxy reflection won't work for UDP
Pure NAT mode should work OK for UDP
It's still best to have internal devices contact the internal IP address directly when possible
-
The good news is…. It fixed it!!!! YAY :)
The bad news is.... It broke EVERYTHING else??? :(
Why would that be??? Now my port 80, 443 etc aren't working from internal :(... Can I not have the best of both worlds?? :(
Aaron
-
You can use different nat types for different forwards - are you trying to use pure nat for everything?
I personally don't see why nat reflection is even needed - you are on the network, why hit the public just to be reflected back in. Just resolve what your trying to hit to the local address when your inside. Now you don't have to worry about reflection.
The only reason that you would need nat reflection is a hard coded IP, hard coded IPs are bad ;) Use the fqdn that resolves to your internal IP when your internal, and when your external that fqdn resolves to your public IP. It really is that simple
-
Ya. I figured out how to set it up per NAT firewall setting. So, I left it has I had it (NAT+Proxy) and then went into the Firewall/NAT and changed the actual one item to Pure Nat. This fixed all my problems :) Honestly, I know I should have separate DNS for internal, but I just am to lazy to set it up that way :) So, I my internal DNS points to my external IPs still because I don't want to setup another DNS server for Internal items :)
Thanks all for your help :)
-
why do you think you need another dns server for internal?? What dns are you using now?? The one that is pfsense? Its a simple host over ride to have it return the local IP for your internal boxes.
-
Maybe I am not understanding….
Here is my setup..
If I go to www.mydomain.com it points to an outside IP address... Lets say 70.50.151.20.. I then have port 80 open on pfSense to point to my internal IP address of 192.168.1.50
If I want www.mydomain.com to point to 192.168.1.50 directly without going to 70.50.151.20, I would need another DNS server to point to the local IP address instead of external. Right?
Am I missing something?
-
Where does your box your using now point to for dns? Normally it would point to pfsense. Which in turn would ask your isp dns, or root or opendns or google dns for www.mydomain.com
So you go in to the dns forwarder section of pfsense and say www.mydomain.com is 192.168.1.50. Now machines using pfsense as their dns get 192.168.1.50 for www.mydomain.com –- people on the internet would get your 70.50.151.20 address.
My point is this default setup, out of the box pfsense runs a dns forwarder, just like every other soho router on the planet. Clients behind the device point to that device for dns - which in turn asks your isp or other dns you configure. This saves the trouble of say 100 computers on your network all asking your isp for the www.google.com.. Pfsense asks your isp and then caches it, now the other 99 machines that ask for www.google.com just ask pfsense and it already knows the answer.
So you don't need to setup anything - it should already be running. All you have to do is tell pfsense hey www.mydomain.com = 192.168.1.50.. It takes all of .3 seconds to do.
-
Gotcha! Sounds good.. As per your recommendation, I switched it over to use the DNS Forwarding :) Thank you for your help!
-
One other quick question… Now that I setup DNS Forwarding... Is there any point in NAT Reflection? What would be the best setting for this now?
-
No there really is no need for nat reflection if you have your internal boxes resolve the www.mydomain.com to your local IP.
-
No there really is no need for nat reflection if you have your internal boxes resolve the www.mydomain.com to your local IP.
For some services (like hosting game servers) connecting to the inside IP isn't an option. For Galcon2 the server list is controlled by the game company. They list the external IP in the server list sent to the client so that is what your client has to connect to. There is no manual entry to specify an IP so you have to connect to the IP that is provided by the master list server (which you don't even see the IP directly… you just see your server name).
-
"you just see your server name)."
My point exactly!!! So you resolve this name LOCALLY to your LOCAL IP!!! Not what it resolves to on the public internet.
Seems your not quite grasping the concept - lets do an example.. Lets pretend www.pefsense.org is my public server name that resolve to
C:>dig www.pfsense.org +short
208.123.73.69So that is my pubic IP address. But I don't want my local boxes resolving that - I want my local boxes to resolve the actual local IP address, lets say it was 192.168.1.7 – so I setup the local dns my boxes are using to resolve www.pfsense.org to that IP. Or I put a entry in their host file, etc..
So since my boxes are all using pfsense dns forwarder I create an over ride. See attached.
Now when my game gets this game lists that says connect to www.pfsense.org -- I connect to 192.168.1.7 vs the 208.123.73.69 that would just need to be reflected back in to 192.168.1.7
-
By server name I mean 'Adam's Server'. The ip is not exposed but that is what is sent to the client. The domain name is not used by the server list.
1. My game server registers to master server. The master server sees what external IP address that comes from and registers that IP in its server list. I have no control over that.
2. Client connects to master server and gets a list of servers. I see my server listed as 'Adam's Server'.
3. I click on the my server to connect to which the master server has used my external IP. There is no DNS involved and not possible to do so with Galcon2.
If I could manually connect to an IP I could connect to the my game server internally. Since the client relies on the master server list which goes by IP for the connection i have no way to specify the internal ip or use a DNS name.
This is why I need to use NAT reflection for UDP.
-
Well that is pretty stupid setup to be honest for people wanting to connect to server that is on their own local network. Since pretty much everyone is behind nat these days, hoping for nat reflection to work is going to fail most of the time.
Play on a server that is not run on your local network would be my suggestion. Host your game server on a VPS, dedicated hardware off your network, etc.
Did you try pure nat for your nat reflection setting per other post by jimp?
Other option maybe - is just use port forward.. So your trying to hit publicipaddress:1234, you clearly know what your publicipaddress, so on pfsense create a port forward on your lan interface for destination publicip:1234 to go to privateip:1234..
Now when your game tries to connect to publicIP:1234 pfsense just forwards it to private:1234 without going through the nat process. This might be the way the purenat setup works – not real clear on the details of how that works internally with pfsense mostly because I just really never have seen a need for nat reflection in the real world. Its a shortcut that promotes bad habits if you ask me ;) To me its a hairpin - which is never really good idea ;)
-
The whole point of NAT is to break IP. The question seems to be is "is there a way for PFSense to use NAT to break IP, but in a very certain way".
I guess what I'm getting at is the title of this is "NAT not working correctly?!". Of course not, there is not a single implementation of NAT that works correctly because NAT itself is the problem. It seems a bit accusatory to imply that that something is wrong with PFSense when there isn't even a standard implementation for NAT.
That being said, I would go with johnpoz's idea of keeping the ports identical and seeing if it gets sent to the correct internal IP.
I know I had mumble working this way at one point. I could connect to the external or internal IP just fine and it was also a hybrid TCP/UDP, TCP was control and UDP was voice. It did take a bit of playing with the NAT settings to make it work correctly.
-
I did get UDP reflection to work on 2.2 beta. I had to use Pure NAT reflection mode and make sure 'Enable automatic outbound NAT for Reflection' in the 'Advanced->Firewall and Nat' settings page.
