Hi

I need help with this. I have been trying to solve it for  hours now.
I have created 2 wifi SSIDs "guest" (wlan0-1) which is for guests which interface is PUBLIC and the other is "mynetwork" (wlan0) for admin purpose which interface is LAN. I then created zones PUBLIC and LAN for firewall policies. The gateway for this network is on separate physical device with IP address 192.168.1.10.

My goal is to prevent hosts on zone PUBLIC accessing zon LAN except if it really is necessary.

Here are the interfaces:

config interface 'lan'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option _orig_ifname 'eth0.1 wlan0 wlan1'
    option _orig_bridge 'true'
    option gateway '192.168.1.10'
    option dns '208.67.222.222 208.67.220.220'
    option ifname 'eth0.1'

config interface 'public'
    option proto 'static'
    option ipaddr '10.0.0.1'
    option netmask '255.255.255.0'
    option _orig_ifname 'wlan0-1'
    option _orig_bridge 'true'
    option dns '208.67.222.222 208.67.222.220'

Please excuse my lack of understanding of how networking works, but I see that I need to enable forwarding between zone PUBLIC and LAN to enable hosts connected to wifi "guest" to access the Internet so I have enabled 2 way forwarding between zone LAN and PUBLIC. I then created a rule to block all access from zone PUBLIC to LAN. However, after applying the rule I can still ping from hosts on Wifi guest to wired hosts on zone LAN. Why is that? What is the correct way of achieving this? Here are the firewall policies:

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config include
    option path '/etc/firewall.user'

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

config zone
    option name 'public'
    option network 'public'
    option output 'ACCEPT'
    option forward 'REJECT'
    option input 'REJECT'

config rule
    option src 'public'
    option target 'DROP'
    option name 'Disallow PUBLIC to LAN'
    option dest 'lan'

config forwarding
    option dest 'lan'
    option src 'public'

config forwarding
    option dest 'public'
    option src 'lan'

Please help.

Thank you.

You are on the right track here. The stumbling block is in the order of the rules. In your firewall config, you first have a default policy for PUBLIC that prohibits all forwarded traffic. You then have an explicit, but unnecessary rule that also prohibits forwarding. You then have two rules, which allow forwarding of traffic to/from PUBLIC and LAN.

And this last pair of rules is now what allows ping to reach a wired host in LAN from a Wi-fi guest in PUBLIC. It is the last pair in your firewall config which applies to forwarding, and because it is the last, it remains the effective one.

If you want to only allow Wi-fi guests to reach the Internet, but not other hosts in the LAN zone, then what you must do is a unidirectional forwarding rule that matches only when a specific destination is being used. The following rule accomplishes that:

config rule
   option name 'Gateway access for PUBLIC'
   option src 'public'
   option dest 'lan'
   option dest_ip '192.168.1.10'
   option target 'ACCEPT'

This rule replaces the three forwarding-related rules you currently have.

In order for return traffic to work, you will need to enable connection tracking on the LAN zone. To do this, change your LAN zone config to the following:

config zone
    option name 'lan'
    option network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option conntrack '1'

As you can see, I have also removed the "forward" option since it is not necessary. The gateway device resides in the same subnet as your LAN, and the logical network "LAN" is bridging together adapters 'eth0.1' and probably the admin-side wireless network. Hence, traffic is automatically allowed to flow freely, and no forward is necessary.

With these changes, clients in PUBLIC should now be able to ping the gateway device at 192.168.1.10. The gateway device can respond to the ping and the packet is allowed back (due to conntrack), but if the gateway tries to ping the clients in PUBLIC, that traffic is blocked. Similarly, traffic from LAN towards PUBLIC is blocked. Clients in PUBLIC also cannot ping clients in LAN (other than the gateway device, that is).

In order for all other traffic to work from PUBLIC (i.e. web browsing etc.) you will need to either set the gateway address (192.168.1.10) explicitly for all clients in PUBLIC, or you will need to configure and expose a DHCP service in the PUBLIC network. You have not shown the content of your /etc/config/dhcp file, so I cannot say if the service is available or not.

If the service is available, then you will need the following additional rule in order for clients in PUBLIC to be able to use it:

config rule
    option name 'DHCP for PUBLIC'
    option src 'public'
    option src_port '67-68'
    option dest_port '67-68'
    option proto 'udp'
    option target 'ACCEPT'

The return direction is working automatically, because the OUTPUT direction in PUBLIC is allowed by the zone's policy.

