Question

Hi - I’ve purchased 2 new RUT950 devices for remote ports in our company.

Because our 4G provider only supplies internal NATd IPs that I can’t remotely access I have configured an OpenVPN connection from the RUT950 in to our corporate network and then I route back over this connection to the remote network.  This is currently working and I have verified I can access the desktop of the remote machines from within the head office network.

I wanted to tighten down the firewall to only allow certain access back in to the remote network but nothing I do in the RUT950 firewall blocks traffic from the head office network to the RUT950.

I have created a port 22 block rule from the OpenVPN ‘zone’ to the LAN ‘zone’ but I’m still able to ssh to the RUT950 from a PC within the head office. Obviously I’m getting zones messed up.

Network is as follows:

RUT950 (192.168.16.0/24)—OpenVPN subnet (10.9.0.0/24)—Head Office (192.268.5.0/24)

As it stands I can access 192.168.16.1(RUT950 interface) from a PC (192.168.5.108) within Head Office.

I don’t really understand what the three rules on the firewall page are doing (INPUT, OUTPUT, FORWARD - set to ACCEPT, ACCEPT, REJECT)

I can post configs if someone can tell me what would help troubleshoot.

Comments

I have spent more hours on this today and I just can;y understand it. I am used to the zone based firewalls in Ubiquiti EdgeRouter devices but this just doesn't make sense to me.

Below is a diagram of what I have set up:

I am connected via an OpenVPN tunnel with an assigned, routable IP, 10.8.0.2. I am trying to block access to resources behind the RUT950 at 192.168.16.1.

---

The test I am using is accessing a HTTP web interface on the printer at 192.168.16.51.

I don't understand what these three settings do:

I expected that if there were no rules in the 'chain' then the packets would fall out the end and get caught by one of these. I set all to "Reject" but I could still access the web interface on the printer at 192.168.16.51:

Nothing I do will allow me to stop traffic getting to the RUT950 interface for HTTP/HTTPS and SSH or ICMP.

I don't know what 'zone' my VPN traffic is on that comes from beyond the 10.9.0.0/24 or 10.8.0.0/24 OpenVPN subnets.

---

I have set the default INPUT policy to REJECT

I don't understand why/how traffic can be getting to the 192.168.16.1 SSH port (TCP 22) with the rules set below. As you can see I have NO explicit rule set to allow SSH on port 22 yet I am still able to SSH the RUT950 from the VPN.

❯ ssh SYD-RUT950
Warning: Permanently added '192.168.16.1' (RSA) to the list of known hosts.

BusyBox v1.30.1 () built-in shell (ash)

   ____        _    ___  ____        _(_)_
  |  _ \ _   _| |_ / _ \/ ___|      (_)@(_)
  | |_) | | | | __| | | \___ \       /(_)
  |  _ <| |_| | |_| |_| |___) |    \|/
  |_| \_\\__,_|\__|\___/|____/     \|/

Teltonika RUT9XX 2014 - 2019

root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~#
root@SYD_RUT950:~# iptables -S INPUT
-P INPUT DROP
-A INPUT -j delegate_input
root@SYD_RUT950:~# iptables -S delegate_input
-N delegate_input
-A delegate_input -i lo -j ACCEPT
-A delegate_input -m comment --comment "user chain for input" -j input_rule
-A delegate_input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_input -m conntrack --ctstate INVALID -j DROP
-A delegate_input -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood
-A delegate_input -i br-lan -j zone_lan_input
-A delegate_input -i wwan0 -j zone_wan_input
-A delegate_input -i tun_+ -j zone_vpn_input
-A delegate_input -i l2tp+ -j zone_l2tp_input
-A delegate_input -i ppp+ -j zone_l2tp_input
-A delegate_input -i pptp+ -j zone_pptp_input
-A delegate_input -i gre+ -j zone_gre_input
-A delegate_input -i tun0 -j zone_hotspot_input
-A delegate_input -i tun1 -j zone_hotspot_input
-A delegate_input -i tun2 -j zone_hotspot_input
-A delegate_input -i tun3 -j zone_hotspot_input
-A delegate_input -j reject
root@SYD_RUT950:~# iptables -S zone_vpn_input
-N zone_vpn_input
-A zone_vpn_input -m comment --comment "user chain for input" -j input_vpn_rule
-A zone_vpn_input -p tcp -m tcp --dport 80 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -p tcp -m tcp --dport 443 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_vpn_input -j zone_vpn_src_ACCEPT
root@SYD_RUT950:~# iptables -S input_vpn_rule
-N input_vpn_rule
root@SYD_RUT950:~# iptables -S zone_vpn_src_ACCEPT
-N zone_vpn_src_ACCEPT
-A zone_vpn_src_ACCEPT -i tun_+ -j ACCEPT
root@SYD_RUT950:~#

Answer 1

So I have found a fix, not sure if it permanent or not but can't find a way to fix via luci UI.

In /etc/config/firewall there is a section that affects the iptables zone_vpn_input chain.

Changing ACCEPT to REJECT and reloading the firewall then set the REJECT chain for the vpn INPUT as expected.

In /etc/config/firewall I changed option input 'ACCEPT' to option input 'REJECT'

config zone 'vpn_zone'
        option name 'vpn'
        option input 'REJECT'
        option output 'ACCEPT'
        option network 'vpn'
        option device 'tun_+'
        option forward 'REJECT'
        option masq '1'

Reload the firewall:

/etc/init.d/firewall reload

Which resulted in the REJECT at the bottom of the zone_vpn_input chain:

