What's new

Help Please..Need assistance stopping outbound connections!

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I'm not following you on the advantage of using a VLAN Capable switch:!

Currently I use 1x Netgear GS108PE, 2 x GS108E and 3 x tp-link TL-SG2008 VLAN capable switches to isolate IoT devices and VPN access all hanging off port 4 on my RT-AC68U: How to segment my network (VLANs, UTM, Cascading)

So clearly your comment
Which makes it impossible for connecting from LAN to the CCTV Vlan
is indeed one of the reasons I use additional VLAN capable switches so I can be sure no IoT devices touch my LAN by default, but I can obviously configure the switch ACLs to allow 'pin-hole' access for certain LAN devices to have 'admin' access to a specific VLAN where necessary.
 
Hello Martineau,

I discovered that my IPTV setting in GUI was messing up with the vlan setup I had in mind. So I fixed my CCTV on a separated Belkin wifi thing, all is well-protected and secured (except I needed to add a Raspberry pi as that Belkin did not provide openvpn support to reach that LAN).

So I'm still stuck with some IoT/printers which I want to protect on the ASUS with your IPCamBlock script. Script is installed and configured, no errors from that part.

Running it gives me:

Code:
admin@RT-AC87U-8538:/jffs/scripts# ./IPCamsBlock.sh init

(IPCamsBlock.sh): 4369 v1.04 I/P Cameras Firewall blocking.... init

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    10549  621K ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
2        0     0 ACCEPT     udp  --  br0    vlan2   anywhere             anywhere             udp dpt:ntp
3        0     0 DROP       all  --  br0    !tun2+  192.168.222.50       anywhere
4       30  2160 logdrop    all  --  br0    !tun2+  192.168.222.50       anywhere
5        0     0 other2wan  all  --  !br0   vlan2   anywhere             anywhere
6       12   624 DROP       all  --  any    any     anywhere             anywhere             state INVALID
7        0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere
8     1188 69470 NSFW       all  --  any    any     anywhere             anywhere
9        5   300 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
10    1183 69170 OVPN       all  --  any    any     anywhere             anywhere             state NEW
11    1183 69170 ACCEPT     all  --  br0    any     anywhere             anywhere

(IPCamsBlock.sh): 4369 I/P Cameras Firewall blocking request completed.

Status:
Code:
admin@RT-AC87U-8538:/jffs/scripts# ./IPCamsBlock.sh status

(IPCamsBlock.sh): 4507 v1.04 I/P Cameras Firewall blocking.... status

num   pkts bytes target     prot opt in     out     source               destination
2        9   684 ACCEPT     udp  --  br0    vlan2   0.0.0.0/0            0.0.0.0/0            udp dpt:123
3        5   360 DROP       all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0
4       30  2160 logdrop    all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0

(IPCamsBlock.sh): 4507 I/P Cameras Firewall blocking status request completed.

All seems good, however, from the 192.168.222.50 I can ping the internet, my router and my NAS, from my NAS & pc's, I can ping 192.168.222.50.

Inspecting the DROP rules in iptables:
Code:
admin@RT-AC87U-8538:/jffs/scripts# iptables -nvL --line | grep DROP
2        1    32 DROP       icmp --  vlan2  *       0.0.0.0/0            0.0.0.0/0            icmptype 8
4       71  2908 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
12     317 17697 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
3       15  1080 DROP       all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0
6       12   624 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
6        0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
1       30  2160 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
2       30  2160 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0


What am I doing wrong?

Thanks for your support!
KK

PS. still working on an AC87U if that may help:
Code:
admin@RT-AC87U-8538:/jffs/scripts# robocfg show
Switch: enabled
Port 0:  100FD enabled stp: none vlan: 2 jumbo: off mac: 00:17:10:88:3f:82
Port 1: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:90:a9:d1:32:46
Port 2: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 74:d4:35:82:a0:8e
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:90:a9:73:3d:69
Port 4:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 5: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:3c
Port 7: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:38
Port 8: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:38
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 5 8t
   2: vlan2: 0 8t