Note that the router will not answer to DNS requests from the clients in PUBLIC. To allow this as well, add one last rule:

config rule
    option name 'DNS for PUBLIC'
    option src 'public'
    option dest_port '53'
    option proto 'tcp udp'
    option target 'ACCEPT'

For a step by step guide on creating a guest WLAN that enforces the information what you've just read above, you can check this link: https://wiki.openwrt.org/doc/recipes/guest-wlan. Note that unlike our setup here, the setup in the link assumes that the wide area access is on a separate logical network. This is not the case for us, since the gateway device is at 192.168.1.10.

Hi Antek,

Thank you for your detail and helpful explanation. I really appreciate it.

I have tried your suggestion but unfortunately wifi hosts on public zone is unable to ping or access 192.168.1.10 hence the Internet. Here is the latest configurations:

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config include
    option path '/etc/firewall.user'

config zone
    option name 'lan'
    option network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option conntrack '1'

config zone
    option name 'public'
    option network 'public'
    option output 'ACCEPT'
    option forward 'REJECT'
    option input 'REJECT'

config rule
        option src 'public'
        option src_port '67-68'
        option dest_port '67-68'
        option proto 'udp'
        option target 'ACCEPT'
        option name 'Allow DHCP request'

config rule
        option src 'public'
        option dest_port '53'
        option proto 'tcpudp'
        option target 'ACCEPT'
        option name 'Allow DNS Queries'

config rule
    option name 'Gateway access for PUBLIC'
    option src 'public'
    option dest 'lan'
    option dest_ip '192.168.1.10'
    option target 'ACCEPT'

As trial and error, I have also tried configurations below to allow everything from public to lan except to subnet 192.168.1.0/24 but I still can ping any host on 192.168.1.0/24 subnet.

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config include
        option path '/etc/firewall.user'

config rule
        option src 'public'
        option src_port '67-68'
        option dest_port '67-68'
        option proto 'udp'
        option target 'ACCEPT'
        option name 'Allow DHCP request'

config rule
        option src 'public'
        option dest_port '53'
        option proto 'tcpudp'
        option target 'ACCEPT'
        option name 'Allow DNS Queries'

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

config zone
        option name 'public'
        option network 'public'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'REJECT'

config forwarding
        option dest 'lan'
        option src 'public'

config forwarding
        option dest 'public'
        option src 'lan'

config rule
        option name 'Deny public to lan'
        option src 'public'
        option dest 'lan'
        option target 'DROP'
        option dest_ip '192.168.1.10/24'

I even swapped the the forwarding and rule like below but I still can ping any host on the subnet.

config forwarding
        option dest 'public'
        option src 'lan'

config rule
        option name 'Deny public to lan'
        option src 'public'
        option dest 'lan'
        option target 'DROP'
        option dest_ip '192.168.1.10/24'

config forwarding
        option dest 'lan'
        option src 'public'

What could be the problem?

Regards,

I don't think the firewall rules know how to deal with CIDR-notation i.e. '192.168.1.10/24'. If you want to use a range of individual IPs or block out entire networks, then you'll need to resort to adding an IP Set. I have not used IP Sets in my firewall rules, so I can't give any good examples.

The latest configuration you posted seems correct to me, so the problem could be somewhere else. Perhaps it is a routing table issue? Using the first configuration, type 'route -n' on an SSH shell and post the result here.

You should also verify the settings on your wireless clients. Join a wireless client into the "public" network, and ensure it gets configured correctly. If you use DHCP on the wireless client, ensure it gets a good IP address and has the correct gateway setting. The DNS settings on the client might still be incorrect unless you've fixed them in /etc/config/dhcp. If you use static addressing on the wireless clients, then ensure the settings are correct.

Thanks Antek.

Actually even if I specified the IP 192.168.1.10 without /24, it makes no difference, I can still ping it using the trial and error configurations.

Here is the result of route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.10    0.0.0.0         UG    0      0        0 br-lan
10.0.0.0        10.0.0.1        255.255.255.0   UG    0      0        0 wlan0-1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
root@pejalan:/tmp/log#

I am quite sure the wireless client is working as I can access the Internet with the trial and error configurations.

By the way, how can I see the logs of the firewall including the accepted traffic? I can see the blocked traffic on kernel logs on Luci. Where is it if use command line?

Thanks

