Teamspeak 3 Wont Allow Connections
-
Tried rebooting still wont allow anyone in. Now it doesn't even show incoming connections on the system log->firewall. It does keep showing LAN connections every time anyone tries to connect.
-
Did you nuke the 30033 forward? I don't see a corrisponding rule for it in that pic, but I do see two separate ones for 10011
-
Changed it. Check these photos out. Still nothing
EDIT I changed the 10011 on the port forward one
-
That WAN thing is still wrong. You did NOT change the NAT ports, only the destination port.
-
Please see the edit. I changed the wan 10011 to 30033
-
No. You only changed it in one place. Look at the NAT Ports field!
-
Yes I did. Here
-
Wonderful. Now, either reset the states or reboot the box.
-
Rebooted still cant get clients =\
-
Sucks to be you. Produce some packet captures.
-
I'm trying to understand your setup. Modem–--> Into NIC #1 into a virtual machine that uses that port dedicated *no bridge the connections go out of it through ----> NIC# 2 the lan port which is bridged ----> into a switch
do you mean that pfsense is virtualized or is it on bare metal, and when you say it uses a dedicated port no bridge do you mean it's a virtual nic?Secondly is your modem a full modem, not one of the generic modem/router combo devices isp's like to give out? If it is one of those combo devices then you'll have to configure it to port forward to the pfsense box.
-
In this post:
https://forum.pfsense.org/index.php?topic=94117.msg523417#msg523417
You do not have a rule on WAN for 30033.
I don't know if you are using the linked rules from your port forwards or not.
This stuff really does "just work."
-
And the most current settings.
-
From: https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
Common Problems
1. NAT and firewall rules not correctly added (see How can I forward ports with pfSense?)
Hint: Do NOT set a source port
2. Firewall enabled on client machine
3. Client machine is not using pfSense as its default gateway
4. Client machine not actually listening on the port being forwarded
5. ISP or something upstream of pfSense is blocking the port being forwarded
6. Trying to test from inside the local network, need to test from an outside machine
7. Incorrect or missing Virtual IP configuration for additional public IP addresses
8. The pfSense router is not the border router. If there is something else between pfSense and the ISP, the port forwards and associated rules must be replicated there.
9. Forwarding ports to a server behind a Captive Portal. An IP bypass must be added both to and from the server's IP in order for a port forward to work behind a Captive Portal.
10. If this is on a WAN that is not the default gateway, make sure there is a gateway chosen on this WAN interface, or the firewall rules for the port forward would not reply back via the correct gateway.
11. If this is on a WAN that is not the default gateway, ensure the traffic for the port forward is NOT passed in via Floating Rules or an Interface Group. Only rules present on the WAN's interface tab under Firewall Rules will have the reply-to keyword to ensure the traffic responds properly via the expected gateway.
12. If this is on a WAN that is not the default gateway, make sure the firewall rule(s) allowing the traffic in do not have the box checked to disable reply-to.
13. If this is on a WAN that is not the default gateway, make sure the master reply-to disable switch is not checked under System > Advanced, on the Firewall/NAT tab.
14. WAN rules should NOT have a gateway set, so make sure that the rules for the port forward do NOT have a gateway configured on the actual rule.
15. If the traffic appears to be forwarding in to an unexpected device, it may be happening due to UPnP. Check Status > UPnP to see if an internal service has configured a port forward unexpectedly. If so, disable UPnP on either that device or on the firewall.
-
Here is what the packet capture got for host 10.30.150.13 with the ts3 server. Attached is the LAN segment but the WAN showed no traffic for udp 9987
-
2. Firewall enabled on client machine
Did you even go through that list?
-
When people connect are they using a domain address like ts.example.com or an IP address? If they are using only the domain address try using the IP address (the public one on the WAN).
-
Yes I have went through the last already.
What firewall does Ubuntu have?
Ubuntu , as with all post 2.2/2.4 kernel Linux distributions comes with the netfilter/iptables framework. This framework is a set of kernel modules that can be utilized to create packet filtering rules at the kernel level. Rules are written in iptables format, which is the method of conveyance of instructions to netfilter, and in essence the Linux Kernel.
Ubuntu also includes an application called Uncomplicated FireWall (UFW). This application is a userspace application that essentially can be used to create iptables rules. There is also a GUI for UFW called GUFW. It provides a graphical interface for UFW. Again remember, UFW is simply writing iptables rules and sending them off to netfilter, and thus the kernel. It is NOT a firewall in and of itself.
There are other applications such as Firestarter, which essentially cover the same ground as UFW. The Firestarter project is out of development, and was bug prone even when it was developed actively. I do not recommend it, and it is not the default thus it will not be covered. It is important to know that there is nothing that Firestarter can do that you can not do with either UFW or by interacting directly with iptables.
You need to realize that Ubuntu's firewall is not enabled by default. You have to enable it.
The ts3 is on ubuntu. No firewall.
-
When people connect are they using a domain address like ts.example.com or an IP address? If they are using only the domain address try using the IP address (the public one on the WAN).
Not using domain using IP
-
Well I only have this to say:
If the ports forwarded are the proper ports and you have gone through everything on that list it would be working.
I finger the local firewall on the host because there is no return traffic from .13 in your packet capture. That or it's not really listening on that port. Or you deliberately set the packet capture so it wouldn't display reply traffic.
