Create a firewall rule

Sorry for opening a new thread, but I need some information on howto establish a firewall rule. I already playing around for some days and also read through documentation and I still need help to understand what I have to do to allow teamviewer connections.

It would already help to know, if the rule has to be placed in rules, or local rules. And having ndpi installed if the ndpi service teamviewer has to be used, and/or if a service - lets call it teamviewer_port for port 5938 has to be created and used in the corresponding rule or local rule to be created. Or do I have to create a network service under system / settings instead in Firewall / Objects / Services?

And does it have to be a rule from red to red as Log showing IN=eth1 OUT=eth1 which for me does not make sense, or would it be green or local lan as source and red for destination??

The strange thing is that on different tries sometimes connection can be established, but soon after on a next try, there are blocked connections again in error log.

Folowing an example line of the connections, I try to allow, but that are still blocked by firewall:

Jul 14 15:52:17 nethhostname kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 MAC=aa:bb:cc:dd:ee:ff:gg:hh:ii:jj:kk:ll:mm:nn SRC=1.2.3.4 DST=188.172.251.40 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=4862 DF PROTO=TCP SPT=55628 DPT=5938 WINDOW=64240 RES=0x00 SYN URGP=0

DST= always changes for the further log entries…

Thanks for your help.

Usually you don’t need any firewall settings when using teamviewer.
Did you allow traffic to and ping from internet in the firewall settings?
TV connects to their own server so it uses port 5938 outgoing, if not possible 443, if not possible 80 and therefore you do not need to open ports on the Nethserver to the world except you disallowed traffic to internet.

Maybe ping is needed for teamviewer to work…

image

Please post your firewall settings:

config show firewall

Thanks for your info mrmarkuz. I read in a post from @filippo_carletti, that ndpi (which I have installed) would block TV.

config show firewall:
firewall=configuration
CheckIP=8.8.8.8,208.67.222.222
Docker=disabled
ExternalPing=enabled
HairpinNat=enabled
MACValidation=enabled
MACValidationPolicy=drop
MaxNumberPacketLoss=10
MaxPercentPacketLoss=50
NotifyWan=disabled
NotifyWanFrom=
NotifyWanTo=
PingInterval=5
Policy=permissive
VpnPolicy=strict
WanMode=balance

I tried with the following rule.
Teamviewer_rule

Instead of the service created for 5938 I tried the builtin (ndpi) teamviewer service too. I also tried with red, green or the host as source but nothing really helps.

Symptom: sometimes connection is established immediately, but then again with the same rule, the log fills with blocked connections to dst port 5938 - similar to the example on initial post, so I am lost…

shorewall clear lets me immediately connect, so it must have something to do with firewall/shorewall/deep packet inspection?

Your firewall settings look correct so please remove all rules and services you created for allowing TV because you don’t need any firewall rule for Teamviewer because it only uses outgoing ports.

If you want to block TV you may use ndpi but it’s allowed out of the box.

Are you using a proxy? Maybe you need to tell TV about that proxy or disable the proxy for testing…

I only have this one rule, and already tested without, but same thing, thats why I started trying to create a rule in the first place, but ok, I will remove it and test again. I use transparent proxy, and already have tested with disabled proxy, but will test again and report back. I have also put *.teamviewer.com in: Filter / Bearbeiten / whitelist for global domain and whitelist for blocked url in proxy settings.

Do I misinterpred filippo’s post? I understand that ndpi would block TV. Should I try to disable ndpi? Which packages would I have to uninstall for that?

Tested with disabled proxy & filter -> same thing, firewall log produces blocked lines as in first post for dpt=5938.

The OP in this thread wanted to block TV so Filippo recommended ndpi to block it. If you setup a rule using ndpi you are able to block TV, it does not block it automatically.

Do you have a port forward with port 5938? Please remove it.

no, I haven’t. I only have a port forward for rdp port, which doesnt work anyway. I remove it and test again. Same thing. Still blockers on 5938

Do you have another router blocking ping or internal traffic?

the red network is connected to a zywall router as are the clients, but zywall does nothing on this network, especially not outbound. Even dhcp is not serrved by zywall router, as this firewall is the dhcp server for this network. And the firewall logs of this nethserver which acts as firewall are filled with blocked 5938 traffic, so I don’t think its the zywall router. So you are sure ndpi does not block it out of the box? Does it make sense to uninstall deep packet inspection to see if this is the source of the problem?

Let’s check the firewall rules first:

db fwrules show