Code:
admin@RT-AC87U-8538:/jffs/scripts# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.d017c2b28538       yes             vlan1
                                                        eth1
 
Hello Martineau,

I discovered that my IPTV setting in GUI was messing up with the vlan setup I had in mind. So I fixed my CCTV on a separated Belkin wifi thing, all is well-protected and secured (except I needed to add a Raspberry pi as that Belkin did not provide openvpn support to reach that LAN).

So I'm still stuck with some IoT/printers which I want to protect on the ASUS with your IPCamBlock script. Script is installed and configured, no errors from that part.

Running it gives me:

Code:
admin@RT-AC87U-8538:/jffs/scripts# ./IPCamsBlock.sh init

(IPCamsBlock.sh): 4369 v1.04 I/P Cameras Firewall blocking.... init

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    10549  621K ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
2        0     0 ACCEPT     udp  --  br0    vlan2   anywhere             anywhere             udp dpt:ntp
3        0     0 DROP       all  --  br0    !tun2+  192.168.222.50       anywhere
4       30  2160 logdrop    all  --  br0    !tun2+  192.168.222.50       anywhere
5        0     0 other2wan  all  --  !br0   vlan2   anywhere             anywhere
6       12   624 DROP       all  --  any    any     anywhere             anywhere             state INVALID
7        0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere
8     1188 69470 NSFW       all  --  any    any     anywhere             anywhere
9        5   300 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
10    1183 69170 OVPN       all  --  any    any     anywhere             anywhere             state NEW
11    1183 69170 ACCEPT     all  --  br0    any     anywhere             anywhere

(IPCamsBlock.sh): 4369 I/P Cameras Firewall blocking request completed.

Status:
Code:
admin@RT-AC87U-8538:/jffs/scripts# ./IPCamsBlock.sh status

(IPCamsBlock.sh): 4507 v1.04 I/P Cameras Firewall blocking.... status

num   pkts bytes target     prot opt in     out     source               destination
2        9   684 ACCEPT     udp  --  br0    vlan2   0.0.0.0/0            0.0.0.0/0            udp dpt:123
3        5   360 DROP       all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0
4       30  2160 logdrop    all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0

(IPCamsBlock.sh): 4507 I/P Cameras Firewall blocking status request completed.

All seems good, however, from the 192.168.222.50 I can ping the internet, my router and my NAS, from my NAS & pc's, I can ping 192.168.222.50.

Inspecting the DROP rules in iptables:
Code:
admin@RT-AC87U-8538:/jffs/scripts# iptables -nvL --line | grep DROP
2        1    32 DROP       icmp --  vlan2  *       0.0.0.0/0            0.0.0.0/0            icmptype 8
4       71  2908 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
12     317 17697 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
3       15  1080 DROP       all  --  br0    !tun2+  192.168.222.50       0.0.0.0/0
6       12   624 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
6        0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
1       30  2160 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
2       30  2160 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
2        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0



Thanks for your support!
KK

PS. still working on an AC87U if that may help:
Code:
admin@RT-AC87U-8538:/jffs/scripts# robocfg show
Switch: enabled
Port 0:  100FD enabled stp: none vlan: 2 jumbo: off mac: 00:17:10:88:3f:82
Port 1: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:90:a9:d1:32:46
Port 2: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 74:d4:35:82:a0:8e
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:90:a9:73:3d:69
Port 4:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 5: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:3c
Port 7: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:38
Port 8: 1000FD enabled stp: none vlan: 1 jumbo: off mac: d0:17:c2:b2:85:38
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 5 8t
   2: vlan2: 0 8t

Code:
admin@RT-AC87U-8538:/jffs/scripts# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.d017c2b28538       yes             vlan1
                                                        eth1
....from the 192.168.222.50 I can ping the internet
Hmm....I'm pretty sure you should be blocked? o_O
...from the 192.168.222.50 I can ping my router and my NAS, from my NAS & pc's, I can ping 192.168.222.50.
For devices attached to the router ports then the switch traffic will not (by default) be subject to the firewall rules.
What am I doing wrong?

