pfBlockerNG blocking access to android bank app
-
In fact, i found that the only truly blocking are the ones from google....
Thats the last one i want in my allow list .....google-analytics.com # rabo www.google-analytics.com # rabo www-google-analytics.l.google.com # CNAME for (google-analytics.com)
-
Last reply from my side.
I fixed it by changing the DNS Virtual IP to 127.0.0.1.
Whitelist is empty again, ads are still blocked.This obviously breaks the functionality where a user is informed that something was blocked by the network administrator , but for home usage this is fine and this is how most home adblockers work anyway.
Probably its an implementation issue in the rabobank bankieren app. But this solution is fine for me.
In fact , routing dns requests to localhosts instead of a 'remote' service is faster at the end (probably unnoticeable , but anyway ;) ) -
Hi @tabnul,
You are my HERO! Also want to thank you for replying to my post. Many many thanks.
Any explanation why routing DNS to 127.0.0.1 instead of 10.10.10.1? Look also forward to how you figured this out…
Again, you are the King
Regards,
Herman -
@Herman
I dont know why this fix solves it but apparently the app expects a valid api response from google analytics whenever it gets a non 4** response code. When routing to 127.0.0.1 it receives a 404 , apparently thats fine.Probably it will break again when you run a webserver on your local machine listening on port 80 this way.
It was just a wild guess from my side.IMO this still is a bug in the App, and/or the google SDK they used for setting up the logic.
-
Thanks a lot for your explanation. Anyway it works.
Is there a possibility that no blocking results are shown at the alerts after the change to 127.0.0.1? It keeps showing 0. Even after updating and reloading. Any Thoughts?
Herman
-
You are right, this seems to mess up the stats... thats a shame.
Apparently stats are collected by http requests on the virtual ip. -
what might be the case here is that the issue is caused by an invalid SSL certificate on the virtual IP adress. In fact i would expect that.
(i mean the original issue) -
probably it is the issue.
you can fix it by handling the google ad services differently. they wont get logged then, but everything else will.
See;
https://forum.netgate.com/topic/111095/dnsbl-certificate-errors/46
and
https://forum.netgate.com/topic/133055/dnsbl-modify-default-bloked-webpage/30 -
@tabnul
Again many thanks for your input.I have read the articles. When I am right I have to null route the google domains? Right? I must admit that I am not a deep dive nerd when it comes to routing.
Would you like to explain how I have to configure this regarding the banking app?
Thanks in advance,
Herman -
Tried to figure it out by myself with the websites you provided. Unfortunately I do not get it working. So if someone would like to help I appreciate this…
Regards Herman
-
Hello,
I just whitelist these URL's. Now de Rabobank App is working again.app-measurement.com # RabobankAPP
.sdk.split.io # RabobankAPP2
.f2.shared.global.fastly.net # CNAME for (sdk.split.io)
.events.split.io # RabobankAPP3
.events-prod-1-1033355748.us-east-1.elb.amazonaws.com # CNAME for (events.split.io)
.tags.tiqcdn.com # RabobankAPP4
.tags.tiqcdn.com.edgekey.net # CNAME for (tags.tiqcdn.com)
.e8091.a.akamaiedge.net # CNAME for (tags.tiqcdn.com)Maybe only the last 3 url's is enough. That i didn't test.
-
Hi, I am truly sorry to revive this old thread but I just wanted to point out that I have come across this same issue with the ING Spain bank app on Android, it's the same issue as Rabo Bank mentioned here, but with ING Spain instead. The issue also seem to related with ".app-measurement.com" from my brief testing, but it could be others (ingdirect.es, ing.es, ing.com, ing.net and ing.nl). I thought that creating a new thread just for this would be pointless so that's why I am using this old thread.
Pointing DNSBL Virtual IP Address's to 127.0.0.1 instead of 10.10.10.1 works for me. However that breaks "DNSBL Block Stats" and it stops updating which is a shame because it was useful and nice to see what was getting blocked.
The user @tabnul tabnul mentions there could be a fix to handle .app-measurement.com (as they call it Google Ad Servcies) differently by pointing to different other threads however I am also lost on how to do what they say, perhaps it's because I am also not a deep dive nerd like the user @Herman who started this thread
.
I don't want to whitelist .app-measurement.com since one of the reasons of me installing pfBlockerNG was to block stuff like that (adverts and telemetry mainly) and that URL is specifically for Google Analytics on Android apps. So I don't really know what to do.
Does anyone have any idea after all these years on what could be done?
Thanks in advance.
-
@nanopulga
A bank app that uses or 'needs' ".app-measurement.com" to be accessible ?
No way .....
Afaik, it's the phone OS that collect app usage, and then calls home with the info. If it can't send the info, it shouldn't stop you from using the app.....@nanopulga said in pfBlockerNG blocking access to android bank app:
Pointing DNSBL Virtual IP Address's to 127.0.0.1 instead of 10.10.10.1 works for me
Why 127.0.0.1 ?
Just :
== 0.0.0.0 and you're fine.
pfBlockerng logging and stats work fine. -
@Gertjan It works! The bank app works fine and the logging also works fine. Thank you so much!
I did have to enable "Unbound python mode" which I actually saw you mention in another thread hah! Here: Pfblocker not working (not blocking ads or sites): I found it while googling for "Null block (logging)", since just with "Unbound mode" I couldn't see the option "Null Block (logging)" and I could only see "Null Block (no logging)"
-
Hummm.
Keep :to the default 10.10.10.1
Right now, you force the DNSBL web server to listen on address "0.0.0.0".
"0.0.0.0" is not what I call aThis address should be in an Isolated Range that is not already used in the Network.
Again, when you use this :
you'll be fine.
-
@Gertjan Oh yeah that's true, my bad, I changed it and the bank app and logging continue to work fine, thank you again.