Let’s check if port is used by a service:

config show | grep 5938

This may be ok as first 5938 is tried from TV, if it does not work it tries 443, then 80.

db fwrules show is empty

Well it sometimes works, but takes long and it does not work always so I would prefer it works with 5938. Because if it does not work, after that attempt to connect to a teamviewer session. Access from this client to the firewall itself thus to internet is completely blocked. That means, I cannot access this nethserver webinterface anymore and cannot access internet ressources. The connection is re-established after either a reboot or shorewall clear on the firewall from another desktop. Thats unacceptable in prod environnement where we rely on teamviewer to help our customers.

config show | grep 5938 -> nothing

I’m sorry. TV usually just works without configuration.

Can you reproduce the issue on an other desktop? Maybe it’s a client problem?

Did you check fail2ban if the client is blocked?

Yes its reproduceable from other desktops. This firewall has no fail2ban installed, as it is on internal lan. We have another nethserver which is hosted and connected through ipsec from zywall to external nethserver. That external nethserver has nextcloud and mailservices installed, thus fail2ban. But it does not control the internal lan, thus does not block internal ressources anyway.

As there is only one physical network available, but nethserver firewall needs two networks, I workarounded it as follows:

On ProxMox I have configured two nics for nethserver firewall, both on same vmbr0. On nethserver I confiured one as green network: 192.168.X.0/25 - translates to subnet mask 255.255.255.128, and red interface on the second nic with 192.168.X.249/29 - translates subnet mask 255.255.255.248 - where 192.168.X.254 is the gateway to internet (the ip of zywall which connects to internet). All clients get dhcp from green. I don’t see why this could be a problem, as.everything else works as intended, but this might explain the log entries :IN=eth1 OUT=eth1, or is this normal anyway?

Hi Ellini,

When I have problem connecting, I usually clear both caches: browser & Station. Most of the time it resolves the conflict.

ipconfig /flushdns

There are Blacklist & Opening Sessions in TeamViewer under Security → Connection rule.
Under Advanced there are → Access Control & TeamViewer Options.

Michel-André

2 Likes

I uninstalled nethserver-ndpi and did yum autoremove to remove its dependency too, and there is still the same behaviour, so its obviously not ndpi that causes this, so I reinstalled deep packet inspection. And deleted the created rule.

I also did an ipconfig /flushdns and checked teamviewer settings/sessions. There is nothing blacklisted, and the security connection rules and access controlls are standard, nothing was changed there. I have to do further testing, but it seems to have improved the situation! It connects - sometimes immediately, sometimes I have to wait a while until the popup for the passowrd appears. I still have some entries in firewall log about blocked port 5938. Do you see this entries in log too? Maybe this entries are normal and can be ignored after all? Thanks for your input much apreciated. :+1:

We will do some further testing, but flushing dns cache could be the solution after all. :slight_smile:

I hope the flushdns works for you but I’m afraid it doesn’t.

I tested with VMWare and was able reproduce your issue. TV had sometimes no connection, sometimes timeout, sometimes working, a lot of entries in firewall.log.

I think at least the first point makes shorewall go crazy:

  • same bridge on proxmox for both LAN and WAN
  • using non-default subnetted networks in this bridged scenario

After setting LAN and WAN to 2 different network interfaces in virtualization instead of one bridge and changing networks to 192.168.X.Y/24 it just worked without firewall.log entries.

You may change internal zywall IP and external Neth IP to different /24 networks so there should be no need to configure more.

2 Likes

I only have one nic in that proxmox available (the second physical nic will serve for storage replication once we get our second proxmox installed). On the zywall which serves as gateway to internet there is a /24 network defined, lets say 192.168.11.0/24 where 192.168.11.254 would be the ip of zywall as internet gateway thus it must be in the range of nethserver’s red interface. All clients are attached via a switch to this same port. Do I understand you correctly that it would work, when I create a vmbr1 in proxmox lets say with 192.168.12.0/24 and configure green neth on this one? I was under the impression that it has to be in the same network, defined in zywall 192.168.11.0/24 in this example. Thats why I have done the separate /25 /29 networks in the first place :slight_smile: I will test, but have to do this after my vacations and probably during a weekend as the system is prod right now.

Flushdns did help a bit, I still get errors in firewall log, but about 20 connection tests worked - once quicker, once with some delay.

I will report back with my findings. Thanks a lot for taking the time to reproduce and report here!!

1 Like

Yes, exactly.

1 Like