Probably nothing.... apart from being overly optimistic regarding the capabilities of my shonky script! :p

IPCamsBlock.sh was written to prevent IP Cams from 'phoning home' whilst still allowing remote viewing inbound only via a secure VPN connection.

Consequently I haven't reviewed the current IPCamsBlock.sh script functionality as I decided to develop a more flexible IoT Blocking script (see the Alexa IoT group example etc.)

I have PM'd you.

If you are willing to test the new script then we can continue further:
e.g. add an IoT entry to

/jffs/configs/IPGroups

e.g. MyIotDevice is the DHCP device name (could be a laptop for testing purposes) to create the IoT KK group
Code:
KK           MyIoTDevice
then issue
Code:
./IotBlock.sh kk init
Now try to PING /access a Web page from the MyIoTDevice...you should be blocked, and you may also check if there is a blocked message:
Code:
./IotBlock.sh kk report

Consult the help in the script, but if IoTBlock.sh still doesn't fully meet your needs, then your options are:

1. VLANs (VLANSwitch.sh)
or
2. If the IoT devices are connected by WiFi, then you may be able to prevent the IoT devices from accessing the LAN or explicitly the NAS (BlockWiFiClient.sh)
 
Last edited:
Hmm....I'm pretty sure you should be blocked? o_O

For devices attached to the router ports then the switch traffic will not (by default) be subject to the firewall rules.

Okok, busted :) I admit, I didn't have any other wifi-device capable device of performing ping-tests, so I had put a PC hardwired to the switch, and put the fixed IP from the cam in it. If "iptables" is indeed incapable of handling that traffic, and my NVR is going to be hardwired, I'm afraid that the only way forward is the VLANSwitch.sh script to cover both wired and wifi devices. The IoT block you pm'ed is on the other hand still very handy for my Google Home - I'll try that tomorrow!

Thank you Martineau!
 
Okok, busted :)

No problem:D

I'm afraid that the only way forward is the VLANSwitch.sh script

I have PM'd you. ...if you have the time to be a Beta tester for VLANSwitch.sh ?

It is biased towards my RT-AC68U and the 384.xx firmware etc. but does include diagnostics which may be useful in identifying why your attempts to create the switch port VLAN didn't work for you as per the other apparently successful posts.

