Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] HTTPS help
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Sun Jun 09, 2013 7:59 pm    Post subject: [solved] HTTPS help Reply with quote

I installed my first purchased SSL certificate today. I've dabbled around with self-signed for years. I have installed it and it appears to work server-side with NameVirtualHost on :80 and :443.


This is what I get whenever I use curl on the host server or any system on the network (including over VPN).
Code:
supernova htdocs # curl https://localhost --insecure      ## Self-signed certificate, so --insecure is necessary
<html><body><h1>It works!</h1></body></html>              ## default virtualhost page
supernova ~ # curl https://newkindofcool.com
SSL works!                                                ## my https virtualhost docroot page


But when I try from anywhere outside of my network, past my NAT router (DD-WRT), I get this:

Code:
rich@area51 ~ $ curl https://newkindofcool.com
curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
rich@area51 ~ $ curl https://newkindofcool.com --insecure
curl: (52) Empty reply from server


I have TCP port 443 forwarded through my DD-WRT NAT router. I don't understand why it can get certificate information and then nothing else. Can someone help me figure out what is going on, please?
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1)


Last edited by BlueFusion on Sun Jun 09, 2013 10:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Sun Jun 09, 2013 8:40 pm    Post subject: Reply with quote

I have disabled the default SSL vhost as well but with the same results.

You can try yourself. Use the domain:

https://newkindofcool.com (should load the same data as http://newkindofcool.com now)

and the IP address:

https://99.153.28.241 (should load same as http://99.153.28.241)

Here's my DD-WRT port forward table:
http://newkindofcool.com/dd-wrt-settings.jpg

Here are the configuration files:
Code:
supernova vhosts.d # cat 00_default_ssl_vhost.conf
<IfDefine SSL>
<IfDefine SSL_DEFAULT_VHOST>
<IfModule ssl_module>
# see bug #178966 why this is in here

# When we also provide SSL we have to listen to the HTTPS port
# Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"
Listen 443
NameVirtualHost *:443

