# HTTPS issue + gentoo home router

## Tuinslak

Hi there,

I've been using a Gentoo server as home router for some time now, and this has been working great until recently.

I couple of months ago (December), I noticed that I couldn't access httpS://www.fon.com -- on any OS/PC (Linux, Winxp/7, Mac) at home, using 4 different browsers (FF, Safari, IE, Chrome). It basicly said "connected to fon.com" and stayed on that. I did not get a time out. 

I tried to run wireshark, and all I noticed were couple of packets being transmitted, basicly just a syn & ack, and a SSL hello. After that, no other packets came through. So NO 'useful' data is ever transmitted.

Now, the main problem is, that I can access these sites from the Gentoo router (using lynx), or when directly connecting a PC to the modem. So it's not a MTU or ISP issue.

The Gentoo router acts as PPPoE device (net-dialup/ppp-2.4.4-r24), and does Squid HTTP caching (no https, & I got the same issue when turning off squid; net-proxy/squid-3.0.19), and iptables. There are some other services running on the server, but none of which should affect internet traffic.

I also tried flushing most iptable rules, and keeping only the forwarding/masquerading bit, but this resulted in the same issue.

I have found other sites that I am unable to connect to as well, including some apple, microsoft, and bank HTTPS sites. However, there are https sites I can access without any problem.

When VPNing to another server outside this network, I of course can access all those websites without any problem. So the problem is somewhere between my client PCs and the Gentoo router. 

I tried a different switch as well, same issue. 

I also tried different kernels, .29-gentoo, .30-gentoo, .31-gentoo and .32-vanilla, all give me the same issue. And I know .29 and maybe even .30 used to work fine.

Problem exists on both the WiFi connection and UTP. So it's not a WiFi AP problem.

I recompiled system as well, and that didn't solve the issue either.

```
Sauron ~ # uname -a

Linux Sauron 2.6.32.2 #2 SMP Wed Jan 13 22:37:05 CET 2010 x86_64 AMD Opteron(tm) Processor 248 AuthenticAMD GNU/Linux

Sauron ~ # ls -ls /etc/ |grep profi

  0 lrwxrwxrwx  1 root   root     50 Jan 11 17:43 make.profile -> ..//usr/portage/profiles/hardened/linux/amd64/10.0

```

make.conf

I'm not entirely sure what more information I should provide you, feel free to ask  :Smile: 

I'm a bit clueless what might be the problem.

Thanks

Edit: this server is also running vmware server (v2) and a XP-client.

----------

## patrikas

Seems like it could be a problem with ip tables and connection tracking assuming you have problems mostly with SSL web sites, I am using gentoo router myself for years but didn't run into this issue, maybe playing around with ip tables kernel options might help ? enabling connection tracking modules, disabling experimental stuff (?), also re-check your firewall rules, resetting them and building once again might fix things.

----------

## Tuinslak

Well, I still have my old kernels that used to work. Booting from those doesn't solve the issue either.

iptables:

```
 # iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

DROP       tcp  --  anywhere             anywhere            tcp dpt:telnet

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http

REJECT     udp  --  anywhere             anywhere            udp dpt:bootps reje                                                                                            ct-with icmp-port-unreachable

REJECT     udp  --  anywhere             anywhere            udp dpt:domain reje                                                                                            ct-with icmp-port-unreachable

DROP       tcp  --  anywhere             anywhere            tcp dpt:ftp

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:222

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2222

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ntp

ACCEPT     udp  --  anywhere             anywhere            udp dpt:ntp

DROP       tcp  --  anywhere             anywhere            tcp dpts:0:1023

DROP       udp  --  anywhere             anywhere            udp dpts:0:1023

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:8333

Chain FORWARD (policy DROP)

target     prot opt source               destination

DROP       all  --  anywhere             10.0.0.0/24

ACCEPT     all  --  10.0.0.0/24          anywhere

ACCEPT     all  --  anywhere             10.0.0.0/24

ACCEPT     all  --  10.20.30.0/24        anywhere

ACCEPT     all  --  anywhere             10.20.30.0/24

TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/S                                                                                            YN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere
```