I have tried to make it compatible with the RT-AC87U but never attempt to use port 1! - I believe it is on a separate Realtek switch :-(

You can check the help for the syntax
e.g. Create VLAN20 on port 3
Code:
./VLANSwitch.sh    20   3   "alias=IoT"

For Port 4 on the RT-AC87U do not specify the port... I think it is really index 5????
e.g. Try creating VLAN100 on port 4
Code:
./VLANSwitch.sh    100   vlanfw
 
Last edited:
Hi Martineau, I played around with the Beta of IOTBlock.sh, it did run without any issues, but as predicted, my hardwired IP is not loving the script and runs freely around on the internet.

I am more than happy to try out your script! As my "manual" attempts are still failing at 50%. I do succeed in creating additional vlans, it's the iptables/ebtables setup that does not work "well": I can block IOT->LAN access, and allow LAN->IOT. But internet (through vlan2 on the AC87U) remains open, whatever I do.

I'll dig into your script now!
 
Hi Martineau, I played around with the Beta of IOTBlock.sh, it did run without any issues, but as predicted, my hardwired IP is not loving the script and runs freely around on the internet.

Hmm can you post the output of
Code:
./IoTBlock.sh   kk   status
 
Hmm can you post the output of
Code:
./IoTBlock.sh   kk   status
Sure!
So here was my starting point: PC hardwired to LAN port 3, (port 2 in robocfg) - got 192.168.222.192 from DHCP server, and gave it label "desktop".

Can ping 8.8.8.8, can ping router (192.168.222.1) and can ping NAS (192.168.222.100).

admin@RT-AC87U-8538:/tmp/home/root# ping desktop
PING desktop (192.168.222.192): 56 data bytes
64 bytes from 192.168.222.192: seq=0 ttl=128 time=0.520 ms
Added this information in /jffs/config/IPGroups:
admin@RT-AC87U-8538:/tmp/home/root# more /jffs/configs/IPGroups
CAMERAS 192.168.222.50
kk desktop

Executed: /jffs/scripts/IOTBlock.sh kk init:
admin@RT-AC87U-8538:/jffs/scripts# ./IOTBlock.sh kk init

(IOTBlock.sh): 936 v1.01b Non-public beta IoT Firewall blocking.... kk init


Name: Kk
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 132
References: 1
Number of entries: 1
Members:
192.168.222.192 comment "desktop"


Name: KkTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0


Total=0


Chain MyKk (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT udp -- br0 vlan2 0.0.0.0/0 0.0.0.0/0 udp dpt:123
2 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix "[BADKk]"
3 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

(IOTBlock.sh): 936 IoT (Group Kk) Firewall Blocking complete.

PC can still ping everything (router, NAS, google).

Statistics:
admin@RT-AC87U-8538:/jffs/scripts# ./IOTBlock.sh kk report

(IOTBlock.sh): 1242 v1.01b Non-public beta IoT Firewall blocking.... kk report

Name: Kk
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 132
References: 1
Number of entries: 1
Members:
192.168.222.192 comment "desktop"


Name: KkTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0


Total=0


Chain MyKk (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT udp -- br0 vlan2 0.0.0.0/0 0.0.0.0/0 udp dpt:123
2 35 2435 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix "[BADKk]"
3 35 2435 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

5 192.168.222.192 8.8.8.8 UDP SPT=65265 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=61156 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=61076 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=60809 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=60229 DPT=53
4 192.168.222.192 8.8.8.8 UDP SPT=57313 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=56147 DPT=53
5 192.168.222.192 8.8.8.8 UDP SPT=49844 DPT=53


Unknown TCP/UDP Ports
Name: KkTRK
Type: hash:ip,port
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 60
References: 0
Number of entries: 0
Members:

Any ideas ;-)
 
@Martineau , my apologies for not providing any feedback for a long time but I have finally got some time to look at IoTBlock.sh again. Below is sample output from IoTBlock.sh wemo report that I was wondering if you could help me out a bit. I have allowed ports 3475,3478, and 8443 as they appear to be required to communicate with their update servers. Where I am stumped is what would need to be entered in IoT_Wemo.apps for the NTP servers they are trying to reach or even better since I have my router configured as an NTP server is it possible to redirect
NTP requests to it? Appreciate the use of your script...

Code:
hardcat@RT-AC86U:/jffs/scripts# ./IoTBlock.sh wemo report

(IoTBlock.sh): 29748 v1.01b IoT Firewall blocking.... wemo report

Name: Wemo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 288
References: 1
Number of entries: 2
Members:
192.168.xxx.140
192.168.xxx.141

Chain MyWemo (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.140      0.0.0.0/0            tcp multiport dports 3475,3478,8443
2        0     0 ACCEPT     tcp  --  br0    *       192.168.xxx.141      0.0.0.0/0            tcp multiport dports 3475,3478,8443
3        2   152 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 7 level 4 prefix "[BADWemo]"
4        2   152 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=59658
      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=59147
      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=49163
      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=2828
      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=28172
      2 192.168.xxx.141 8.8.8.8 ICMP TYPE=8 CODE=0 ID=18188
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=58378
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=57867
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=47883
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=26892
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=16908
      2 192.168.xxx.141 4.2.2.2 ICMP TYPE=8 CODE=0 ID=1548
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=60938
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=60427
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=50443
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=4108
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=29452
      2 192.168.xxx.141 208.67.222.222 ICMP TYPE=8 CODE=0 ID=19468
     10 192.168.xxx.141 208.184.49.9 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 208.184.49.9 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 208.184.49.9 UDP SPT=3083 DPT=123 LEN=56
     10 192.168.xxx.141 207.200.81.113 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 207.200.81.113 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 207.200.81.113 UDP SPT=3083 DPT=123 LEN=56
     10 192.168.xxx.141 192.5.41.41 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 192.5.41.41 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 192.5.41.41 UDP SPT=3083 DPT=123 LEN=56
      1 192.168.xxx.141 192.5.41.41 UDP SPT=123 DPT=123 LEN=56
     10 192.168.xxx.141 192.5.41.209 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 192.5.41.209 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 192.5.41.209 UDP SPT=3083 DPT=123 LEN=56
      9 192.168.xxx.141 192.43.244.18 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 192.43.244.18 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 192.43.244.18 UDP SPT=3083 DPT=123 LEN=56
      9 192.168.xxx.141 132.163.4.102 UDP SPT=3085 DPT=123 LEN=56
     10 192.168.xxx.141 132.163.4.102 UDP SPT=3084 DPT=123 LEN=56
      9 192.168.xxx.141 132.163.4.102 UDP SPT=3083 DPT=123 LEN=56
 
@Martineau , my apologies for not providing any feedback for a long time but I have finally got some time to look at IoTBlock.sh again.
No problem. :)
...what would need to be entered in IoT_Wemo.apps for the NTP servers they are trying to reach or even better since I have my router configured as an NTP server is it possible to redirect NTP requests to it?
IPCamsBlock.sh does allow the ability to influence the NTP access, but I deliberated about adding similar functionality to IoTBlock.sh as NTP access rules are probably global rather than for each individual IoT group/chain? :confused:

So currently, using the 'IoT_Wemo.apps' file won't work as the chain name wouldn't match, as the NTP rule(s) wouldn't be visible in your WeMo device chain so I wouldn't be able to associate a global NTP redirect rule with a specific IoT chain when you specified the 'report' or 'del' options.

At the moment I'm not able to access/create/test v1.02b of my script to accommodate your requirement but it should be pretty simple e.g. add something like 'localntp="xxx.xxx.xxx.xxx" as a command line option, however in the interim, you would probably need to manually use something like this:
Code:
iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr) -m --comment "Wemo"

or (if you are on a back-level firmware)

iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr)
 