This routing table seems ok. Do you have any Linux clients in the wireless network? If you use 'route -n' for them, what does the result look like? If you have only Windows clients, you can use 'route print' command.

Another thing you can try is change the 'conntrack' option in the LAN zone to the 'masq' option, with the same value of '1. This creates masquerade rules so traffic coming from the 'public' network that is forwarded to the LAN network is subjected to a source address rewrite (source NAT).

Your scenario is pretty unique since the gateway device resides in the "lan" network. Usual router configs have a "lan" network, a "guest" wi-fi and then a "wan" network through which the gateway device, and Internet, are reachable. This three-network setup makes the routing rules much simpler to write.

If nothing else works, you can always use the "trial and error" configuration. In my opinion it gives a bit too much visibility for the wireless clients, but if the user accounts and passwords of your router and all LAN-side devices are secure enough, then it shouldn't be a problem.

The 'dmesg' command prints the content of the kernel log from the command-line. The 'logread' command prints the system log, again from the command-line.

The following two options, defined in the 'zone' entries in /etc/config/firewall:

    option log '1'
    option log_limit '10/minute'

will create firewall rules that write an entry to either the kernel log or the system log for rejected and dropped traffic on a per-zone basis, and will limit the number of log entries to 10 entries per minute so the kernel log doesn't get flooded.

I do not know how to configure the firewall so that it prints log entries for accepted traffic.

(Last edited by Antek on 20 Aug 2017, 15:45)

Hi Antek,

I have only Android clients so far and the netstat command output looks ok:

Kernel IP routing table:
Destination     Gateway     Genmask
0.0.0.0            10.0.0.1      0.0.0.0
10.0.0.0           0.0.0.0       255.255.255.0

Since my gateway resides on the lan network, is it possible to have a wan network which only gateway 192.168.1.10 resides but the rest is on the lan network? Which interface should I assign to this wan network?

The reason I have the gateway in lan network because I thought it could reduce delay introduced by routing since there is one more router to connect to the Internet through my home ADSL. So I thought if this gateway is not on the same lan network, the routing delay may be higher. Is that a correct assumption?

Yes I can use the trial and error configuration but the rule that blocks connection from public to lan is not working as I mentioned in the previous post.

Thanks for the tips on the firewall logs.

(Last edited by zorrox on 21 Aug 2017, 16:20)

A thought occurred to me: perhaps we need to be a bit more explicit on the routing configuration. Modify your Public network in the /etc/config/network to match this:

config interface 'public'
    option proto 'static'
    option ipaddr '10.0.0.1'
    option netmask '255.255.255.0'
    option dns '208.67.222.222 208.67.222.220'

config route 'Default route for Public'
    option interface 'public'
    option target '0.0.0.0'
    option netmask '0.0.0.0'
    option gateway '192.168.1.10'

Remember to retain the 'lan' network so it has the 'conntrack' option, and the explicit firewall forwarding rule that I wrote earlier.

Does this change help? Post the 'route -n' command from the OpenWRT router after this change.

Note: We are modifying the default routing table, so there is a chance that after this change, you'll lose Internet access from the LAN behind the OpenWRT router. If that happens, just remove the default route and restart.

You could either use two /28 segments (192.168.1.0 - 192.168.1.15 and 192.168.1.16 - 192.168.1.31), or you could use 192.168.1.0/24 as the network where the gateway resides, and use 192.168.2.0/24 for the "LAN" behind the OpenWRT.

It would require you to configure the switch device, and assign VLAN tagging for the ports. Configuring the switch is always a bit tricky, because the configuration needs to be complete, and may cause changes not only to network, firewall and DHCP, but also to Dropbear and uhttpd because the network interfaces change around. The pitfall is that if you make a mistake anywhere in the process, you might end up having to reset your router completely from safe mode or over a TTL serial cable because it becomes inaccessible due to some obscure mistake that you didn't account for. I've been there, and done that. Configuring OpenWRT through a serial cable is NOT fun

This is the correct assumption. Splitting the LAN network to LAN and WAN would introduce one additional routing decision for the "LAN" network behind the OpenWRT router. In your current setup, no such decision is necessary.

(Last edited by Antek on 21 Aug 2017, 20:58)

Hi Antek,

Sorry for the delay in reply.

I have tested your suggestion but it is not working. My wifi and wired clients are unable to even get IP from the DHCP server so I cannot run the route -n on the router. I need to reset the router in safe mode to fix it.

