[Solved] Opening ports in firewall configs not working as expected

dit_dah_dit · January 13, 2019, 5:16am

Greetings,

I have a Netgear R8000 running LEDE 17.01.6. I am unable to update to OpenWrt 18.06.x quite yet because the NUT package is currently broken in 18.06.1 for my hardware.

I am trying to figure out how the /etc/config/firewall file works in terms of opening up ports on the WAN interface. Here is what my current file looks like:

/etc/config/firewall

config defaults
        option syn_flood        1
        option input            ACCEPT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

config rule
        option name             Allow-IGMP
        option src              wan
        option proto            igmp
        option family           ipv4
        option target           ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option src_ip           fc00::/6
        option dest_ip          fc00::/6
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-MLD
        option src              wan
        option proto            icmp
        option src_ip           fe80::/10
        list icmp_type          '130/0'
        list icmp_type          '131/0'
        list icmp_type          '132/0'
        list icmp_type          '143/0'
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-IPSec-ESP
        option src              wan
        option dest             lan
        option proto            esp
        option target           ACCEPT

config rule
        option name             Allow-ISAKMP
        option src              wan
        option dest             lan
        option dest_port        500
        option proto            udp
        option target           ACCEPT

# include a file with users custom iptables rules
config include
        option path /etc/firewall.user

### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#       option src              lan
#       option src_ip           192.168.45.2
#       option dest             wan
#       option proto            tcp
#       option target           REJECT

# block a specific mac on wan
#config rule
#       option dest             wan
#       option src_mac          00:11:22:33:44:66
#       option target           REJECT

# block incoming ICMP traffic on a zone
#config rule
#       option src              lan
#       option proto            ICMP
#       option target           DROP

# port redirect port coming in on wan to lan
#config redirect
#       option src                      wan
#       option src_dport                80
#       option dest                     lan
#       option dest_ip                  192.168.16.235
#       option dest_port                80
#       option proto                    tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#       option src              wan
#       option src_dport        22001
#       option dest             lan
#       option dest_port        22
#       option proto            tcp

### FULL CONFIG SECTIONS
#config rule
#       option src              lan
#       option src_ip           192.168.45.2
#       option src_mac          00:11:22:33:44:55
#       option src_port         80
#       option dest             wan
#       option dest_ip          194.25.2.129
#       option dest_port        120
#       option proto            tcp
#       option target           REJECT

#config redirect
#       option src              lan
#       option src_ip           192.168.45.2
#       option src_mac          00:11:22:33:44:55
#       option src_port         1024
#       option src_dport        80
#       option dest_ip          194.25.2.129
#       option dest_port        120
#       option proto            tcp

which is basically the default file that comes with LEDE/OpenWrt out of the box. What I don’t understand is why this stanza

config rule
	option name		    Allow-ISAKMP
	option src			wan
	option dest			lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

is not considered by OpenWrt's firewall to be opening up port 500. When I run a port scan from the outside, port 500/UDP is showing up as being closed.

What confuses me is that if I add the following rule:

config rule
	option name		    Allow-SSH-WAN
	option src			wan
	option dest_port	22
	option proto		tcp
	option target		ACCEPT

and reload the firewall (/etc/init.d/firewall reload), then I am able to SSH into the router from outside, as expected. Also, a port scan shows port 22/TCP as being open. However, if I then either add a rule or modify the original rule to be:

config rule
	option name		    Allow-ISAKMP-TCP
	option src			wan
	option dest_port	500
	option proto		tcp
	option target		ACCEPT

Following a firewall reload, a port scan is still showing port 500/TCP as being closed. What am I not understanding? How does this last rule differ from my SSH rule, besides the name and port numbers?

rj-45 · January 13, 2019, 7:19am

I think it is closed, because no service/daemon is listening on that port.

mpa · January 13, 2019, 12:47pm

Please note that with option dest lan, the rule applies to FORWARD (hosts on the LAN), while without it, the rule applies to INPUT (the router itself). You can see the results yourself with iptables-save.

Which service are you trying to set up, and on which host?

dit_dah_dit · January 13, 2019, 7:11pm

Which service are you trying to set up, and on which host?

I am trying to set up an IKEv2 VPN server using strongswan on the router, so that I can connect to individual computers inside my network from the outside through the VPN (road warrior setup). In terms of what @rj-45 was saying, I would have thought that the IPsec daemon would be listening on port 500 (and also port 4500 for the NAT-T), but that doesn't appear to be the case. Despite strongswan being up and running, the port is showing up as being closed. Hence my confusion.

dit_dah_dit · January 13, 2019, 7:19pm

Please note that with option dest lan , the rule applies to FORWARD (hosts on the LAN), while without it, the rule applies to INPUT (the router itself). You can see the results yourself with iptables-save .

I had suspected that this was the case, which is why there was no option dest lan in the last rule in my OP that I was using for testing.

vgaetera · January 13, 2019, 7:28pm

netstat -anp | grep ipsec

mpa · January 13, 2019, 11:22pm

dit_dah_dit:

config rule
        option name         Allow-ISAKMP-TCP
        option src          wan
        option dest_port    500
        option proto        tcp
        option target       ACCEPT

For IKEv2, replace tcp with udp, and perhaps add port 4500.
I am not aware of any IKE variant based on TCP.

dit_dah_dit · January 14, 2019, 1:14am