Last edited:
No problem. :)

IPCamsBlock.sh does allow the ability to influence the NTP access, but I deliberated about adding similar functionality to IoTBlock.sh as NTP access rules are probably global rather than for each individual IoT group/chain? :confused:

So currently, using the 'IoT_Wemo.apps' file won't work as the chain name wouldn't match, as the NTP rule(s) wouldn't be visible in your WeMo device chain so I wouldn't be able to associate a global NTP redirect rule with a specific IoT chain when you specified the 'report' or 'del' options.

At the moment I'm not able to access/create/test v1.02b of my script to accommodate your requirement but it should be pretty simple e.g. add something like 'localntp="xxx.xxx.xxx.xxx" as a command line option, however in the interim, you would probably need to manually use something like this:
Code:
iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr) -m --comment "Wemo"

or (if you are on a back-level firmware)

iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr)

Not meaning to be critical by any means I did learn in order for the "comment" to be added the first line should read as follows:;)

Code:
iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr) -m comment --comment "Wemo"

Thanks...
 
Not meaning to be critical by any means I did learn in order for the "comment" to be added the first line should read as follows:;)
Code:
iptables -t nat -I PREROUTING -i br0 -s 192.168.xxx.140/31 -p udp --dport 123 -j DNAT --to-destination $(nvram get lan_ipaddr) -m comment --comment "Wemo"

Whoops :oops: ...that's what comes from trying to remember/type syntax correctly ...without being able to actually execute the command on a router :oops::oops:

But does the command show correctly in 'iptables'..or more importantly does it redirect NTP requests for those two devices to the NTPD on the router?
 
Whoops :oops: ...that's what comes from trying to remember/type syntax correctly ...without being able to actually execute the command on a router :oops::oops:

But does the command show correctly in 'iptables'..or more importantly does it redirect NTP requests for those two devices to the NTPD on the router?

Output of iptables looks good, still waiting to see a couple of hits on the counters. Will report back when I see some. Not sure when the Wemo devices check time.