```
 # cat /var/lib/iptables/rules-save

# Generated by iptables-save v1.4.3.2 on Sat Feb 13 01:47:57 2010

*security

:INPUT ACCEPT [4403:306002]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [4202:776733]

COMMIT

# Completed on Sat Feb 13 01:47:57 2010

# Generated by iptables-save v1.4.3.2 on Sat Feb 13 01:47:57 2010

*raw

:PREROUTING ACCEPT [5141:350854]

:OUTPUT ACCEPT [4202:776733]

COMMIT

# Completed on Sat Feb 13 01:47:57 2010

# Generated by iptables-save v1.4.3.2 on Sat Feb 13 01:47:57 2010

*nat

:PREROUTING ACCEPT [1498:105175]

:POSTROUTING ACCEPT [18:3925]

:OUTPUT ACCEPT [18:3925]

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

-A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

-A POSTROUTING -o ppp0 -j MASQUERADE

COMMIT

# Completed on Sat Feb 13 01:47:57 2010

# Generated by iptables-save v1.4.3.2 on Sat Feb 13 01:47:57 2010

*mangle

:PREROUTING ACCEPT [5141:350854]

:INPUT ACCEPT [4403:306002]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [4202:776733]

:POSTROUTING ACCEPT [4228:780021]

COMMIT

# Completed on Sat Feb 13 01:47:57 2010

# Generated by iptables-save v1.4.3.2 on Sat Feb 13 01:47:57 2010

*filter

:INPUT ACCEPT [0:0]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [4166:772531]

-A INPUT -p tcp -m tcp --dport 23 -j DROP

-A INPUT -i lo -j ACCEPT

-A INPUT -i eth0 -j ACCEPT

-A INPUT -i tun0 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT ! -i eth0 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable

-A INPUT ! -i eth0 -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable

-A INPUT ! -i eth0 -p tcp -m tcp --dport 21 -j DROP

-A INPUT -i ppp0 -p tcp -m tcp --dport 222 -j ACCEPT

-A INPUT -i ppp0 -p tcp -m tcp --dport 2222 -j ACCEPT

-A INPUT -i ppp0 -p tcp -m tcp --dport 123 -j ACCEPT

-A INPUT -i ppp0 -p udp -m udp --dport 123 -j ACCEPT

-A INPUT -i ppp0 -p tcp -m tcp --dport 0:1023 -j DROP

-A INPUT -i ppp0 -p udp -m udp --dport 0:1023 -j DROP

-A INPUT -i ppp0 -p tcp -m tcp --dport 8333 -j ACCEPT

-A FORWARD -d 10.0.0.0/24 -i eth0 -j DROP

-A FORWARD -s 10.0.0.0/24 -i eth0 -j ACCEPT

-A FORWARD -d 10.0.0.0/24 -i ppp0 -j ACCEPT

-A FORWARD -s 10.20.30.0/24 -i tun0 -j ACCEPT

-A FORWARD -d 10.20.30.0/24 -i ppp0 -j ACCEPT

-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

-A OUTPUT -o lo -j ACCEPT

-A OUTPUT -o tun0 -j ACCEPT

COMMIT

# Completed on Sat Feb 13 01:47:57 2010
```

Here's my kernel config: http://home.tiete.be/tmp/config.txt

----------

## Hu

According to man iptables, clamping the MSS is only valid in the mangle table.  Your rules appear to place it in the filter table.

----------

## Tuinslak

That comes from the howto page

 *Quote:*   

> Incorrect MTU Value
> 
> If you experience odd errors (such as not being able to access some webpages while others load fine), you may be having Path MTU Discovery trouble. The quick way to test is to run this iptables command:
> 
> Code Listing 7.2: Circumvent MTU issues
> ...

 

I added that line not so long ago, hoping it would solve my problem, but it didn't.

However, I removed that line again, retested, and same issues exists.

----------

## Hu

From the same guide: *Quote:*   

> If that command does not work for you, you may want to try putting the rule into the mangle table. Simply add -t mangle to the command.

 

Also, when running mangling commands like that, it is helpful to run them before a terminating target such as ACCEPT.  If you examine the output of iptables-save -c, you will see that your ACCEPT rules are consuming the packet before it ever reaches your TCPMSS target.

----------

## Tuinslak

Aha, okay. That makes more sense now.

I just never thought it could be MTU related, as it worked fine on the router itself, but not 'within' the lan. 

Seems to work now. Big thanks!

----------