Well, strongswan doesn't actually have a daemon called ipsec, but running netstat -anp | grep charon returns the following:

udp        0      0 0.0.0.0:68              0.0.0.0:*                           4443/charon
udp        0      0 0.0.0.0:4500            0.0.0.0:*                           4443/charon
udp        0      0 0.0.0.0:500             0.0.0.0:*                           4443/charon
udp        0      0 :::4500                 :::*                                4443/charon
udp        0      0 :::500                  :::*                                4443/charon
raw   165184      0 0.0.0.0:17              0.0.0.0:*               17          4443/charon
unix  2      [ ACC ]     STREAM     LISTENING     9810891 4443/charon         /var/run/charon.xml
unix  2      [ ACC ]     STREAM     LISTENING     9810895 4443/charon         /var/run/charon.wlst
unix  2      [ ACC ]     STREAM     LISTENING     9810897 4443/charon         /var/run/charon.dck
unix  2      [ ACC ]     STREAM     LISTENING     9810921 4443/charon         /var/run/charon.ctl
unix  2      [ ]         DGRAM                    9810814 4443/charon

which seems to imply that the charon daemon is indeed listening on ports 500 and 4500.

dit_dah_dit · January 14, 2019, 1:20am

mpa:

dit_dah_dit:

I would have thought that the IPsec daemon would be listening on port 500 (and also port 4500 for the NAT-T), but that doesn't appear to be the case.
dit_dah_dit:
config rule
        option name         Allow-ISAKMP-TCP
        option src          wan
        option dest_port    500
        option proto        tcp
        option target       ACCEPT
For IKEv2, replace tcp with udp, and perhaps add port 4500.
I am not aware of any IKE variant based on TCP.

Yes, I know that IKEv2 uses udp... I had just put tcp to make the rule look as close as to my SSH rule as possible. Either way, port 500 still appears closed both over tcp and udp, while the SSH rule causes port 22 to appear as being open.

vgaetera · January 14, 2019, 8:29am

Make sure test results are reliable because UDP-scan differs from TCP-scan.
For example nmap requires root privileges and special option to perform it correctly:

$ nmap -h | grep sU
  -sU: UDP Scan

$ nmap -sU -p 53 192.168.1.1
You requested a scan type which requires root privileges.
QUITTING!

# nmap -sU -p 53 192.168.1.1
...
PORT   STATE SERVICE
53/udp open  domain

dit_dah_dit · January 14, 2019, 6:41pm

vgaetera:

dit_dah_dit:

Either way, port 500 still appears closed both over tcp and udp

Make sure test results are reliable because UDP-scan differs from TCP-scan.
For example nmap requires root privileges and special option to perform it correctly:
$ nmap -h | grep sU
  -sU: UDP Scan

$ nmap -sU -p 53 192.168.1.1
You requested a scan type which requires root privileges.
QUITTING!

# nmap -sU -p 53 192.168.1.1
...
PORT   STATE SERVICE
53/udp open  domain

I never run nmap without being superuser, because it seems like all of the scans I run will spit out the You requested a scan type which requires root privileges. message without elevated privileges.

jeff · January 14, 2019, 7:21pm

A well-configured UDP client, of any sort, often won't respond to "random" probes that aren't part of their protocol and its current state.

tcpdump or Wireshark are more reliable ways of determining if the packets are flowing as expected.

trendy · January 14, 2019, 8:27pm

The thing is that ipsec doesn't work on tcp/500, so your testing was wrong. Since the service is running on your router, you need to remove the dest lan option for all 3 rules (udp/500, udp/4500 and esp)
Run also the iptables -L -vn command to verify that you have hits on the packetcount for each rule when you try to connect.

dit_dah_dit · January 15, 2019, 5:49am

As discussed earlier in the thread, I only used the TCP rule as an example to make it look as close to the SSH rule as possible. In my original testing, all I did was comment out the option dest lan from the ISAKMP rule.

The reason why I became confused in the first place is that iptables -L -vn is showing zero hits on the packet count on the ISAKMP rule when trying to connect. Port scanning shows the port as being closed. SSH over TCP works, so why doesn't ISAKMP over UDP work? After option dest lan is commented out, I see no difference between the two rules. So what is different?

trendy · January 15, 2019, 8:43am

Run a tcpdump to make sure that packets are reaching your router:
tcpdump -i pppoe-wan -vvv -n "udp port 500 or udp port 4500 or ip proto 50"

dit_dah_dit · January 15, 2019, 4:59pm

So, someone explain this one to me. I just briefly lost power, and the router got rebooted. Now, iptables -L -vn is suddenly showing hits on the packet counts when I try to make a VPN connection. I haven't changed anything since starting this thread.

Obviously I can mark this thread as being solved, and I feel stupid for not following my own IT advice that I often tell customers of "did you try rebooting it?"... but I was under the impression that /etc/init.d/firewall reload completely flushes and restarts the firewall. Having to reboot the router to get things working is not a very satisfying solution, especially in a production environment. Has anyone else experienced anything similar in OpenWrt?

vgaetera · January 15, 2019, 5:11pm

service reload != service restart

dit_dah_dit · January 15, 2019, 5:25pm

So, I have to do both?

vgaetera · January 15, 2019, 5:32pm

Reload action does not imply complete status reset by design.

Either one or another depending on the goal.

tmomas · January 25, 2019, 5:32pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.