Code:
hardcat@RT-AC86U:/jffs/scripts# iptables -t nat -nvL PREROUTING --line-numbers
Chain PREROUTING (policy ACCEPT 368 packets, 121K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DNAT       udp  --  br0    *       192.168.xxx.140/31   0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
2       87 15706 VSERVER    all  --  *      *       0.0.0.0/0            xxx.xxx.xxx.198
 
Starting to see the counters increase in iptables output as follows:
Code:
hardcat@RT-AC86U:/jffs/scripts# iptables -t nat -nvL PREROUTING --line-numbers
Chain PREROUTING (policy ACCEPT 12675 packets, 3596K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       20  1520 DNAT       udp  --  br0    *       192.168.xxx.140/31   0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
2      190 35396 VSERVER    all  --  *      *       0.0.0.0/0            xxx.xxx.xxx.198

Do not know how to check ntpd to see if they got their time since it is only the busybox version, and the Wemo devices do not appear to have a way to check either. Hmmm...
 
Starting to see the counters increase in iptables output as follows:
Code:
hardcat@RT-AC86U:/jffs/scripts# iptables -t nat -nvL PREROUTING --line-numbers
Chain PREROUTING (policy ACCEPT 12675 packets, 3596K bytes)
num   pkts bytes target     prot opt in     out     source               destination     
1       20  1520 DNAT       udp  --  br0    *       192.168.xxx.140/31   0.0.0.0/0            udp dpt:123 /* Wemo */ to:192.168.xxx.1
2      190 35396 VSERVER    all  --  *      *       0.0.0.0/0            xxx.xxx.xxx.198

Do not know how to check ntpd to see if they got their time since it is only the busybox version, and the Wemo devices do not appear to have a way to check either. Hmmm...

Silly question.. have you actually configured/initiated an instance of NTPD either the Busybox version or @kvic's version on the router?
 
Silly question.. have you actually configured/initiated an instance of NTPD either the Busybox version or @kvic's version on the router?
Configured as per Wiki, not Kvic's version.
Code:
https://github.com/RMerl/asuswrt-merlin/wiki/Setting-up-an-NTP-Server-for-your-local-lan
Checked it is running
Code:
hardcat@RT-AC86U:/tmp# ps | grep ntpd
 2576 hardcat   3592 S    ntpd -l
15780 hardcat   5324 S    grep ntpd
 
Configured as per Wiki, not Kvic's version.
Code:
https://github.com/RMerl/asuswrt-merlin/wiki/Setting-up-an-NTP-Server-for-your-local-lan
Checked it is running
Code:
hardcat@RT-AC86U:/tmp# ps | grep ntpd
 2576 hardcat   3592 S    ntpd -l
15780 hardcat   5324 S    grep ntpd

OK, Kvic's version includes diagnostic utilities ntpdc etc. but I assume you tested the router's NTP server capabilties by temporarily setting a spare windows laptop etc. to an obscure date, then 'Adjust/Date time/Internet Time' via the GUI? so at least you could see if the PREROUTING rule was effective.
 
OK, Kvic's version includes diagnostic utilities ntpdc etc. but I assume you tested the router's NTP server capabilties by temporarily setting a spare windows laptop etc. to an obscure date, then 'Adjust/Date time/Internet Time' via the GUI? so at least you could see if the PREROUTING rule was effective.
Created a new rule for the laptop's IP, changed the time and date on the laptop, went to Internet time settings in Windows 10, told it to update via IP address of the router, update now, time and date changed immediately to the correct date and time, confirmed the new rule in the PREROUTING chain incremented by 1.
 
Created a new rule for the laptop's IP, changed the time and date on the laptop, went to Internet time settings in Windows 10, told it to update via IP address of the router, update now, time and date changed immediately to the correct date and time, confirmed the new rule in the PREROUTING chain incremented by 1.

Good, however explicitly requesting the Windows 10 laptop to use the router's NTP server should always work, with or without the PREROUTING rule, so perhaps a better test would be to leave the Windows 10 Internet time value to its original external server or perhaps use a non-existent NTP time server such as 172.16.1.1?
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top