That is the name of the new feed that I'm trying to add. Why would it be considered "incomplete"? Could it be because I emptied the "Rulev4" field? Or could it be something else?
Out of curiosity, in the Edit Custom Feeds tab, I copied the "Rulev4" field from the doh feed that comes with BanIP into the new feed I added, "doh2", and rebooted, now I see the following in the system log, instead:
Hi, @stevennausak. This "support thread" doesn't appear to provide much actual support for us, so I'll try helping you even though I'm just another user.
In an attempt to debug what's going on, what if you try setting "Auto Allow Uplink" and "Blocklist Set Expiry" back to the defaults of "Please Choose". Then, copy out the contents of the blacklist as a backup if you don't want to lose it, emptying it out, then reboot your device.
Then try selecting one option back at a time to what you have in your screenshot and see if the functionality works correctly with one setting set to your choice, and then the other, by itself. I know "Subnet" says "default" and should work the way you have it, but maybe there's a bug in the code and this procedure might help track it down.
You could also try the above steps and also uncheck "Auto Blocklist", and see if those IPs stop getting automatically added. It would be nice if they had documentation that would properly explain how that feature works, since I've seen IPs get added to my list, but no idea why or how the logic works for that setting. All it says in the docs is "Unsuccessful login attempts or suspicious requests will be tracked and added to the local blocklist (see the ban_autoblocklist option)", but it doesn't say what a "suspicious request" is or how it is calculated to be "suspicious". That might be helpful to know.
@dibdot I think there is an issue with the caching for the IPTHREAT feed. I've been getting the following in my logs for the past two-three weeks (more with similar IP's - same IP /24 segment).
But manually downloading the feed file and checking it, the IP's being reported are not in the file. I think the cached file is still being used instead of using the newer file.
UPDATE:
After validating, BanIP was downloading the updated IPTHREAT file but somehow some of the old IP's are still maintained in FW4. Doing reload doesn't help but a full restart of banip fixed the issue.
UPDATE 2
After deleting all the downloaded backup file and doing a restart. From 45K+ Element count it went down to 35K+ count. So it seems the e-tag checking is somehow affecting if to use the backup or download and use a newer file.
I've tried this in 3 different of my routers that uses BANIP and results are the same.
I'd like to block requests to specific IPs, and I'm having trouble doing that.
I've added the IP 139.59.209.225 (it belongs to openwrt.org) to my blocklist /etc/banip/banip.blocklist. BanIP is active according to /etc/init.d/banip status, and I've reloaded the config via /etc/init.d/banip reload.
When I try to run a GET request on the PC connected to my Openwrt router via curl 139.59.209.225
I get a 301 response, not the timeout I was looking for.
Is there anything more I can try? I've read the manual, but I'm up against a wall.
My network hardware configuration looks like this:
Verizon G1100 -> LAN port -> Cat5 -> WAN port -> TP-Link TL-WDR3500 with OpenWRT 22 installed -> LAN port -> Cat5 -> my PC
301 location pointing to your openwrt?
I get "packet filtered" response while probing a blocked dst ip with icmp, which can help you troubleshot asap.
Ps. I would use curl -I http:// or Ik with https.
No, it's a 301 to https://openwrt.org/. Which is how I would expect it to behave if the IP wasn't being blocked. Here's the entire output. I've added -I, which does help.
I'm wondering my network configuration is messing things up. The configuration in which I'm placing an OpenWRT router "in between" the G1100 (which Verizon compels me to use) and my PC.
I have done some tests on my end, working if properly configured. In my test i use openwrt as upstream router, basically a double nat scenario. Works as expected too.
Make sure you enable the local blocklist in lan forward chain.
I have added and tested with fqdn (cnn.com), add to blacklist, restart banip and test.
curl -Ik https://cnn.com
curl: (7) Failed to connect to cnn.com port 443 after 51 ms: Couldn't connect to server
Delete everything else if that's what you need.
Or just stop banip, and go by cli:
mv /etc/banip/banip.feeds /etc/banip/banip.feeds.old
touch /etc/banip/banip.feeds
edit custom feeds:
vi/nano /etc/banip/banip.custom.feeds
Start bainip
/etc/init.d/banip start.
Check.
