PfSense blocking UDP for TeamViewer

markoweb · Dec 18, 2014, 12:29 PM

For some reason pfSense 2.1.x branch is blocking outgoing/incoming UDP connections for TeamViewer.

I have the latest TeamViewer 9 version installed on both sides and "Use UDP (recommended)" is ticked under Options -> Advanced -> Advanced networking.
If there is no pfSense between my side and remote host, then UDP is working fine.
Any combination of pfSense doesn't allow UDP connections to be created:
My Side -> Remote side => result
–-----------------------------------------

pfSense -> pfsense => TCP only
pfSense -> Cisco ASA => TCP only
Cisco ASA -> pfsense => TCP only
Cisco ASA -> Cisco ASA => UDP and TCP working
Linksys home router -> Cisco ASA => UDP and TCP working

All my pfSense installations are fairly simple. Default install, no packages, couple of port forwardings and that's it.
My outgoing LAN rules are defined like this:

Nothing special, only SMTP port is blocked from non e-mail servers. Even without that rule, UDP is still not working. I haven't tried outside of the 2.1.x branch, whether UDP works, all my pfSense installations are in the 2.1.x branch…
Status -> System Logs -> General and Firewall - don't show any connections being blocked when I'm trying to connect with TeamViewer.

Can someone help shine some light on this issue?
How can I diagnose this further?
How can I try to fix this issue?

kejianshi · Dec 18, 2014, 12:36 PM

Is UPNP enabled? If not, try enabling it.

markoweb · Dec 18, 2014, 5:29 PM

@kejianshi:

Is UPNP enabled? If not, try enabling it.

UPNP was not enabled. I enabled it and allowed both UPNP and NAT-PNP, but still UDP connection could not be established.
Also, I don't think TeamViewer uses UPNP. Status -> UPNP also showed that no ports were enabled/created at any time during the connection.
(I turned off my Win7 firewall for testing sake)

I googled a bit more and it seems that TeamViewer uses UDP hole punching to create a direct connection. In essence both parties at first talk to a proxy server via HTTPS/SSL, after PIN/Code verification the proxy server gives both clients each others IP-s, then both clients start sending UDP packets to each other.
Because I'm sending UDP packets out to a certain IP and I am getting UDP packets back from the same IP, a firewall should create an automatic pass through rule, but pfSense is blocking this for some reason. I actually saw some blocked UDP packets in the System -> Firewall logs now, from the same IP was connecting to (don't know how I missed this first time round).

Creating an inbound Firewall rule to allow UDP from all sources to all destinations got rid of the blocked messages in the Firewall log, but TeamViewer still couldn't create an UDP connection. Most likely because the proper NAT mappings have not been created, pfSense isn't forwarding the UDP packets to my machine.

So the question now becomes, how to enable UDP hole punching in pfSense?

markoweb · Dec 18, 2014, 5:45 PM

Okay, problem solved :)

The problem inherintly lies in pfSense rewriting the Source port.
To disable this feature I followed:
https://doc.pfsense.org/index.php/Static_Port

Instead of creating a new rule, I simply edited the existing "Auto created rule for Lan to Wan" and checked Static Port.
Now I get to have UDP connections with TeamViewer - yei :)

kejianshi · Dec 18, 2014, 8:45 PM

Wow - Yeah. Static port is not usually requred for teamviewer. I'm using teamviewer daily behind pfsense and I only have static port enabled for sip devices.

Glad its working, though.

phil.davis · Dec 19, 2014, 9:30 AM

Yeah, I use TeamViewer out of and into office LANs behind pfSense without doing anything special for it. I am surprised you had trouble. TeamViewer is usually like Skype - it is good at finding its way out from behind NAT…

markoweb · Dec 21, 2014, 1:48 PM

@kejianshi:

Wow - Yeah. Static port is not usually requred for teamviewer. I'm using teamviewer daily behind pfsense and I only have static port enabled for sip devices.

Glad its working, though.

You are right that static port is not usually required for TeamViewer. TeamViewer can work in such a case, but will simply revert to TCP connection.
The problem with TCP is that file transfers are ridiculously slow - hard limited to only 120 kb/s.
With UDP, file transfers get pretty much maximum speed. I guess TCP traffic has to go through TeamViewer proxy servers, that's why it is hard limited.
I suppose, regular remote control will also get a speed boost with UDP…