However, the good news is I have successfully made the trial and error configuration working. It turns out that the DROP rule from public to lan must be specific enough to match the traffic, like this:

config rule
    option name 'Deny public to lan'
    option src 'public'
    option dest 'lan'
    option dest_ip '192.168.1.0/24'
    option proto 'all'
    option target 'DROP'

Previously I omitted the "option proto" line but after rearranging the option lines and adding "option proto 'all'", it works. I guess I will stick with this for now.

I would like to thank you again for your wonderful help and suggestion. I really appreciate it.

Did the DHCP stop working after adding the default rule? That's really strange indeed, and quite unexpected, especially for the wired clients since they shouldn't be affected by the rules of the 'public' network.

This sounds logical, as the default value for "proto" is "tcpudp". So icmp etc. was able to pass through. I'm surprised that the "dest_ip" field accepts CIDR notation, the documentation doesn't explicitly state this. Good to know for future reference

Glad you got it working, and good to hear if my ideas helped you at least a little bit, although I couldn't figure out the exact solution

Now I am having problem to deny NEW connection from public to lan. The rule

config rule
    option name 'Deny public to lan'
    option src 'public'
    option dest 'lan'
    option dest_ip '192.168.1.0/24'
    option proto 'all'
    option target 'DROP'

drops everything including ESTABLISHED and RELATED connections from public to lan. How do I specify to drop NEW connection from public to lan only? I tried adding option extra argument like below but it does not seem to work.

config rule
    option name 'Allow Established Connection'
    option src 'public'
    option dest 'lan'
    option dest_ip '192.168.1.0/24'
    option proto 'all'
    option target 'ACCEPT'
    option extra '-m state --state RELATED,ESTABLISHED'

Any ideas?

The 'extra' option should do what you want. Can you post the entire firewall config as it now is, for reference?

Here it is:

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config include
        option path '/etc/firewall.user'

config zone
        option name 'lan'
        option network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option log '1'

config zone
        option name 'public'
        option network 'public'
        option output 'ACCEPT'
        option input 'REJECT'
        option forward 'ACCEPT'
        option log '1'


config rule
        option name 'Allow DHCP request'
        option src 'public'
        option src_port '67-68'
        option dest_port '67-68'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Allow DNS Queries'
        option src 'public'
        option dest_port '53'
        option proto 'tcpudp'
        option target 'ACCEPT'


config forwarding
        option src 'lan'
        option dest 'public'

config forwarding
        option dest 'lan'
        option src 'public'

config rule
        option name 'Allow Established Connection'
        option src 'public'
        option dest 'lan'
        option dest_ip '192.168.1.0/24'
        option proto 'all'
        option target 'ACCEPT'
        option extra '-m state --state RELATED,ESTABLISHED'

config rule
        option name 'Deny public to lan'
        option src 'public'
        option dest 'lan'
        option dest_ip '192.168.1.0/24'
        option proto 'all'
        option target 'DROP'

When I ping from 192.168.1.114 to 10.0.0.65, I see this on firewall logs which I think it is blocking echo reply from 10.0.0.65:

[29392.010000] DROP(dest lan)IN=wlan0-1 OUT=br-lan MAC=c6:e9:84:d5:11:d7:70:5a:0f:52:4d:37:08:00 SRC=10.0.0.65 DST=192.168.1.114 LEN=84 TOS=0x00 PREC=0x00 TTL=254 ID=19861 PROTO=ICMP TYPE=0 CODE=0 ID=3845 SEQ=12
[29393.050000] DROP(dest lan)IN=wlan0-1 OUT=br-lan MAC=c6:e9:84:d5:11:d7:70:5a:0f:52:4d:37:08:00 SRC=10.0.0.65 DST=192.168.1.114 LEN=84 TOS=0x00 PREC=0x00 TTL=254 ID=20548 PROTO=ICMP TYPE=0 CODE=0 ID=3845 SEQ=13
[29394.070000] DROP(dest lan)IN=wlan0-1 OUT=br-lan MAC=c6:e9:84:d5:11:d7:70:5a:0f:52:4d:37:08:00 SRC=10.0.0.65 DST=192.168.1.114 LEN=84 TOS=0x00 PREC=0x00 TTL=254 ID=21184 PROTO=ICMP TYPE=0 CODE=0 ID=3845 SEQ=14

Please help

What happens if you remove the 'Allow established connection' rule completely, and instead use the 'option extra' in the Deny rule, to make it affect only new connections?

Like so:

config rule
        option name 'Deny public to lan'
        option src 'public'
        option dest 'lan'
        option dest_ip '192.168.1.0/24'
        option proto 'all'
        option target 'DROP'
        option extra '-m state --state NEW'

You can also use 'iptables --list' in order to print the whole filter table chain structure. It might help in rooting out the issue. Sometimes the UCI config file does not print the whole picture, when the scenario is complex enough.

EDIT: Also, I see that the 'conntrack' option has been removed from the 'lan' zone. I think this option is necessary in order for the stateful firewall to work in the first place. Perhaps try adding this option first, and if that doesn't work, then try with the modified Deny rule?

(Last edited by Antek on 25 Aug 2017, 05:13)

Hi Antek

Adding the conntrack again solves the issue. Thank you very much.

By the way how do I know when to add conntract to a zone? If I have a wan zone, should it have conntrack too?

Currently I am using your suggestion to add the  "option extra '-m state --state NEW'" to the deny rule and it works like charm. Thanks again.

You're welcome

If a zone is involved in a firewall rule that relies on tracking the state of the connection (NEW, ESTABLISHED, RELATED etc.) then the 'conntrack' option needs to be set on this zone. If the firewall rule is associated with two zones (forwarded traffic) then the option needs to be set on at least one of the zones.

Usually a WAN zone has the 'masq' option which causes outbound packets to get their source address re-written to the  IP address which the router's interface is using in this network. The 'masq' option also implicitly enables 'conntrack'. Armed with these two options, the zone both knows to accept the return-packet (due to 'conntrack'), and knows where it should be forwarded to (due to 'masq').

If your LAN zone uses public IPs, then you can use just the 'conntrack' option on the WAN zone to enable the stateful firewall without the source address re-write.

Hi Antek,

Need you help again. I just realized recently that tcp connection from lan to public is always terminated after a few seconds despite ping works with no drop. For example, I run an SSH server on 10.0.0.164 and connect to it from 192.168.1.177. The initial connection is fine I can login and get authenticated and get the shell prompt. However after around 20 seconds the shell just hangs. The SSH server is still running and I can connect again without restarting the ssh server. The same problem happens when I try to print to a printer on public network from lan network, the printer will print about almost a quarter of the page before stopping. Please find below the last part of tcpdump capture of the ssh connection when it hangs:

15:07:40.196715 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5052:5168, ack 4140, win 1629, options [nop,nop,TS val 154798 ecr 5641639], length 116
15:07:40.196879 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5168, win 249, options [nop,nop,TS val 5641892 ecr 154798], length 0
15:07:40.690788 IP 192.168.1.177.45709 > 10.0.0.164.60805: Flags [FP.], seq 0:104, ack 1, win 249, options [nop,nop,TS val 5642016 ecr 146432], length 104
15:07:41.200863 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5168:5284, ack 4140, win 1629, options [nop,nop,TS val 154999 ecr 5641892], length 116
15:07:41.201023 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5284, win 249, options [nop,nop,TS val 5642143 ecr 154999], length 0
15:07:42.191301 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5284:5400, ack 4140, win 1629, options [nop,nop,TS val 155197 ecr 5642143], length 116
15:07:42.191454 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5400, win 249, options [nop,nop,TS val 5642391 ecr 155197], length 0
15:07:43.207483 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5400:5516, ack 4140, win 1629, options [nop,nop,TS val 155400 ecr 5642391], length 116
15:07:43.207640 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5516, win 249, options [nop,nop,TS val 5642645 ecr 155400], length 0
15:07:44.207775 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5516:5632, ack 4140, win 1629, options [nop,nop,TS val 155600 ecr 5642645], length 116
15:07:44.207940 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5632, win 249, options [nop,nop,TS val 5642895 ecr 155600], length 0
15:07:45.199236 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5632:5748, ack 4140, win 1629, options [nop,nop,TS val 155799 ecr 5642895], length 116
15:07:45.199407 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5748, win 249, options [nop,nop,TS val 5643143 ecr 155799], length 0
15:07:46.199007 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5748:5864, ack 4140, win 1629, options [nop,nop,TS val 155998 ecr 5643143], length 116
15:07:46.199173 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5864, win 249, options [nop,nop,TS val 5643393 ecr 155998], length 0
15:07:47.200189 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 156199 ecr 5643393], length 116
15:07:47.200356 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5643643 ecr 156199], length 0
15:07:47.414063 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 156240 ecr 5643393], length 116
15:07:47.414197 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5643696 ecr 156240,nop,nop,sack 1 {5864:5980}], length 0
15:07:47.823494 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 156322 ecr 5643393], length 116
15:07:47.823665 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5643799 ecr 156322,nop,nop,sack 1 {5864:5980}], length 0
15:07:48.639662 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 156486 ecr 5643393], length 116
15:07:48.639797 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5644003 ecr 156486,nop,nop,sack 1 {5864:5980}], length 0
15:07:50.284380 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 156815 ecr 5643393], length 116
15:07:50.284548 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5644414 ecr 156815,nop,nop,sack 1 {5864:5980}], length 0
15:07:53.572103 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 157472 ecr 5643393], length 116
15:07:53.572260 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5645236 ecr 157472,nop,nop,sack 1 {5864:5980}], length 0
15:08:00.154094 IP 10.0.0.164.60805 > 192.168.1.177.46016: Flags [P.], seq 5864:5980, ack 4140, win 1629, options [nop,nop,TS val 158788 ecr 5643393], length 116
15:08:00.154256 IP 192.168.1.177.46016 > 10.0.0.164.60805: Flags [.], ack 5980, win 249, options [nop,nop,TS val 5646881 ecr 158788,nop,nop,sack 1 {5864:5980}], length 0