<VirtualHost *:443>
        ServerName localhost
        Include /etc/apache2/vhosts.d/default_vhost.include
        ErrorLog /var/log/apache2/ssl_error_log

        <IfModule log_config_module>
                TransferLog /var/log/apache2/ssl_access_log
        </IfModule>

        ## SSL Engine Switch:
        # Enable/Disable SSL for this virtual host.
        SSLEngine on

        ## SSL Cipher Suite:
        # List the ciphers that the client is permitted to negotiate.
        # See the mod_ssl documentation for a complete list.
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        ## Server Certificate:
        # Point SSLCertificateFile at a PEM encoded certificate. If the certificate
        # is encrypted, then you will be prompted for a pass phrase. Note that a
        # kill -HUP will prompt again. Keep in mind that if you have both an RSA
        # and a DSA certificate you can configure both in parallel (to also allow
        # the use of DSA ciphers, etc.)
        SSLCertificateFile /etc/ssl/apache2/server.crt

        ## Server Private Key:
        # If the key is not combined with the certificate, use this directive to
        # point at the key file. Keep in mind that if you've both a RSA and a DSA
        # private key you can configure both in parallel (to also allow the use of
        # DSA ciphers, etc.)
        SSLCertificateKeyFile /etc/ssl/apache2/server.key

        ## Server Certificate Chain:
        # Point SSLCertificateChainFile at a file containing the concatenation of
        # PEM encoded CA certificates which form the certificate chain for the
        # server certificate. Alternatively the referenced file can be the same as
        # SSLCertificateFile when the CA certificates are directly appended to the
        # server certificate for convinience.
        #SSLCertificateChainFile /etc/ssl/apache2/ca.crt

        ## Certificate Authority (CA):
        # Set the CA certificate verification path where to find CA certificates
        # for client authentication or alternatively one huge file containing all
        # of them (file must be PEM encoded).
        # Note: Inside SSLCACertificatePath you need hash symlinks to point to the
        # certificate files. Use the provided Makefile to update the hash symlinks
        # after changes.
        #SSLCACertificatePath /etc/ssl/apache2/ssl.crt
        #SSLCACertificateFile /etc/ssl/apache2/ca-bundle.crt

        ## Certificate Revocation Lists (CRL):
        # Set the CA revocation path where to find CA CRLs for client authentication
        # or alternatively one huge file containing all of them (file must be PEM
        # encoded).
        # Note: Inside SSLCARevocationPath you need hash symlinks to point to the
        # certificate files. Use the provided Makefile to update the hash symlinks
        # after changes.
        #SSLCARevocationPath /etc/ssl/apache2/ssl.crl
        #SSLCARevocationFile /etc/ssl/apache2/ca-bundle.crl

        ## Client Authentication (Type):
        # Client certificate verification type and depth. Types are none, optional,
        # require and optional_no_ca. Depth is a number which specifies how deeply
        # to verify the certificate issuer chain before deciding the certificate is
        # not valid.
        #SSLVerifyClient require
        #SSLVerifyDepth  10

        ## Access Control:
        # With SSLRequire you can do per-directory access control based on arbitrary
        # complex boolean expressions containing server variable checks and other
        # lookup directives. The syntax is a mixture between C and Perl. See the
        # mod_ssl documentation for more details.
        #<Location />
        #       #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
        #       and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
        #       and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
        #       and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
        #       and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
        #       or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
        #</Location>

        ## SSL Engine Options:
        # Set various options for the SSL engine.

        ## FakeBasicAuth:
        # Translate the client X.509 into a Basic Authorisation. This means that the
        # standard Auth/DBMAuth methods can be used for access control. The user
        # name is the `one line' version of the client's X.509 certificate.
        # Note that no password is obtained from the user. Every entry in the user
        # file needs this password: `xxj31ZMTZzkVA'.

        ## ExportCertData:
        # This exports two additional environment variables: SSL_CLIENT_CERT and
        # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the server
        # (always existing) and the client (only existing when client
        # authentication is used). This can be used to import the certificates into
        # CGI scripts.

        ## StdEnvVars:
        # This exports the standard SSL/TLS related `SSL_*' environment variables.
        # Per default this exportation is switched off for performance reasons,
        # because the extraction step is an expensive operation and is usually
        # useless for serving static content. So one usually enables the exportation
        # for CGI and SSI requests only.

        ## StrictRequire:
        # This denies access when "SSLRequireSSL" or "SSLRequire" applied even under
        # a "Satisfy any" situation, i.e. when it applies access is denied and no
        # other module can change it.

        ## OptRenegotiate:
        # This enables optimized SSL connection renegotiation handling when SSL
        # directives are used in per-directory context.
        #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>

        <Directory "/var/www/localhost/cgi-bin">
                SSLOptions +StdEnvVars
        </Directory>

        ## SSL Protocol Adjustments:
        # The safe and default but still SSL/TLS standard compliant shutdown
        # approach is that mod_ssl sends the close notify alert but doesn't wait
        # for the close notify alert from client. When you need a different
        # shutdown approach you can use one of the following variables:

        ## ssl-unclean-shutdown:
        # This forces an unclean shutdown when the connection is closed, i.e. no
        # SSL close notify alert is send or allowed to received.  This violates the
        # SSL/TLS standard but is needed for some brain-dead browsers. Use this when
        # you receive I/O errors because of the standard approach where mod_ssl
        # sends the close notify alert.

        ## ssl-accurate-shutdown:
        # This forces an accurate shutdown when the connection is closed, i.e. a
        # SSL close notify alert is send and mod_ssl waits for the close notify
        # alert of the client. This is 100% SSL/TLS standard compliant, but in
        # practice often causes hanging connections with brain-dead browsers. Use
        # this only for browsers where you know that their SSL implementation works
        # correctly.
        # Notice: Most problems of broken clients are also related to the HTTP
        # keep-alive facility, so you usually additionally want to disable
        # keep-alive for those clients, too. Use variable "nokeepalive" for this.
        # Similarly, one has to force some clients to use HTTP/1.0 to workaround
        # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
        # "force-response-1.0" for this.
        <IfModule setenvif_module>
                BrowserMatch ".*MSIE.*" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        </IfModule>

        ## Per-Server Logging:
        # The home of a custom SSL log file. Use this when you want a compact
        # non-error SSL logfile on a virtual host basis.
        <IfModule log_config_module>
                CustomLog /var/log/apache2/ssl_request_log \
                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
        </IfModule>
</VirtualHost>
</IfModule>
</IfDefine>
</IfDefine>

# vim: ts=4 filetype=apache


