UDP blocked - NAT reflection unable to connect over UDP
-
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.
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
the instructions were to use manual outbound
Yeah those instructions are sub optimal, and horrible advice.. And causes a lot of issues when users add new networks/vlans and don't understand why they don't work ;)
And users always fail to mentioned that they are even using a vpn or that their outbound was put into manual, and then come here asking why xyz doesn't work ;)
-
Well at least in my scenario the manual outbound and vpn had no impact. I specifically removed the vpn from the equation so that it wouldn't be an issue.
I just can't believe that the nat reflection requires the gateway to be set as default even if the chosen gateway is the default. Hopefully someone down the road finds this thread and it helps them.
-
@horizon82 said in UDP blocked - NAT reflection unable to connect over UDP:
manual outbound and vpn had no impact
It wouldn't have an impact unless you messed with them, or added another network and not an outbound nat and then wondered why it wasn't working ;)
Its just bad setup to switch to manual, and then create the nat required for the vpn, when you could just add the hybrid nat for the vpn..
I don't use nat reflection, since in my opinion its an abomination to all things networking ;) Now in some instances true it can be useful. When some client is is hard coded to use a public IP, or when it is using external dns and no way to have it use internal for whatever reason.
As to having to set a default gateway, might have to do with having a vpn setup which your pulling routes with and it gets set as the default gateway regardless of what might be shown in the gui.. Again more bad advice from the vpn providers - but then again they want you to send all traffic to them, not just the traffic you want to send.