Thanks

Introducing additional services into the Public network which need to be accessed from LAN as well changes your network topology so much that I think you'll need to re-design it. The services which need to be accessible from both networks should be placed into a demilitarized zone, and the WAN network should be segregated to a zone of its own.

The firewall rule that we wrote was a quick way to block traffic. Your network complexity has outgrown the rule, and thus you need to plan it a-new.

Take out pen & paper, and draw the entire network topology on paper. Place services that you want to expose to more than one network into a zone of their own. Also put the edge gateway into a zone of its own. This makes it easier to write access rules.

This network is a home network which I do not plan to expand or redesign and hope to keep it simple. I appreciate your suggestion but as of now I think I will first try to look for a solution to solve this problem.

By the way, I have used logread and dmesg to check the logs to get  more clues. Can you tell me where else I can find other logs or any other commands to view the logs?

Regards

(Last edited by zorrox on 11 Sep 2017, 14:41)

Although I cannot be sure of this, I tend to think that these intermittent disconnections might be caused by the inherent complexity of your current configuration.

The UCI system is capable of creating pretty amazing firewall configurations based on the instructions it is given, but it is by no means complete or fail-safe. This fact bit me in the ankle when I had the need to create time-based limitations for the Internet-connected devices that our kids use. I had to resort to the 'firewall.user' script file and non-UCI custom chains, all because the UCI system adds some default entries high up in the iptables filter table that cannot be effectively overridden in UCI config alone. And it does this even without you necessarily knowing it!

I think you should use 'iptables -t filter --list', 'iptables -t nat --list' and 'iptables -t mangle --list' in order to get a complete, full overview of all the intertwined rules that the current configuration establishes. Perhaps by analyzing these rules in detail we can get a better view on what is truly going on, and possibly pinpoint the failure.

For example, my innocent-looking UCI config:

root@OpenWRT:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'REJECT'
        option output 'REJECT'
        option forward 'REJECT'

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

config zone
        option name 'wan'
        option network 'wan'
        option input 'DROP'
        option output 'ACCEPT'
        option forward 'DROP'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'
        option family 'any'
        option reload '1'

creates quite a complex configuration already: http://jekor.com/gressgraph/graph/e7641 … 69b46a69f2.

And this graph just shows the filter table, without any active UPnP redirects

Thank you for your explanation of the complexity of the firewall. It is always good to learn something new.
I do not really have the skills and knowledge to use the commands you suggested so I need to study further on how to use them.
For your information, the disconnection is not intermittent, so far all TCP connections from "lan" to "public" will always drop after about 20 seconds. I have even removed the deny rule below to allow full access from "public" to "lan" but the same issue persists. I am now looking for a way to view other logs on the device.

config rule
        option name 'Deny public to lan'
        option src 'public'
        option dest 'lan'
        option dest_ip '192.168.1.0/24'
        option proto 'all'
        option target 'DROP'
        option extra '-m state --state NEW'

That sounds really strange. I can't really think of any reason why the iptables would drop the connection at the 20 seconds mark. Just a thought, but perhaps there's some sort of an auto-timeout at the SSH server?

