help with youlube streaming
-
@stephenw10 snort is definitely impacting sygic map downloads.
I bypassed the VPN and when i snort off on the WAN interface, the downloads work.
I will do some testing whether youtube is affected by that -
@gwaitsi said in help with youlube streaming:
I bypassed the VPN
Which VPN? The one you didn't mention before?
Might be some geo fencing kicking in. Then it's designed behaviour. -
@jahonix for the map download, i am getting the following alert in Snort.
(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSEEven though i put the destination IP in the Pass List Alias, it is still getting an alert and not working.
When i turn off snort for the wan it works, so the traffic is definitely going over the wan and not the vpn.
i have both VPN and WAN defined as snort interfacesp.s. the streaming problem seems to have been client h/w, as i have tried another machine and it is working fine over wireless for an extended period. Just need to solve the snort problem with the map downloads
-
I would just disable the rule that's triggering on that. You will only see more false positives otherwise.
Steve
-
@stephenw10 how can i see which rule set it is in. It is also blocking some of my voip i see.
-
You can see it in the Snort Alerts. There is a link there to disable the rule directly. The red X icon.
https://docs.netgate.com/pfsense/en/latest/ids-ips/setup-snort-package.html#getting-to-know-the-alertsSteve
-
Several of the HTTP_INSPECT rules are overly aggressive in today's web application climate. Many web sites and web API services don't fully honor all the RFC standards, and this can cause some of the HTTP_INSPECT rules that enforce those standards to falsely trigger.
If you search the IDS/IPS sub-forum within the Packages forum you will find a Master Suppress List thread containing suggested rules to be disabled and/or suppressed in order to reduce false positives.
-
@bmeeks thanks for that. i disabled 120.3 and 120.8 which fixed the snort problem with downloading maps. but i still need to disable the pfblockerNG for the map download to work. I can't see what is causing it in the logs, cause the IP address doesn't show.
-
@gwaitsi said in help with youlube streaming:
@bmeeks thanks for that. i disabled 120.3 and 120.8 which fixed the snort problem with downloading maps. but i still need to disable the pfblockerNG for the map download to work. I can't see what is causing it in the logs, cause the IP address doesn't show.
I'm not a pfBlockerNG expert, but from what I do know it works by creating firewall rules to block IP addresses found on lists of bad IP actors. You should see whatever pfBlockerNG blocks in the firewall logs (and possibly elsewhere if it has its own alert logs).
-
Yes, make sure logging for it is enabled in pfBlocker and you should see exactly which rule it blocking it.
Steve
-
@stephenw10 i don't see the map address in firewall logs at all. the address is in the vpn bypass list and goes over the wan interface. it doesn't show in the dnsbl alerts either.
-
Run a packet capture for that IP on the WAN. Make sure that traffic actually is blocked by the firewall and isn't leaving and just getting no response.
Steve
-
You mentioned a VPN bypass list. Be aware that unless you configure pfSense to NOT pull routes from your VPN provider, then all of your traffic (both VPN and regular) will bounce through the default gateway provided by your VPN provider. Some services (in fact, quite a few) block the IP subnets of known VPN provider networks. So any traffic from your firewall, even non-VPN traffic, it it routes through your VPN provider's network can be dropped by the destination (in this case your maps service).
Here is a link to the specifics in the pfSense documentation about not pulling VPN routes: https://docs.netgate.com/pfsense/en/latest/book/openvpn/openvpn-configuration-options.html#don-t-pull-routes
-
@bmeeks this forum blocks vpn access and is in the vpnbypass alias i setup. the fact i am writing means the vpn bypass is working. the snort aspect has been eliminated via the two rules deactived and is now done to simply toggling BlockerNG. i.e. turning off, makes the download work, and on makes it not but i can't see any alerts or blocks in the rules
-
@gwaitsi said in help with youlube streaming:
@bmeeks this forum blocks vpn access and is in the vpnbypass alias i setup. the fact i am writing means the vpn bypass is working. the snort aspect has been eliminated via the two rules deactived and is now done to simply toggling BlockerNG. i.e. turning off, makes the download work, and on makes it not but i can't see any alerts or blocks in the rules
pfBlockerNG blocks thing using two methods. The first is a set of firewall rules that block IP addresses found on the IP lists you subscribe to and load into pfBlockerNG. The other method implements a customization of the Unbound DNS resolver using the DNSBL (DNS Blacklist). IP addresses found on this list will not resolve to their real IP address. I think they instead resolve to an internal web page on the firewall. If this is what is happening, then you won't find an alert in the firewall blocks logs. Look instead at the Unbound and DNSBL logging.
-
@bmeeks i run netstat on the android device and found a number of ports being redirected to 10.10.10.1, unfortunately i see that as the destination IP, so am still trying to work out what the original IP was.
-
That's the replacement page hosted on pfSense. That implies it's being resolved to that by DNSBL.
So one of the feeds you have added to DNSBL is blocking that URL. It implies mostly serves stuff you don't want, ads malware etc. You might reconsider whether you actually need that...
Steve
-
@stephenw10 is correct. It seems the DNSBL feature of pfBlockerNG is intercepting the attempted domain-to-IP lookup made by your phone and instead of sending your phone the real IP of the domain it is redirecting your phone to the internal web page hosted by the DNSBL code. That's what the 10.10.10.1 address is.
This is the problem that can result from using tools that use IP blacklists as the basis for their block decisions. Many of these lists are not always 100% accurate, and they sometimes tend to broad-brush when marking IP subnets as malicious. What I mean by that is they can unintentionally blacklist an IP address that is actually OK but just happens to be located within a larger block the blacklist is marking as bad. Of course it is also possible that DNSBL is flagging the IP block because it serves up ads.
