Score:0

UDP packets on port 10000 and TCP packets on port 4443 do not reach external jitsi server

ca flag

I need help in the configuration of the following scenario: The web browsing of a small institutional network is done through a proxy server with authentication configured in a Debian as proxy / firewall (using iptables rules) and connected to a parent proxy. The clients of the LAN do not make any type of DNS query to the outside because all the web browsing is through the proxy and some other type of access to external service was not needed. Now: we must access a jitsi server at the specific IP address xxx.xxx.xxx.xxx. The web access to that jitsi server is fine in the sense that the proxy takes care of it, but the packets to UDP ports 10000 and TCP 4443 respectively, I have not managed to handle them in the iptables rules.

The network scheme is as follows:

LAN on eth0 (192.168.0.0/24) ---- (192.168.0.1 ens18)debian proxy/firewall(192.168.1.2 ens19) -- (192.168.1.1)MODEM ROUTER---->ISP

The iptables rules are as follows:

 *filter
    :FORWARD DROP [0:0]
    :INPUT DROP [0:0]
    :OUTPUT DROP [0:0]
    # ##### INPUT chain ###### Accept relate or stablished connections
    -A INPUT -m conntrack ! -i lo --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
    -A INPUT -p udp -m udp -m conntrack --dport 33434:33534 --ctstate NEW -j REJECT
    # Anti spoofing rule
    -A INPUT ! -s 192.168.0.0/24 -i ens18 -j LOG  --log-prefix "SPOOFED PKT "
    -A INPUT ! -s 192.168.0.0/24 -i ens18 -j DROP
    # LAN TO PROXY LOCAL
    -A INPUT -p tcp -m state -s 192.168.0.0/24 -i ens18 --dport 8080 --state NEW -j ACCEPT
    # ACCESS TO WEB REPORTS
    -A INPUT -p tcp -m state -s 192.168.0.2/24 -i ens18 --dport 80 --state NEW -j ACCEPT
    # ACCESS TO SSH
    -A INPUT -p tcp -m state -s 192.168.0.2/24 -i ens18 --dport 22 --state NEW -j ACCEPT
    # TIME SYNC FOR LAN
    -A INPUT -p udp -i ens18 -m state --sport 123 --state NEW -j ACCEPT
    # WEBMIN ACCESS
    -A INPUT -p tcp -m state -s 192.168.0.2/24 -i ens18 --dport 10000 --state NEW -j ACCEPT
    # LOG the rest and drop by default input chain
    -A INPUT ! -i lo -j LOG  --log-prefix "DROP INPUT " --log-ip-options --log-tcp-options
    -A OUTPUT -m state --state INVALID -j LOG  --log-prefix "DROP INVALID " --log-ip-options --log-tcp-options
    -A OUTPUT -m state --state INVALID -j DROP
    -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    # ##### OUTPUT chain ###### ## ACCEPT rules for allowing connections out
    -A OUTPUT -p tcp -m state --dport 21 --state NEW -j ACCEPT
    -A OUTPUT -p tcp -m state --dport 80 --state NEW -j ACCEPT
    -A OUTPUT -p tcp -m state --dport 443 --state NEW -j ACCEPT
    -A OUTPUT -p udp -m state --dport 123 --state NEW -j ACCEPT 
    
     # external DNS servers (only reachable, no recursion enabled) 
    -A OUTPUT -p udp -m state -d XXX.XXX.XXY.131 --dport 53 --state NEW -j ACCEPT
    -A OUTPUT -p tcp -m state -d XXX.XXX.XXX.132 --dport 53 --state NEW -j ACCEPT
    
    -A OUTPUT -m state -d XXX.XXX.XXX.68 --state NEW -j ACCEPT
    **# TRYING TO REACH JITSI SERVER
    -A OUTPUT -m state -d XXX.XXX.ZXX.XXX --state NEW -j ACCEPT**
    -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
    # ##### FORWARD chain ###### Accept relate or stablished connections
    -A FORWARD -m state --state INVALID -j LOG  --log-prefix "DROP INVALID " --log-ip-options --log-tcp-options
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A FORWARD ! -s 192.168.0.0/24 -i ens18 -j LOG  --log-prefix "SPOOFED PKT "
    -A FORWARD ! -s 192.168.0.0/24 -i ens18 -j DROP
    
    # prevent forwarding packets for connections initiated from the outside (spoofing)
    -A FORWARD -m state -i ens19 --state NEW -j DROP
    # ## default log rule
    -A FORWARD ! -i lo -j LOG  --log-prefix "DROP FORWARD " --log-ip-options --log-tcp-options
    COMMIT
    # Completed
    # Generated by webmin
    *mangle
    :OUTPUT ACCEPT [0:0]
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    COMMIT
    # Completed
    # Generated by webmin
    *nat
    :OUTPUT ACCEPT [0:0]
    :INPUT ACCEPT [0:0]
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    
    # SOURCE NAT FOR LAN NETWORK ON
    -A POSTROUTING -o ens19 -j SNAT --to-source 192.168.1.2
    # MASQUERADE (FOR DYNAMIC IP ADDRESSS IN CASE OF DHCP MODEM)
    -A POSTROUTING -s 192.168.0.0/24 -o ens19 -j MASQUERADE
    
    COMMIT
    # Completed

**** something interesting with these same firewall rules: we can access to videoconferences on the server https://meet.jit.si without problems. The jitsi server administrator at xxx.xxx.xxx.xxx argues that only need access to ports UDP 10000 and TCP 4443 as i explained, and of course 443 (which is handled by the network proxy)

anx avatar
fr flag
anx
Don't block ICMP & ICMPv6 traffic (if you have, to block the specific message types that your LAN devices do not handle the way they should).
anx avatar
fr flag
anx
It does not seem obvious what is going on, acquire more diagnostics. You could use additional rules in your iptables configuration to check their packet counters, you could watch traffic on your router, you could run some form of tcptraceroute, you could check your browser devtools to confirm that the jitsi instance that does work through your firewall really uses similar ports as the instance you are failing to get to work, ..
Francisco avatar
ca flag
@anx: OK, I'm going to open icmp traffic, and traffic to ports 3478 UDP and 5349 TCP (taken from https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart) just in case of my external jitsi admin has forgotten that detail
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.