Can you elaborate a little bit on the network topology? Is the SSH server, and the printer, directly connected to the OpenWRT router? Is the SSH server on a computer of its own, or is it hosted on the OpenWRT and just listens on the "public" network's interfaces? How is the printer shared to the network, is there a daemon running on OpenWRT, or does the printer have its own DHCP client and a printer daemon?

I do not think the SSH server has auto-timeout because when assigned with LAN ip address, there is no connection drop issue.

Here is my simplified network topology:

The SSH server is actually running on my android phone which is connected to WIFI on PUBLIC interface assigned with IP 10.0.0.x. The printer is also connected to the same WIFI. However If the android phone is connected to LAN interface WIFI which is assigned with IP 192.168.1.x, there is no connection drop issue connecting from devices on the same network. Any device can connect to the printer wirelessly using WIFI. The printer is just a normal WIFI HP printer. All devices get the IP from OpenWRT DHCP server running on LAN and PUBLIC interfaces. Please find below other configurations on openwrt:

DHCP:
config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv6 'server'
    option ra 'server'
    option ra_management '1'
    list dhcp_option '3,192.168.1.10'

config dhcp 'public'
    option interface 'public'
    option start '50'
    option limit '200'
    option leasetime '6h'

network:
config interface 'lan'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option _orig_ifname 'eth0.1 wlan0 wlan1'
    option _orig_bridge 'true'
    option gateway '192.168.1.10'
    option dns '208.67.222.222 208.67.220.220'
    option ifname 'eth0.1 eth0.100'
    option stp '1'

config interface 'public'
    option proto 'static'
    option ipaddr '10.0.0.1'
    option netmask '255.255.255.0'
    option _orig_ifname 'wlan0-1'
    option _orig_bridge 'true'
    option dns '208.67.222.222 208.67.220.220'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '1'
    option ports '0t 1'

config switch_vlan
    option device 'switch0'
    option vlan '3'
    option ports '0t 1t 5'
    option vid '600'

config interface 'iptv'
    option proto 'dhcp'
    option ifname 'eth0.600'

config route
    option interface 'public'
    option target '10.0.0.0'
    option netmask '255.255.255.0'
    option gateway '10.0.0.1'

config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '100'
    option ports '0t 1t 2 3 4'

Wireless:
config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'mynetworky'
    option encryption 'psk-mixed'
    option network 'lan'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'Duyuf'
    option encryption 'psk-mixed'
    option network 'public'

Ok, I see it now.

A few clarifying questions while I digest your config:
- Does the device running the pfSense firewall terminate the DSL link, or do you have a separate DSL modem?
- Apparently your ISP exposes their Internet service through VID 100 and an IPTV service through VID 600. Correct?
- What is the purpose of VID 1? Is it required to reach the management interface of the pfSense firewall?
- How do you want to use the OpenDNS DNS service? Only for your OWRT router, or for all wired and wireless clients as well?

My answers are below:

- Does the device running the pfSense firewall terminate the DSL link, or do you have a separate DSL modem?
Yes, terminated at pfsense

- Apparently your ISP exposes their Internet service through VID 100 and an IPTV service through VID 600. Correct?

My ISP Internet service is on VLAN 500 but this only configured on pfsense. VLAN 100 is only configured on openwrt. The openwrt has trunk connection to pfsense. The truth is I am also not really good with VLAN, I am still can not figure out why VLAN 100 configured on openwrt works while Internet connection on pfsense is on VLAN 500. You may able to figure this out.
VLAN 600 is configured on openwrt and pfsense for IPTV. The LAN interface and WAN interface on pfsense are configured with VLAN 600 and bridged on pfsense to enable IPTV. I think this is on layer 2 all the way to my ISP network. 

- What is the purpose of VID 1? Is it required to reach the management interface of the pfSense firewall?

Not really. It was there based on other users configuration in my country which I stumbled on the Internet who subscribed to the same service. I do not remove it as I do not know how it can affect my network.

- How do you want to use the OpenDNS DNS service? Only for your OWRT router, or for all wired and wireless clients as well?

I use OpenDNS for HTTPS web filtering to complement pfsense HTTP filtering. It is actually configured on openwrt only but all clients get DNS IP which is the openwrt interface IP. All clients DNS requests are relayed to OpenDNS by Openwrt.

I also observe that there is no drop connection between clients on 10.0.0.x. using the same SSH server and printer.

Thanks