[SOLVED] CentOS 6.2: Unable to fetch data from SSL sites (cURL, wget, etc)
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
CentOS 6.2: Unable to fetch data from SSL sites (cURL, wget, etc)
Hi,
My machine is running CentOS 6.2
I've had a Perl script which I've been using for ages, which has previously had no problem (and still doesn't) fetching data using LWP from port 80 locations. However, attempting to fetch from any https locations (i.e. port 443), always fails, no matter what the site.
To simplify the diagnostics, I figured I'd try the same idea from the command line using cURL and wget, but these also fail with https, while they also both work fetching regular http data.
Figuring that the same problem affects all three methods, I'm trying to ascertain exactly what it is that might be wrong, and how to fix it. It's a dedicated server, and I have root access so I can pretty much do what I want to.
I've tried forcing cURL to use ipv4, and a bunch of other flags that looked interesting, but I always end up with the requests failing with "curl: (7) couldn't connect to host".
Code:
$ cat debugdump.txt
== Info: About to connect() to www.xyz.com port 443 (#0)
== Info: Trying 194.xxx.xxx.xx... == Info: Connection timed out
== Info: couldn't connect to host
== Info: Closing connection #0
.. and similar connection time-outs with wget and netcat as well.
If I try fetching the same data with http, and with the -L flag (to follow redirects) then it will similarly fail on the secure portion of it.
If it's relevant, though I'm not really too familiar with firewalls, or even if this problem is related to firewalls, but FYI, the entries in /etc/sysconfig/iptables relating to port 443 (on my machine) are:
Code:
-A INPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X....
-A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X...
However, I'm not sure why/if I'd need to open port 443 (if it's not already open) anyway; I mean, I'm fetching from port 443 on another server, not listening for traffic on my 443; surely I'm using some other random port on my own machine to fetch with?
Anyway, basically I want to be able to retrieve remote data served via https, but am currently unable to do so. I know I definitely should be able to. I've spent ages trying to resolve this, and also asked the same question on another site, but so far to no avail. Thanks!
Last edited by cheddarcheese; 09-25-2017 at 09:22 AM.
Most sites these days are redirecting you to https (port 443) even when you initially go to http (port 80).
Most sites also have upgrades to only allow TLSv1.1 or TLSv1.2. The original curl on RHEL6 (and therefore CentOS6) only allowed for TLSv1.0 at max. Also that relies on openssl. You need to be sure your openssl and curl packages are at the latest versions.
Additionally most sites have gotten rid of older ciphers so you also have to update the nss package to get the later ciphers.
Also just for perversity I found lftp instead of using openssl for TLSv1.1 and higher uses gnutls which also has to be upgraded to allow those.
"yum update openssl curl nss gnutls" should update you to the later versions of those products.
6.2 is fairly old so you might want to consider just doing "yum update" to get to the latest overall 6.x which 6.9 (for RHEL - not sure if CentOS 6.9 is out but if not at least 6.8 would be.)
Last edited by MensaWater; 09-25-2017 at 10:27 AM.
Thanks for the reply. I did the yum updates as you suggested, but still the same result ("connection timed out"). I haven't yet updated CentOS from 6.2, as I have a ton of live sites on the machine, and I'm slightly concerned in case of problems with the updating.
Although I realize updating CentOS is a good idea, which I'll get to at some point, I feel sure there is probably some resolvable issue which should get it working on 6.2. To my knowledge it has never worked (I've had the machine five years), but it's never been something I've needed to do until now, as the sites I needed to fetch from would also serve via http as well. (but now only https).
Any other suggestions very welcome.
Last edited by cheddarcheese; 09-25-2017 at 10:59 AM.
What does "yum list installed openssl curl nss gnutls" output?
It may be the fixes aren't in update packages 6.2 given how old it is as there may be other package dependencies.
on a RHEL6.5 where I had done the updates I show these versions:
Installed Packages
curl.x86_64 7.19.7-37.el6_4 @anaconda-RedHatEnterpriseLinux-201311111358.x86_64/6.5
gnutls.x86_64 2.12.23-21.el6 @rhel-6-server-rpms
nss.x86_64 3.28.3-3.el6_9 @rhel-6-server-rpms
openssl.x86_64 1.0.1e-57.el6 @rhel-6-server-rpms
Does "yum list available openssl curl nss gnutls" show versions at or above the ones I list above?
Rereading your original post I see you say it failed with nc as well. That suggests the other side isn't LISTENing on port 443 at all. If you run "nmap -P0 www.xyz.com" it should show what ports appear to be open on the other end. If it doesn't show 443 it may be they aren't LISTENing on that, their firewall is blocking that or your own internal firewall DEVICE (i.e. not your server's iptables) is blocking that.
You can rule out your own servers iptables by temporarily disabling iptables and trying to connect. If it still fails when iptables is disabled then you know that isn't the issue.
Last edited by MensaWater; 09-25-2017 at 11:47 AM.
Output from "yum list available openssl curl nss gnutls" is:
Code:
]# yum list available openssl curl nss gnutls
Loaded plugins: fastestmirror, presto, security
Loading mirror speeds from cached hostfile
* base: mirror.datto.com
* extras: mirror.es.its.nyu.edu
* updates: centos.mirror.constant.com
Error: No matching Packages to list
I can fetch from the same sites in question with another CentOS machine, using the same tools, and no reason to think my IP would be blocked, as I can download other stuff from non-SSL URLs at the same location(s).
Ah, progress ...So, I saved and then disabled the iptables, tried the fetch again - which was successful - and then restarted the iptables (for security reasons, until I have a permanent fix). For anyone's future reference:
Code:
# /etc/init.d/iptables save
# /etc/init.d/iptables stop
# [run my command(s)]
# /etc/init.d/iptables start
However, I'm kind of clueless when it comes to firewall configuration, etc, so all I currently know is that if the iptables are disabled then it works, but if they're active then it doesn't. What do I need to add/remove from iptables to make a permanent fix? Thanks!
Last edited by cheddarcheese; 09-25-2017 at 12:34 PM.
If it is working for another client as you mention perhaps comparing iptables of the 2 servers would help. (It is possible the other one isn't doing jump targets at all or specifying any OUTPUT rule for port 443.)
P.S. Since the versions of packages you have are higher than those I listed they aren't likely the issue.
Okay, I've taken a look at the info' at the link provided, and tried to make sense of it, but - as interesting as it is - I'm honestly not really certain what it is I need to be looking for. I've only a very vague idea about iptables at the best of times, and I'm not sure I can understand the info' provided there well enough to help me. I can post the whole iptable from my machine if it would help anyone.
As an FYI: firewalld is a frontend for iptables. While you shouldn't directly edit iptables on RHEL7 with iptables commands you can look at them as you can on earlier versions of RHEL.
It appears the chain you're jumping to is allowing only specific IP ranges for outbound port 80 and port 443 connections as for example:
-A Cid2676X8888.0 -d 6x.xxx.xxx.xx5/32 -j ACCEPT
That line is allowing anything in the /32 network of the IP you masked. /32 allows only 1 address so if for example that IP was 61.100.212.105 the /32 would allow you to reach 61.100.212.105. Since you have multiple such rules you'd be able to reach each of the IPs specified in those rules.
In your original post you indicated it failed when "trying"
194.xxx.xxx.xx...
Since your jump chain is only allowing 6x........ addresses that is likely your issue. You'd have to add a rule like the following to that jump chain:
-A Cid2676X8888.0 -d 194.xxx.xxx.xx5/32 -j ACCEPT
You might first want to examine that entire jump chain to be sure you know all the rules within it with this syntax.
iptables -nL Cid2676X8888.0
If you run "iptables -nL --line-numbers" it will show you line numbering within all the chains. To add a rule you determine the best place to add it within the chain then specify the line number.
So if you saw line numbers in Cid2676X8888.0 such as 1 through 37 with the last line being a special rule to block everything else you'd want to insert the new rule above line 37 say at line 36:
iptables -I Cid2676X8888.0 36 -d 194.xxx.xxx.xx5/32 -j ACCEPT
NOTE: The above is an example - you need to review your iptables before making such a change.
Also if you run "iptables-save >/etc/sysconfig/iptables-save.YYYYMMDD" (where the suffix is year, month day) before you make the change you will save rules that are in memory currently. You can also do "cp -p /etc/sysconfig/iptables /etc/sysconfig/iptables.YYYYMMDD" to save the current static file that gets loaded on restart of iptables (e.g. on a reboot). Ideally both should be the same but some people forget to overwrite that static file after making changes. Any time you make a change to iptables in memory (e.g. with the "iptables -I" mentioned above make sure to run iptables-save >/etc/sysconfig/iptables to save changes to that static file.
First, many thanks for the informative replies, MensaWater.
All of the masked IP addresses which I have in the iptables are on my own machine, although I had no hand in creating the original iptables. (i.e. these are all public IP addresses which host websites on my machine, rather than addresses which I want to retrieve from).
Code:
# iptables -nL Cid2676X8888.0
Chain Cid2676X8888.0 (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.176
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.177
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.178
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.179
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.180
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.181
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.182
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.183
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.184
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.185
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.186
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.187
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.188
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.189
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.190
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.191
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.192
ACCEPT all -- 0.0.0.0/0 6x.xxx.xxx.193
Looking through the table, I don't see anything related to that chain which would appear to reject anything. There is another chain, but which - to my novice eye - doesn't seem related to the question at hand, although it does reject everything with "reject-with icmp-port-unreachable".
Okay, I made a copy of the iptables, just in case.
Must admit I'm still a bit confused about the whole thing ... Like I mentioned in the original post, although I'm fetching from port 443 on a remote machine, does that necessitate my using port 443 on my machine to fetch it? I just figured that my request would be using any old random port (on my machine) to make the request to the remote 443 port.
Not immediately clear where I'd insert a rule, as I don't see which bit of the table is rejecting stuff, but would it be too ham-handed to just add something like:
to the table? My understanding is that using -I rather than -A would make sure the rule was above the other rules, rather than below. Or would the rules still trickle down to whichever bit is rejecting requests?
Here I've not used jump rules and I don't use OUTPUT rules in general as I'm usually only concerned about INPUT chains (i.e. what I'm allowing INTO the server vs what is allowed OUT of the server).
Your jump rule in the OUTPUT chain which in turn jumps to a different chain. The mere fact you are using an OUTPUT chain may by default block anything not explicitly listed in the jumped to chain. I think for your issue you can ignore the INPUT chain.
By default on RHEL/CentOS6 the OUTPUT chain contains only:
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
If you don't have that OR if the jump rule is above that it is probably being explicit to only those entries you have in the jump chain itself. Since your existing OUTPUT entry for jump specifies ports 80 & 443 it would send all those there unless you had something above it in the OUTPUT chain that would allow 80 & 443 for the 194.x.x.x you're trying to reach.
iptables is read top to bottom so the jump rule if it is the first thing in your OUTPUT chain is saying to redirect to the jump chain then I would think it would only allow OUT to the things listed in the jump chain.
So a couple of ways to solve it might be to add the rule I previously suggested or add a rule to the OUTPUT chain itself ABOVE the existing jump rule similar to the rule I suggested. The fact you have both your INPUT and OUTPUT chains using the same jump chain would make me NOT want to edit the jump chain itself but rather add to the OUTPUT chain instead.
I'm kinda confused to be honest. Guess that's why I don't like playing around with firewall stuff, as I don't really understand much of it.
Thing is, I want to be able to fetch from any https site, not just the one I was testing with (i.e. 194...).
So, below is an abbreviated version of my iptables, complete except for an identical range of IP addresses removed from several different rules/chains:
Code:
cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Mon Sep 25 12:11:56 2017
*filter
:INPUT DROP [6907441:352931352]
:FORWARD DROP [0:0]
:OUTPUT DROP [1884664:473339919]
:Cid10579X2466.0 - [0:0]
:Cid13055X10420.0 - [0:0]
:Cid13055X10420.1 - [0:0]
:Cid2676X8888.0 - [0:0]
:Cid2676X8888.1 - [0:0]
:Cid2690X8888.0 - [0:0]
:Cid2690X8888.1 - [0:0]
:Cid2714X8888.0 - [0:0]
:Cid6906X3849.0 - [0:0]
:In_RULE_1 - [0:0]
:RULE_0 - [0:0]
:RULE_10 - [0:0]
:RULE_4 - [0:0]
:RULE_6 - [0:0]
-A INPUT -i eth1 -p tcp -m tcp --dport 8600 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 8402 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 8400 -j ACCEPT
-A INPUT -s xx.xxx.xxx.130/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s xx.xxx.xxx.39/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -f -j RULE_0
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j RULE_0
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j RULE_0
-A INPUT -s 6x.xxx.xxx.176/32 -i eth0 -m state --state NEW -j In_RULE_1
-A INPUT -s 6x.xxx.xxx.177/32 -i eth0 -m state --state NEW -j In_RULE_1
....[bunch of other IP addresses in same range] ...
-A INPUT -s 192.168.250.15/32 -i eth0 -m state --state NEW -j In_RULE_1
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.1
-A INPUT -d 6x.xxx.xxx.176/32 -p tcp -m tcp --dport 22 -m state --state NEW -j RULE_4
-A INPUT -p tcp -m tcp -m multiport --dports 53,25 -m state --state NEW -j Cid2690X8888.0
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j Cid2690X8888.0
-A INPUT -p tcp -m tcp --sport 20 --dport 1024:65535 -m state --state NEW -j Cid13055X10420.0
-A INPUT -p tcp -m tcp -m multiport --dports 21,80 -m state --state NEW -j Cid13055X10420.0
-A INPUT -d 192.168.250.15/32 -p tcp -m tcp --dport 5555 -m state --state NEW -j Cid6906X3849.0
-A INPUT -p tcp -m tcp --dport 113 -m state --state NEW -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state NEW -j RULE_10
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -f -j RULE_0
-A FORWARD -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j RULE_0
-A FORWARD -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j RULE_0
-A FORWARD -s 6x.xxx.xxx.176/32 -i eth0 -m state --state NEW -j In_RULE_1
-A FORWARD -s 6x.xxx.xxx.177/32 -i eth0 -m state --state NEW -j In_RULE_1
....[bunch of other IP addresses in same range] ...
-A FORWARD -m state --state NEW -j RULE_10
-A OUTPUT -o eth1 -p tcp -m tcp --dport 8600 -j ACCEPT
-A OUTPUT -o eth1 -p tcp -m tcp --dport 8402 -j ACCEPT
-A OUTPUT -o eth1 -p tcp -m tcp --dport 8400 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -f -j RULE_0
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j RULE_0
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j RULE_0
-A OUTPUT -o lo -m state --state NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.0
-A OUTPUT -d 6x.xxx.xxx.176/32 -p tcp -m tcp --dport 22 -m state --state NEW -j RULE_4
-A OUTPUT -p tcp -m tcp -m multiport --dports 53,25 -m state --state NEW -j Cid2690X8888.1
-A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j Cid2690X8888.1
-A OUTPUT -p tcp -m tcp --sport 20 --dport 1024:65535 -m state --state NEW -j Cid13055X10420.1
-A OUTPUT -p tcp -m tcp -m multiport --dports 21,80 -m state --state NEW -j Cid13055X10420.1
-A OUTPUT -s 192.168.250.15/32 -p tcp -m tcp --dport 9900:9999 -m state --state NEW -j Cid10579X2466.0
-A OUTPUT -p tcp -m tcp --dport 113 -m state --state NEW -j Cid2714X8888.0
-A OUTPUT -m state --state NEW -j RULE_10
-A Cid10579X2466.0 -d 192.168.210.5/32 -j ACCEPT
-A Cid10579X2466.0 -d 192.168.210.41/32 -j ACCEPT
-A Cid13055X10420.0 -s 6x.xxx.xxx.176/32 -j RULE_6
-A Cid13055X10420.0 -s 6x.xxx.xxx.177/32 -j RULE_6
....[bunch of other IP addresses in same range] ...
-A Cid13055X10420.1 -s 6x.xxx.xxx.176/32 -j RULE_6
-A Cid13055X10420.1 -s 6x.xxx.xxx.177/32 -j RULE_6
....[bunch of other IP addresses in same range] ...
-A Cid2676X8888.0 -d 6x.xxx.xxx.176/32 -j ACCEPT
-A Cid2676X8888.0 -d 6x.xxx.xxx.177/32 -j ACCEPT
....[bunch of other IP addresses in same range] ...
-A Cid2676X8888.1 -d 6x.xxx.xxx.176/32 -j ACCEPT
-A Cid2676X8888.1 -d 6x.xxx.xxx.177/32 -j ACCEPT
....[bunch of other IP addresses in same range] ...
-A Cid2690X8888.0 -s 6x.xxx.xxx.176/32 -j ACCEPT
-A Cid2690X8888.0 -s 6x.xxx.xxx.177/32 -j ACCEPT
....[bunch of other IP addresses in same range] ...
-A Cid2690X8888.1 -s 6x.xxx.xxx.176/32 -j ACCEPT
-A Cid2690X8888.1 -s 6x.xxx.xxx.177/32 -j ACCEPT
....[bunch of other IP addresses in same range] ...
-A Cid2714X8888.0 -d 6x.xxx.xxx.176/32 -j REJECT --reject-with icmp-port-unreachable
-A Cid2714X8888.0 -d 6x.xxx.xxx.177/32 -j REJECT --reject-with icmp-port-unreachable
....[bunch of other IP addresses in same range] ...
-A Cid2714X8888.0 -d 192.168.250.15/32 -j REJECT --reject-with icmp-port-unreachable
-A Cid6906X3849.0 -s 192.168.210.5/32 -j ACCEPT
-A Cid6906X3849.0 -s 192.168.210.41/32 -j ACCEPT
-A In_RULE_1 -j LOG --log-prefix "RULE 1 -- DENY " --log-level 6
-A In_RULE_1 -j DROP
-A RULE_0 -j LOG --log-prefix "RULE 0 -- DENY " --log-level 6
-A RULE_0 -j DROP
-A RULE_10 -j LOG --log-prefix "RULE 10 -- DENY " --log-level 6
-A RULE_10 -j DROP
-A RULE_4 -j LOG --log-prefix "RULE 4 -- ACCEPT " --log-level 6
-A RULE_4 -j ACCEPT
-A RULE_6 -j LOG --log-prefix "RULE 6 -- ACCEPT " --log-level 6
-A RULE_6 -j ACCEPT
COMMIT
So, I see the line:
Code:
-A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.0
and then I see [what I think is] the first line of the chain:
Code:
-A Cid2676X8888.0 -d 6x.xxx.xxx.176/32 -j ACCEPT
So, if I'm not mistaken, you're suggesting to add a rule above the previous line, so it's the first in the chain? And that line would be something like:
Code:
-A Cid2676X8888.0 -d 194.xxx.xxx.xx5/32 -j ACCEPT
except for the fact that i need to allow all https addresses to be fetched, and not just that one. Even so, I don't quite understand what the rule would do that it doesn't already do, as it already appears to be allowed.
I think I'm missing some big point here somewhere but, if you're not sick of this post already, then any additional assistance would be gratefully received.
What I think you're missing is that iptables is not just one set of rules but rather a set of chains each of which have there own rules. By default you'd have only 3 chains like:
Notice you start with the same 3 chains as the default BUT where the default has ACCEPT on each chain you have DROP. This explains to me WHY your setup is using the jump chain from OUTPUT. It is basically saying to drop everything not otherwise addressed within the OUTPUT chain.
As I've stated before and you've seen in your most recent post you have a rule:
Code:
-A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.0
That rule is in the OUTPUT chain and the "-j Cid2676X8888.0" says to jump to the separate chain named Cid2676X8888.0.
You also have a similar rule in the INPUT chain:
Code:
-A INPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.1
If you notice this INPUT chain rule is actually jumping to a sligthly different chain (.1 instead of .0) than the OUTPUT chain rule.
Do you have any connection within the range of IPs you see in Cid2676X8888.0 chain that you can connect to via port 443? If so can you look for all rules that contain that IP?
Yeah, okay, I kinda-sorta get the drift with the chain idea, but I can still can't understand, given that it would appear to be set up to accept OUTPUT on 443, why it's failing.
All of the bits where I put "....[bunch of other IP addresses in same range] ..." are simply identical lines to the couple of lines directly above them, but with an extended range of IP addresses. There are actually about twenty addresses in total, in each of those sections. There are definitely no other references to 443, and the lines which I removed for the sake of readability are identical in every way, except the IP address, to the ones listed above.
I note the "-A OUTPUT -p tcp -m tcp -m multiport --dports 80,443 -m state --state NEW -j Cid2676X8888.0" line, and the further references in the actual Cid2676X8888.0 chain further down:
Code:
-A Cid2676X8888.0 -d 6x.xxx.xxx.176/32 -j ACCEPT
-A Cid2676X8888.0 -d 6x.xxx.xxx.177/32 -j ACCEPT
... bunch more addresses ...
... and this to me seems to say "yeah, that's good, I'm good with 80 and 443 traffic, go ahead" ... and it wouldn't follow any more rules in that chain. In fact outbound traffic to port 80 does indeed work.
I guess the iptables are deliberately restrictive, which is usually a good thing, but seems to be making my life a misery right now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
