FYI to other Linksys firewall users and network admins...
I've run into a problem with the SPI firewall on the EA series of Linksys routers. With the SPI Firewall enabled, push notifications for Android devices on WiFi never make it to the device. Thus things like Google Voice only notify upon sync (i.e. every 5 minutes or whatever interval is set).
After upgrading the firewalls in 2 of our offices from TomatoUSB powered units to new EA4500 routers, users started complaining about their phones no longer receiving notifications in a timely manner.
So far I've tested it with the EA4500 and the EA4200v2. My assumption is the problem will affect any EA series router as they share similar code for the SPI Firewall feature.
My guess is that the firewall is overly sensitive to inbound requests to the devices behind the firewall and blocks what it thinks is unsolicited traffic.
To resolve the problem and allow Android devices to successfully receive push notifications when connected to WiFi on these units, disable the SPI firewall for IPv4 (and IPv6 if it's in use).
In the new Cisco Connect Cloud version of the firmware for these, that setting is located in Security -> Firewall.
Related
Hi,
I'm trying to connect from a host (PC or other) to a mobile cellular Android device on the Verizon/AT&T cellular network. This device uses only the 3G network and has its Wi-Fi turned off. The Android device has a listening socket and I need the remote host to be the connection initiator. As far as I know, Verizon/AT&T uses NAT traversal for mobile phones and assigns local IP addresses to them on the cellular network. This prevents me from initiating a connection to the device from a remote host. Please correct me if I'm wrong about that.
With the usage of IPv6 assignments there shouldn't be any practical limitation (virtually unlimited) to the number of "real" IPs that can be assigned.
Therefore my questions are:
1. Does the Verizon/AT&T cellular network support IPv6 and assigns IPv6 addresses to capable Android devices?
2. Is it a feasible solution to this problem?
3. Does Android 2.2+ have enough support for IPv6 to implement such solution?
I am aware of other methods that can be used, such as C2DM, but it has some drawbacks (such as unknown response time) that prevent me from using it.
Thanks.
This works on T-Mobile with the Nexus S. ICS brings 3G IPv6 support to the Nexus S, and T-Mobile has an IPv6 beta. On that beta program, you sign up for IPv6 and made inbound connection to the phone, which has a public IPv6 address.
Hi guys,
Has any one else experienced any issue seeing multicast packets from the prime over the wireless connection? I have an app that I'm working on that basically listens for multicast heartbeat packets(230.0.0.1 port 8092) from local networked servers, then displays the servers it sees in the app. I have the same version of my app installed on a xoom tablet and a samsung galaxy tab 7+. The app runs fine and displays the server heartbeats on all other android devices i have tried it on. All devices I'm testing on are stock, updated to the latest release build.
All devices are also on the same local network (tablets and servers). I can pull up the servers local web page in the browser of the Prime, and the app is not generating any errors. It is hearing its own heartbeat but not the broadcast of the server heartbeat... so it seems like for whatever reason the wireless NIC is dropping these messages. This app isnt even using the android API, just a regular java socket.
I have narrowed it down to specifically the wireless connection not seeing the packets. I was able to do this by connecting a usb-ethernet adapter to the dock usb port, then connecting everything to a switch. If I do this, I can successfully run my app and see my multicast server packets on the prime. So it appears to be some sort of built in firewall on the wireless network side of things.
So any ideas why over wireless multicast packets are being dropped by the prime? Or how I can go about fixing my problem?
Thanks for any help!
actually it turns out it was my router. I guess for some reason it plays nice with most tablets, but the prime seems to have some problems with getting multicast packets from it. I tried a couple different routers, and found one that works with it.
I just noticed that my moto E (running CM11) is not correctly routing my traffic to my openvpn server. I noticed when I was looking at the current connections on my OpenWRT router that I could see the VPN's local IP address, and the remote connection:
IPV4 TCP 10.9.0.20:56657 157.166.xx.xx:80
Where 10.9.0.20 is my local VPN address, the other represents any remote address I connect to.
I could see all this in Luci's connection graphs, which means that OpenVPN is not sending my traffic over the tunnel at all, despite the reports from sites like ipleak.net and similar sites that tell me I have no leak . But if I can see the connections from my router, that means that when I connect over mobile data, my carrier can likely see all of my traffic. This is not what I want, I am having a hard time fixing it. Also, how is it even possible that my router is detecting the IP of my tun interface??
I tried two different OpenVPN frontends, tweaking the firewall on the phone (afwall+) and also playing around with the 'redirect-gateway' directives. I am not sure if this a DNS leak or total disobiedience on Android's part of my routing rules. The fact that I can see these connections from the router makes me think that the traffic is not even being encrypted before it's sent over the internet. My firewall rules are set so that every app is supposed to route over the VPN. These are my configurations:
Server Config:
mode server
tls-server
local x.x.x.x
port 35777
proto udp
dev tun0
ca /etc/openvpnca.crt
cert /etc/openvpn/randomcn.crt
key /etc/openvpn/randomcn.key
dh /etc/openvpn/dh.pem
topology p2p
server 10.8.0.0 255.255.255.0
;topology subnet
ifconfig-pool-persist ipp.txt
client-config-dir clients
;client-to-client
keepalive 7 80
tls-auth /etc/openvpn/ta.key 0
cipher AES-128-CBC
comp-lzo
max-clients 3
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
In my client directory, I have these settings. On my PC I do not have this IP leak problem despite the settings being the same:
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
I have dnscrypt running with unbound on the server, serving the clients. This configuration works on my PC, but it seems no matter what I do I still can see the vpn local IP and all of my remote connections with Luci on openwrt.
I have tried using both OpenVPN connect, Openvpn for Android, and I am currently trying to use the ICS binary as well. Can anyone help me solve this problem? My goal is to tunnel all my phones traffic over the VPN and prevent IP or DNS leaks.
Hello everyone,
I am new to Android development and am uncertain about the restrictions on STOCK phones.
The goal of my application is to exchange a small amount of data ~32 byte. It should use a method available for all phones (Android, iOS, Linux). Most phones always have mobile data and WiFi activated so my idea was to use WiFi.
I thought of two methods:
Method A
Phone A could add a new WiFi network to the list of known networks. The name of the SSID could be chosen (that's the transmitted message). Phone A would now send out WiFi probe requests. Phone B could listen to WiFi probe requests and extract the SSID (message received). The phones would not have to actually communicate over WiFi. The exchange of SSID names is all that needs to be achieved.
Method B
Phone A could send out a WiFi beacon. The name of the SSID could be chosen (that's the transmitted message). Phone A would now send out WiFi beacons. Phone B could scan available networks and extract the SSID (message received). The phones would not have to actually communicate over WiFi. The exchange of SSID names is all that needs to be achieved.
(I guess tethering would have to be possible. This might cause unwanted behavior if phone is actually supposed to be tethering. Also if I am correct tethering is sometimes restricted)
Preferably this should all work on stock phones. Differentiating between SSID that are messages and SSID which are regular networks (router..) is out of scope for this problem. If anybody has a hint for rooted phones, your help would also be greatly appreciated
Thank you very much for your help!
FreudigerMax
Some of my Android 11 devices with Always-On VPN apps ignore VPN tunnels when in Sleep Mode, even though "Always-On" and "Block Connections Without VPN" are enabled in Android Network & Internet settings. Local DNS resolver logs show that Android Sleep Mode WiFi activity includes Android devices attempting to resolve Google domains, such as google.com, connectivitycheck.gstatic.com, and play.googleapis.com outside of VPN tunnels using WiFi-assigned DNS resolver address instead of VPN-set resolver address. The same devices do use VPN tunnels in Sleep Mode when receiving email and other internet data. That means that VPN tunnel connection persists and isn't dropped in Sleep Mode.
It is almost as if there is a forced Android-set VPN Split Tunneling that can't be configured in any VPN apps. The same behavior happens with all VPN apps and protocols, but not on all devices. Disabling or enabling Battery Optimization for VPN apps makes no difference.
Some say that Captive Portal check is the issue, but none of following ADB Shell Captive Portal commands resolve this issue for me:
settings put global captive_portal_detection_enabled 0
settings put global captive_portal_server localhost
settings put global captive_portal_mode 0
settings put global wifi_watchdog_on 0
settings put global wifi_watchdog_background_check_enabled 0
pm disable com.android.captiveportallogin
This behavior is similar to how Android devices use carrier/SIM-card WiFi calling that also bypasses installed VPN apps and exclusively uses IPSec 3GPP ePDG tunnels to make/receive calls and/or SMS/MMS. Only app-based WiFi calling (WhatsApp, Viber, Skype, Telegram, Signal, etc.) and other internet apps can use installed VPN app tunnels.
There is definitely no way to tunnel carrier/SIM-card WiFi calling through installed VPN apps, but is there a way to prevent Android devices in Sleep Mode from trying to connect to google.com, connectivitycheck.gstatic.com, and play.googleapis.com outside of VPN tunnels? Connecting to those Google domains outside of VPN defeats the point of using a VPN!