root@SYD_RUT950:~# iptables -S zone_vpn_input
-N zone_vpn_input
-A zone_vpn_input -m comment --comment "user chain for input" -j input_vpn_rule
-A zone_vpn_input -p tcp -m tcp --dport 80 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -p tcp -m tcp --dport 443 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -p tcp -m tcp --dport 22 -m comment --comment "Allow-VPN to local SSH" -j ACCEPT
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_vpn_input -j zone_vpn_src_REJECT

Comments

I have just found that using UCI I can do the same thing:

uci set firewall.vpn_zone.input='REJECT'
uci commit
/etc/init.d/firewall reload 

Answer 2

Hello,

Instead changing general settings, try creating Traffic Rules in router's firewall, which should prevent reaching devices behind the router on certain ports, or router itself when connecting via certain interface.

To create new rule, simply navigate to Traffic Rules submenu in Firewall menu and in New Forward Rule section create a traffic rule, by entering the name and selecting the interfaces:

Once pressed "Add", you will be redirected to Traffic Rule configuration window, which allows to select more options, like protocol, port, IP and etc.

Here you can select rules to block traffic coming from OpenVPN interface to certain device's port.

E.g.  to block ability to reach printer on http port from openvpn interface, the rule should look similar to below:

Comments

But that's not how iptables works. The 'default' policy to DROP should be applied UNLESS a rule in the chain is matched. Doing it this way I would have to set explicit DROPs for any and all traffic I don't want to pass the firewall.

---

Can you take the screenshot of your router's Zone Forwarding section?

---

Here's the screenshot of the zone forwarding screen.

I think the issue is here, the iptables rules are allowing the traffic:

root@SYD_RUT950:~# iptables -S zone_vpn_input
-N zone_vpn_input
-A zone_vpn_input -m comment --comment "user chain for input" -j input_vpn_rule
-A zone_vpn_input -p tcp -m tcp --dport 80 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -p tcp -m tcp --dport 443 -m comment --comment "Allow-VPN to RUT950 UI" -j ACCEPT
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_vpn_input -j zone_vpn_src_ACCEPT
root@SYD_RUT950:~# iptables -S zone_vpn_src_ACCEPT
-N zone_vpn_src_ACCEPT
-A zone_vpn_src_ACCEPT -i tun_+ -j ACCEPT

I need to find how to raise a support request with Teltonika as I believe its a bug.

This issue is not with forwarding, its on the INPUT chain.

The FORWARD chain is below and you can see it cascades down to a REJECT rule as expected.

root@SYD_RUT950:~# iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -j delegate_forward
root@SYD_RUT950:~# iptables -S delegate_forward
-N delegate_forward
-A delegate_forward -m comment --comment "user chain for forwarding" -j forwarding_rule
-A delegate_forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A delegate_forward -m conntrack --ctstate INVALID -j DROP
-A delegate_forward -i br-lan -j zone_lan_forward
-A delegate_forward -i wwan0 -j zone_wan_forward
-A delegate_forward -i tun_+ -j zone_vpn_forward
-A delegate_forward -i l2tp+ -j zone_l2tp_forward
-A delegate_forward -i ppp+ -j zone_l2tp_forward
-A delegate_forward -i pptp+ -j zone_pptp_forward
-A delegate_forward -i gre+ -j zone_gre_forward
-A delegate_forward -i tun0 -j zone_hotspot_forward
-A delegate_forward -i tun1 -j zone_hotspot_forward
-A delegate_forward -i tun2 -j zone_hotspot_forward
-A delegate_forward -i tun3 -j zone_hotspot_forward
-A delegate_forward -j reject
root@SYD_RUT950:~# iptables -S zone_vpn_forward
-N zone_vpn_forward
-A zone_vpn_forward -m comment --comment "user chain for forwarding" -j forwarding_vpn_rule
-A zone_vpn_forward -p tcp -m tcp --dport 5900 -m comment --comment "Allow-VNC to LAN VNC" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -p icmp -m comment --comment "Allow-VPN to LAN ICMP" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -p tcp -m tcp --dport 80 -m comment --comment "Allow-VPN HTTP/HTTPS" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -p tcp -m tcp --dport 443 -m comment --comment "Allow-VPN HTTP/HTTPS" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_vpn_forward -j zone_vpn_src_REJECT
root@SYD_RUT950:~# iptables -S zone_vpn_src_REJECT
-N zone_vpn_src_REJECT
-A zone_vpn_src_REJECT -i tun_+ -j reject
root@SYD_RUT950:~#

---

If I add the destination zone back in it then ignores the firewall rules completely:

❯ nc -vz 192.168.16.51 80
found 0 associations
found 1 connections:
     1:    flags=82<CONNECTED,PREFERRED>
    outif utun10
    src 10.8.0.3 port 61911
    dst 192.168.16.51 port 80
    rank info not available
    TCP aux info available

Connection to 192.168.16.51 port 80 [tcp/http] succeeded!

Thanks to this  -A zone_vpn_forward -m comment --comment "forwarding vpn -> lan" -j zone_lan_dest_ACCEPT

root@SYD_RUT950:~# iptables -S zone_vpn_forward
-N zone_vpn_forward
-A zone_vpn_forward -m comment --comment "user chain for forwarding" -j forwarding_vpn_rule
-A zone_vpn_forward -p tcp -m tcp --dport 5900 -m comment --comment "Allow-VNC to LAN VNC" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -p icmp -m comment --comment "Allow-VPN to LAN ICMP" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -m comment --comment "forwarding vpn -> lan" -j zone_lan_dest_ACCEPT
-A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_vpn_forward -j zone_vpn_src_REJECT
root@SYD_RUT950:~#