Code:
supernova vhosts.d # cat newkindofcool.com.conf   
<VirtualHost *:80>
        ServerName newkindofcool.com
        ServerAlias www.newkindofcool.com
        ServerAdmin webmaster@newkindofcool.com
        DocumentRoot "/home/ashbo/htdocs"
        <Directory "/home/ashbo/htdocs">
                Options Indexes FollowSymLinks
                AllowOverride All
                        Order allow,deny
                        Allow from all
        </Directory>
        <IfModule alias_module>
                ScriptAlias /cgi-bin/ "/home/ashbo/cgi-bin/"
        </IfModule>
        <Directory "/home/ashbo/cgi-bin">
                AllowOverride None
                Options None
                Order allow,deny
                Allow from all
        </Directory>

        <IfModule mpm_peruser_module>
                ServerEnvironment apache apache
        </IfModule>
</VirtualHost>

<IfDefine SSL>
<IfDefine SSL_DEFAULT_VHOST>
<IfModule ssl_module>
<VirtualHost *:443>
        ServerName newkindofcool.com
        ServerAlias www.newkindofcool.com
        ErrorLog /var/log/apache2/ssl_error_log
        ServerAdmin webmaster@newkindofcool.com
        DocumentRoot "/home/ashbo/htdocs"
        <Directory "/home/ashbo/htdocs">
                Options Indexes FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
        <IfModule alias_module>
                ScriptAlias /cgi-bin/ "/home/ashbo/cgi-bin/"
        </IfModule>
        <Directory "/home/ashbo/cgi-bin">
                AllowOverride None
                Options None
                Order allow,deny
                Allow from all
        </Directory>
        <IfModule log_config_module>
                TransferLog /var/log/apache2/ssl_access_log
        </IfModule>
        SSLEngine on
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile /etc/ssl/apache2/newkindofcool.com.crt
        SSLCertificateKeyFile /etc/ssl/apache2/newkindofcool.com.key
        SSLCertificateChainFile /etc/ssl/apache2/newkindofcool.com.ca-bundle
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory "/home/ashbo/cgi-bin">
                SSLOptions +StdEnvVars
        </Directory>
        <IfModule setenvif_module>
                BrowserMatch ".*MSIE.*" \
                        nokeepalive ssl-unclean-shutdown \
                        downgrade-1.0 force-response-1.0
        </IfModule>
        <IfModule log_config_module>
                CustomLog /var/log/apache2/ssl_request_log \
                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
        </IfModule>
</VirtualHost>
</IfModule>
</IfDefine>
</IfDefine>

# vim: ts=4 filetype=apache

_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1)
Back to top
View user's profile Send private message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Sun Jun 09, 2013 10:13 pm    Post subject: NAT/SSL issue Reply with quote

Some further information. I installed tcpdump on my server and watched the incoming traffic on port 443.

When I access it over the VPN, packets flow without issue: (note: 10.1.1.1 is the router which is also the VPN server, which is why it appears the traffic is coming from there)
Quote:
supernova ~ # tcpdump -i eth0 port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:02:37.395240 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [S], seq 1874311446, win 14060, options [mss 1406,sackOK,TS val 21386521 ecr 0,nop,wscale 7], length 0
18:02:37.395270 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [S.], seq 3964920988, ack 1874311447, win 14480, options [mss 1460,sackOK,TS val 582947366 ecr 21386521,nop,wscale 7], length 0
18:02:37.483111 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [.], ack 1, win 110, options [nop,nop,TS val 21386603 ecr 582947366], length 0
18:02:37.486565 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [P.], seq 1:336, ack 1, win 110, options [nop,nop,TS val 21386604 ecr 582947366], length 335
18:02:37.486589 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [.], ack 336, win 122, options [nop,nop,TS val 582947457 ecr 21386604], length 0
18:02:37.505071 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [P.], seq 1:1260, ack 336, win 122, options [nop,nop,TS val 582947475 ecr 21386604], length 1259
18:02:37.580790 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [.], ack 1260, win 132, options [nop,nop,TS val 21386705 ecr 582947475], length 0
18:02:37.585495 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [P.], seq 336:526, ack 1260, win 132, options [nop,nop,TS val 21386709 ecr 582947475], length 190
18:02:37.598764 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [P.], seq 1260:1311, ack 526, win 130, options [nop,nop,TS val 582947569 ecr 21386709], length 51
18:02:37.685193 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [P.], seq 526:628, ack 1311, win 132, options [nop,nop,TS val 21386806 ecr 582947569], length 102
18:02:37.685636 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [P.], seq 1311:1632, ack 628, win 130, options [nop,nop,TS val 582947656 ecr 21386806], length 321
18:02:37.774410 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [P.], seq 628:659, ack 1632, win 152, options [nop,nop,TS val 21386888 ecr 582947656], length 31
18:02:37.774498 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [P.], seq 1632:1663, ack 659, win 130, options [nop,nop,TS val 582947745 ecr 21386888], length 31
18:02:37.774643 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [F.], seq 1663, ack 659, win 130, options [nop,nop,TS val 582947745 ecr 21386888], length 0
18:02:37.780844 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [F.], seq 659, ack 1632, win 152, options [nop,nop,TS val 21386888 ecr 582947656], length 0
18:02:37.780856 IP 10.1.1.15.https > 10.1.1.1.39023: Flags [.], ack 660, win 130, options [nop,nop,TS val 582947751 ecr 21386888], length 0
18:02:37.849682 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [R], seq 1874312105, win 0, length 0
18:02:37.857445 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [R], seq 1874312105, win 0, length 0
18:02:37.860532 IP 10.1.1.1.39023 > 10.1.1.15.https: Flags [R], seq 1874312106, win 0, length 0


