UDP blocked - NAT reflection unable to connect over UDP
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
Edit: Coincidentally that link you provided specifically states that NAT+proxy doesn't work for UDP.
You're correct. Read it wrong.
Regarding split DNS assuming my settings are correct it still doesn't work for my application because the URL used still translates back to an internal IP and I need an external one. This specific case is for an ARK cluster and it specifically needs a WAN address.
It requires strictly a WAN address?? I'm wondering what makes the different for the application.
So basically it should work with NAT reflection in proxy mode though. If it doesn't you can try forward it manually in addition with an outbound NAT rule. But don't know, if this makes a difference.
-
@horizon82 What are the rules involved - you sure your allowing udp to go out from your lan side network.. If not then it couldn't be reflected.
Same goes for your wan rules if your saying udp doesn't work from external.
You can validate working with sniffs. Validate this udp traffic hits your wan, and then via sniff on lan side to validate its being forwarded on.
Same goes for pure proxy test..
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
the URL used still translates back to an internal IP and I need an external one
huh? At a loss there, your saying if the fqdn you use, and create host override for split dns doesn't work if the IP is not returned as public?
What specific game server are you running - might be helpful since others here might be running the same server, etc.
-
Strictly WAN address. It's an ARK thing and has been posted many times over many forums with troubles and the resolution every time is NAT reflection. It's just not working for me.
Looks like I can no longer connect my roadwarrior vpn to remotely log into the pfsense box so I can't confirm but I do not believe there is a specific allow UDP rule on LAN; rather there is a default allow any rule. UDP Port forwards are configured on WAN and do work for external clients.
If I add a host override in DNS resolver for said host.fqdn and put that into the Steam client it resolves back to the LAN IP of the forwarded PC not the WAN IP.
This is an ARK cluster and the way the game is coded is for cluster transfer it requires a WAN address.
Why would TCP work by default but not UDP? I don't have any specific TCP rules other than allow all on LAN and its respective port forward on WAN. Just to reiterate, external clients can connect to the game server without issue which is UDP. It is my VNC testing that won't connect via UDP externally even though I have the rule created for UDP (making the change to TCP immediately works for VNC).
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
said host.fqdn and put that into the Steam client it resolves back to the LAN IP of the forwarded PC not the WAN IP.
That is how it is suppose to work ;) Why would it require a wan (public ip) address, A client wants to talk to a server - why would it matter what the IP is be it public or rfc1918 if it can talk to the server? Since the server is right next to it on the local lan it makes little sense to just send it to your wan IP to be reflected back in to the local address.
Your "server" reporting into some cluster would use whatever your wan IP is.
If your saying the game checks into this public cluster, and your client never actually tries and resolves your specific local servers name, then yeah such a scenario would require nat reflection.
-
That's how the game was coded. It's not my choice and not something I have control over. There is no setting inside the server config to override it.
-
@horizon82 yeah such things can be problematic for sure. There are scenarios where nat reflection is required where the client is hard coded to use some public IP, or what sounds like this scenario it gets the IP of the specific client from some external source and the only IP that can be in there is public.
Not a fan of nat reflection, and don't play with it much. And have nothing I need to use it for. And for sure not via udp, etc.. But I was not aware that it wouldn't work for udp. But quite often you would have to use pure nat sort of mode or you can run into asymmetrical problems. Not always the case - but it can be problematic sometimes if not used..
I would validate your reflection is working via sniffing to validate your client sends traffic to some port X on your wan IP, and that you see it being redirected in to your servers IP.. You would do these sniffs on the pfsense packet capture under diagnostic menus.
edit: if you do a search here for ark server - there are a few threads about, have not read any of them in detail, but you might find your solution in one of those.
-
Earlier when I did a pfsense packet capture on UDP there was zero data being reported. Wireshark on the pc itself trying to establish the connection also showed zero data - worked fine for TCP. I'll continue some sniffing to see if I can get more details. Up until a few hours ago my roadwarrior vpn was connecting and that uses UDP but I must have changed something and that no longer connects. I'm going to run home and see what that problem was.
I have done tons of internet searches for the last 3 days to try and resolve this and have exhausted everything I can think of. I have read some posts on this site through my google searches but I will search here specifically in the event I have missed something.
Edit: Odd, roadwarrior isn't working but in battlemetrics I can see my buddy connected to the game server. Static 1:1 mapping is what broke the roadwarrior.
-
I was under the impression VNC uses UDP by default but I see in the firewall log that im blocking TCP:S for port 5900. port forward rule is allowed for UDP5900.
Well now I know why VNC is being blocked; because its using TCP and the rule is configured for UDP.
-
Watching the packet capture and I can see some hits from random IPs, some of which I think are battlemetrics pinging my server. I do see a couple hits from my WAN address to the forwarded LAN IP after I try to add the server in steam. I also see microsoft hitting that port.
So if packet capture sees my WAN IP hit the server LAN IP but I steam doesn't recognize it, what does that mean?
I did a quick start capture, add server in steam, stop capture and this is what I got.
16:17:40.831730 IP 107...*.56443 > 192.168.11.253.27060: UDP, length 25Edit: looking at the firewall log I also see a pass from my WAN IP to the server's LAN IP on the respective port I'm testing. I am so confused.
I spammed the connect in steam and I see:
pass ipv4 loopback 127.0.0.1:random ports 127.0.0.1:53 -
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
16:17:40.831730 IP 107...*.56443 > 192.168.11.253.27060: UDP, length 25
But you saw no response? Then that points your server not listening on that port, or running its own firewall, not using pfsense as its gateway?
You seeing the traffic being sent to where you forwarded it shows the forward working.. Not a pfsense issue..
-
I've been messing with various configs, swapped over to my PIA VPN, spammed the shit out steam connect and I saw every single click from PIA IP to my the server's LAN IP as passed traffic.
Any ideas what would be causing steam to not recognize the connection?
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
Any ideas what would be causing steam to not recognize the connection?
Because its not getting an answer.. As you showed pfsense sent the traffic to where you told it to send it, if there is no answer that is not anything pfsense can do about that..
If your server is connected to some vpn - then no it prob wouldn't work, because it most likely sent the answer out its vpn..
on your server run netstat, do you see that port listening?
-
I already know the port is listening, external clients can connect.
The reason I brought the VPN into the mix was because it was easy to see another external IP hit the server. I wasn't using the VPN before I made the comment showing that my traffic was indeed coming back.
Edit: I should clarify, the server has always been going out the WAN. I changed my client PC to go out the VPN for testing purposes only. My dynamic DNS points to my WAN, clients can connect to any game server I have up. I apologize if I confused the situation, I brought the VPN in for testing because at this point I'm just throwing mud at the wall.
-
I installed a fresh copy of pfsense onto a new drive, enabled nat reflection (pure nat), added my port forwards and steam recognized it via WAN IP. I'm now comparing xml's to see if I can spot the difference that is screwing me on the main pfsense install.
I noticed when I changed the fresh install's nat page to manual that it has 2 rules that my config does not have but I don't know what they mean. Preliminary google searches for a similar string were a mess to say the least.
WAN ::1/128 * * 500 (ISAKMP) WAN *
WAN ::1/128 * * * WAN address * [static port] -
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
I noticed when I changed the fresh install's nat page to manual
Why would you do that?
-
Simply because I wanted to see the differences.
I however just figured out the problem and it now works.
My default gateway is the WAN gateway but in firewall rules I selectively route based on device whether or not something goes out the WAN or VPN. Even though I had my client PC configured to go out the WAN gateway it wasn't until I changed it from WAN to default that it worked. Unreal! So for whatever reason nat reflection wants the rule as default not a selected gateway even if the selected gateway IS the default gateway.
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
Simply because I wanted to see the differences.
There is no difference - when you switch from auto to manual, it takes all the auto rules and just converts them to manual. Manual then allows you to edit those or delete, etc.
While there might be some odd ball configs that would require manual mode. Normally you can just do hybrid, which is the best of both worlds. Allows you to do what you want, for say a vpn or something our outbound on other interfaces for source natting reasons. And still get auto nats added if you add more lan side interfaces, etc.
-
I understand hybrid is ideal however at the time I created my PIA VPN (many years ago) the instructions were to use manual outbound and copy the rules but make needed changes for the VPN. I've just stuck with that over the years onto my current config. Hence why I wanted to see the differences on a fresh install and compare to my own.
-
Thank you for talking with me along the way. Someone to discuss with provides much needed feedback on the route of frustration when things don't work.
