Sorry, I was away a few days. Your theory is brilliant! I wouldn't have thought of it but it makes perfect sense. Thanks so much for seeing that, I will call AT&T and explain it basically as a "routing problem". The network is basically "unreachable" from my phone. I'm betting they will blow me off on this (after I go through the first 15 people who can't understand it) but at least I won't keep knocking my head against the wall. Might be an unsolvable problem, given their likely disinterest for one guy using an odd (to them) ISP solution.
Yes, all port are definately open. These failure *ONLY* happens from any of the family's AT&T cell phones, when WiFi is off.
I performed a service firewall restart. No difference.
I can run the command you noted above, but when do I run it and what am I looking for?
Here is the output from IPTABLES below. I don;t see anything in my /var/log/messages file except what appear to be legitimate DHCP requests from the server to the cellular modem. I've never seen my cell phone IP in any table or in any file anywhere.
I am saying that there is nothing in my blocked list, and I have added nothing manually. But, there are lots of chinese IP addresses in my security file showing attempted logins. Isn't the system supposed to see that and eventually blacklist them?
[root@me ~] # iptables -nvL INPUT
Chain INPUT (policy DROP 2713 packets, 124K bytes)
pkts bytes target prot opt in out source destination
119 9044 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 state RELATED,ESTABLISHED
63 3780 DROP all -- * * 18.104.22.168 0.0.0.0/0
4 240 DROP all -- * * 22.214.171.124 0.0.0.0/0
4 240 DROP all -- * * 126.96.36.199 0.0.0.0/0
0 0 DROP all -- * * 188.8.131.52 0.0.0.0/0
0 0 DROP all -- * * 184.108.40.206 0.0.0.0/0
214 8668 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
3428 669K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth4 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth4 * 169.254.0.0/16 0.0.0.0/0
582K 169M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
402K 47M ACCEPT all -- eth3 * 0.0.0.0/0 0.0.0.0/0
524 15196 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
29 1828 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
1 344 ACCEPT udp -- eth4 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth4 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
1 44 ACCEPT tcp -- * * 0.0.0.0/0 220.127.116.11 tcp dpt:1875
1 44 ACCEPT tcp -- * * 0.0.0.0/0 18.104.22.168 tcp dpt:20
1 44 ACCEPT tcp -- * * 0.0.0.0/0 22.214.171.124 tcp dpt:21
8945 882K ACCEPT tcp -- * * 0.0.0.0/0 126.96.36.199 tcp dpt:80
24 1717 ACCEPT tcp -- * * 0.0.0.0/0 188.8.131.52 tcp dpt:443
1 44 ACCEPT tcp -- * * 0.0.0.0/0 184.108.40.206 tcp dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 220.127.116.11 tcp dpt:135
1 44 ACCEPT tcp -- * * 0.0.0.0/0 18.104.22.168 tcp dpt:110
2 88 ACCEPT tcp -- * * 0.0.0.0/0 22.214.171.124 tcp dpts:60000:60999
4940 4092K ACCEPT tcp -- * * 0.0.0.0/0 126.96.36.199 tcp dpt:25
2760 594K ACCEPT tcp -- * * 0.0.0.0/0 188.8.131.52 tcp dpt:22
1 44 ACCEPT tcp -- * * 0.0.0.0/0 184.108.40.206 tcp dpt:83
34 5366 ACCEPT tcp -- * * 0.0.0.0/0 220.127.116.11 tcp dpt:236
0 0 ACCEPT tcp -- * * 0.0.0.0/0 18.104.22.168 tcp dpt:237
5891 760K ACCEPT udp -- eth4 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
564 186K ACCEPT tcp -- eth4 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Nick and Jeff,
Thanks for the replies. I have looked up my public IP, and there is nothing noting that IP either in the security log or the response to the IPTABLES command. I just see no reason for it at all. I also don't understand why there is nothing in my IDS blacklist when the security is obviously full of Chinese brute force login attempts.
I don;t know much about this sort of thing, just how to us the COS UI. But I am completely stumped why I cannot look at my web page with a cell phone when WiFi is fine. There's got to be some place where blocked IPs are stored! Shouldn't this be simple? I am so frustrated...
Yes, that is my public IP. No, 81 is not open. You are correct, putting that address in results in no web page if I am on cellular. On WiFi, it works fine.
I don't know what to look for on the IPTABLES command you noted. What am I looking for?
I see noting relevant in the log files you noted, but again, I am not clear what I am looking for. The snortsam log is essentially empty, is that normal?
Putting in the IP directly does not allow me to see the site so I don't think there is a DNS issue.
My domain is registered with ClearOS, I use them for everything. Regarding IP, I do have a static IP with AT&T for the server. No need for dynamic, and it was causing too many mail server block list problems. My cellular modem is pass through so there is no double-NATing.
Where can I look in ClearOS to see if any IPs are blacklisted? I can't get into the admin interface remotely, but I can SCP to see files today.
Thanks for the quick response. No, I did not change handsets. But your questions was a great one, and I had never thought to check.
NO, I cannot see www.whisperingwoods.org from my phone unless I am on WiFi!! What can do this?
I don;t have any firewall rules to block the page, and it is OK except from cellular. I am not familiar with IDS, or .htaccess - can you help me to get started there?
Looking through my logs, I found a log of attempted but failed logins. So, to be more careful I closed down port 22. I have not seen anymore strange uses of data since. I can't be sure that was it, but so far, so good.
Thanks for everyone's help, especially Nick!
Hi Nick & Friends,
I spoke too soon. The problem is not cured, but I performed more experiments and I now have a better description. The issue is not whether or not users are on the local network, it is whether or not they are on WiFi wherever they happen to be. In other words, email never works from cellular connection on the phone, but always works with a WiFi connection. To me, this means that the outgoing cellular connection on AT&T is what blocks success, but I do not know why.
One very quick way to reproduce this is to browse to the site mydomain.com/Microsoft-Server-ActiveSync. This will show a sign-on page via wifi and then give some zarafa Z-push info, but it will error with "page not found" on a cellular connection. How can that be for a web connection???
Perhaps this additional data will allow someone to know what the issue could be? Please???