When I try the same curl request from an external source, not over VPN, not a single packet makes it to the server, according to tcpdump.

Okay, well then I logged into telnet on my router to verify that it is infact forwarding https to 10.1.1.15 (supernova). It is as it should be.

iptables on my firewall:
Code:
root@orbit:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:1723
ACCEPT     47   --  0.0.0.0/0            0.0.0.0/0           
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520
logaccept  tcp  --  0.0.0.0/0            10.1.1.1            tcp dpt:80
logaccept  tcp  --  0.0.0.0/0            10.1.1.1            tcp dpt:23
DROP       icmp --  0.0.0.0/0            0.0.0.0/0           
DROP       2    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state NEW
logaccept  0    --  0.0.0.0/0            0.0.0.0/0           state NEW
DROP       0    --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
ACCEPT     47   --  10.1.1.0/24          0.0.0.0/0           
ACCEPT     tcp  --  10.1.1.0/24          0.0.0.0/0           tcp dpt:1723
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
lan2wan    0    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:21
ACCEPT     tcp  --  0.0.0.0/0            10.1.1.254          tcp dpt:1792
ACCEPT     udp  --  0.0.0.0/0            10.1.1.254          udp dpt:1792
TRIGGER    0    --  0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
trigger_out  0    --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state NEW
DROP       0    --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Okay, so maybe there's a service on port 443 listening on the router?

Quote:
root@orbit:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN
tcp 0 0 99.153.28.241:1723 70.63.37.58:13541 ESTABLISHED
tcp 0 0 10.1.1.1:23 10.1.1.15:41819 ESTABLISHED
udp 0 0 127.0.0.1:34954 0.0.0.0:*
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
raw 0 0 99.153.28.241:47 70.63.37.58:* 47
raw 0 0 0.0.0.0:255 0.0.0.0:* 255


Nope, nothing is listening on port 443.

So I guess afterall, this is not an Apache/SSL issue. It appears to me to be something more network related.

Where the hell is this certificate coming from and where the hell are the packets going????

FWIW, and you can check this yourself, nmap is reporting that https is open as it should be. I don't believe my ISP is blocking it in any way, they claim not to block any ports (AT&T U-verse).
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1)
Back to top
View user's profile Send private message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Sun Jun 09, 2013 10:35 pm    Post subject: Reply with quote

A further update......

I found out how to get tcpdump working on my router.

It shows no activity when it comes to sending HTTPS data to is via the WAN to be forwarded. There's plenty of HTTPS data passing through as there are android clients and other devices constantly checking https websites. Not a darn thing relating to my requests, though.

Does this make sense to anybody? Any tips? What else should I check?
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1)
Back to top
View user's profile Send private message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Sun Jun 09, 2013 10:49 pm    Post subject: Reply with quote

Well my continuous devotion into the problem paid off.

Apparently it IS my ISP. It's not an intentional port block. If you have AT&T U-Verse and use a wireless AP for the set-top-boxes, it uses port 443 for a VPN tunnel. It has no ability to select a different port, unfortunately.

Time to buy some IP addresses :\
_________________
i7-940 2.93Ghz | ASUS P6T Deluxe (v.1) | 24GB Triple Channel RAM | nVidia GTX660
4x 4TB Seagate NAS HDD (Btrfs raid5) | 2x 120GB Samsung 850 EVO SSD (Btrfs raid1)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum