PDA

View Full Version : [ubuntu] IPTables/NAT Help



tehtide
February 9th, 2012, 09:11 PM
I have a small NAT server that is running Ubuntu Natty and I'm having some issues with the Windows 7 NAT Clients browsers timing out when accessing https sites.

I'm using IPTABLES to do the NAT portion, and frequently when attempting to access https sites, gmail, google, facebook, the browsers are unable to connect to the web site. However non-https sites, bing, msn, fark, are fine during this time. Then after a bit you can resume browsing the https sites until it times out again.

The strange part is that non windows devices are fine... iPAD, Android phone. I have a laptop that I travel with and when not connected to this NAT I don't have any timeout issues, however when connected to the NAT I do have timeout issues.

Does anyone have any ideas on where I can start looking for the underlying issues on this?

Any information I can provide I will... thanks.

Doug S
February 10th, 2012, 08:09 PM
I would: Start watching the iptables packet counters, trying to observe which path packets are taking during a timeout event; Maybe add some debug iptables log entries to help, while also not flooding the log files too much; Watch the connection tracking table for any short established connection timeout (unlikely); Use wireshark or tcpdump to monitor at the packet level during a timeout event.
sudo iptables -v -x -n -L
sudo cat /proc/net/ip_conntrackMaybe you could post your iptables rule set here for us to look at.

tehtide
February 11th, 2012, 12:32 AM
result of sudo iptables -v -x -n -L


Chain INPUT (policy ACCEPT 103470 packets, 8094291 bytes)
pkts bytes target prot opt in out source destination
19904 13550329 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
278773 24403155 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0
1259351 694195151 ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
151242 25465769 ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
166481 85996810 ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 1231281 packets, 914280631 bytes)
pkts bytes target prot opt in out source destination


Anything jump out?

When I have some time this weekend I will setup some tracking with wireshark and try and get some logging going for iptables.

Doug S
February 11th, 2012, 12:38 AM
My apologies, I should have also asked for the nat table data.
sudo iptables -t nat -v -x -n -LAnd, actually, a better way, to get it all at once, might be:
sudo iptables-save -c

tehtide
February 11th, 2012, 01:11 AM
no problem.

FYI my out going internet facing connection is eth1 and my private network connection is eth0



# Generated by iptables-save v1.4.10 on Fri Feb 10 19:10:30 2012
*nat
:PREROUTING ACCEPT [57993:6910263]
:INPUT ACCEPT [105495:6016843]
:OUTPUT ACCEPT [24462:1832707]
:POSTROUTING ACCEPT [3925:333105]
[6743:388237] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:3128
[58074:2911185] -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
[24863:1781910] -A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Fri Feb 10 19:10:30 2012
# Generated by iptables-save v1.4.10 on Fri Feb 10 19:10:30 2012
*mangle
:PREROUTING ACCEPT [3161750:1794046154]
:INPUT ACCEPT [2809637:1669335031]
:FORWARD ACCEPT [337623:119729912]
:OUTPUT ACCEPT [2463886:2081403782]
:POSTROUTING ACCEPT [2802423:2201357167]
COMMIT
# Completed on Fri Feb 10 19:10:30 2012
# Generated by iptables-save v1.4.10 on Fri Feb 10 19:10:30 2012
*filter
:INPUT ACCEPT [105973:8491829]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2463887:2081404050]
[22399:13902252] -A INPUT -i lo -j ACCEPT
[701621:48786252] -A INPUT -i eth0 -j ACCEPT
[1979644:1598154698] -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
[161426:27550965] -A FORWARD -i eth0 -o eth1 -j ACCEPT
[176197:92178947] -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Fri Feb 10 19:10:30 2012

SeijiSensei
February 12th, 2012, 02:47 PM
I take it you're using Squid in transparent mode. I just use these rules:


-A PREROUTING -s 10.1.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o eth1 -j SNAT --to-source ext.ip.of router

That pushes all web requests from the LAN clients in 10.1.0.0/16 through the proxy and masquerades everything else. Replace "ext.ip.of.router" with the IP address on eth1.

tehtide
February 27th, 2012, 10:15 PM
Ok... I've stripped out the squid config from the IPTABLES and have run it for a couple weeks. Things have not changed... still getting interruptions when connecting to SSL sites.

I've had wireshark running but don't know what I'm looking for... same as trying to get through the conntrack file. What do I need to look for? Is there anything I can upload to get some help with trying to diagnose this?

thanks in advance...

kevdog
February 27th, 2012, 10:19 PM
SSL runs over a different port than port 80 (standard http). https is port 443. You would have to forward connections intending to connect on this port as a destination through the firewall as well.

tehtide
February 27th, 2012, 10:25 PM
SSL runs over a different port than port 80 (standard http). https is port 443. You would have to forward connections intending to connect on this port as a destination through the firewall as well.

All my forwarded ports have been killed off. The server is currently functioning totally as a NAT router. All browsing works fine EXCEPT for the occasional even where all of the sudden all SSL sites are unreachable. After a time, usually between 5 and 10 minutes, the SSL sites are able to be browsed again and things go back to normal.

This is my current IPTABLES setup:


# Generated by iptables-save v1.4.10 on Mon Feb 27 16:25:01 2012
*mangle
:PREROUTING ACCEPT [49507696:156752484296]
:INPUT ACCEPT [45220016:154850321372]
:FORWARD ACCEPT [4184782:1861479209]
:OUTPUT ACCEPT [23611586:60308560965]
:POSTROUTING ACCEPT [27801729:62171340070]
COMMIT
# Completed on Mon Feb 27 16:25:01 2012
# Generated by iptables-save v1.4.10 on Mon Feb 27 16:25:01 2012
*nat
:PREROUTING ACCEPT [267646:19308225]
:INPUT ACCEPT [243357:13522462]
:OUTPUT ACCEPT [10743:842348]
:POSTROUTING ACCEPT [2168:175223]
[179083:12692681] -A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Mon Feb 27 16:25:01 2012
# Generated by iptables-save v1.4.10 on Mon Feb 27 16:25:01 2012
*filter
:INPUT ACCEPT [2108616:130761385]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23611594:60308562261]
[158615:97153264] -A INPUT -i lo -j ACCEPT
[28186551:148729952970] -A INPUT -i eth0 -j ACCEPT
[14766234:5892453753] -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
[2155817:571008402] -A FORWARD -i eth0 -o eth1 -j ACCEPT
[2028965:1290470807] -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Mon Feb 27 16:25:01 2012

tehtide
March 4th, 2012, 07:04 PM
Ok... so I've completely blown away the server in an attempt to correct this issue and have rebuilt using 11.10 again.

The ONLY service I have running on the box is LAMP and DHCP. I configured the NAT through webmin and the problem persists. I'm beginning to wonder how I'm to figure this out.

Mainly the issue happens with google.com

Is there anyone that can help me track this down? I don't really want to migrate off this new installation again, but I will if I have to.

Doug S
March 4th, 2012, 09:04 PM
I have a similar set up as you. I haven't had any troubles with https sites. I just made an https session with google webmaster tools and poked around for awhile and left it idle for awhile and such. I watched my conntrack table grow and shrink with activity and idle times. I did this from a windows vista computer. I might be able try the same from a windows 7 computer later.

My iptables is somewhat different than yours (at least the one you listed 5 days ago). I don't use the mangle table and I currently use SNAT instead of MASQUERADE. I have used MASQUERADE briefly about a year ago, and don't recall any troubles.

Sorry, I do not have any other suggestions at the moment.

tehtide
April 30th, 2012, 08:50 PM
I have a similar set up as you. I haven't had any troubles with https sites. I just made an https session with google webmaster tools and poked around for awhile and left it idle for awhile and such. I watched my conntrack table grow and shrink with activity and idle times. I did this from a windows vista computer. I might be able try the same from a windows 7 computer later.

My iptables is somewhat different than yours (at least the one you listed 5 days ago). I don't use the mangle table and I currently use SNAT instead of MASQUERADE. I have used MASQUERADE briefly about a year ago, and don't recall any troubles.

Sorry, I do not have any other suggestions at the moment.

Sorry to bring this one out from the dead... I thought I had it fixed but alas it seems to be rearing its ugly head.

Could you post your IPTABLE rules that you are using for doing the NAT?

I blew away the server and re installed using 12.04 LTS on beta 2 and things worked great until the final release. It is very odd in that it seems to come and go... it'll work just fine for a while and then it'll break for a bit and the it'll start right back up.

This is my current IPTables Setup not including the UFW stuff:



# Generated by iptables-save v1.4.12 on Fri Mar 9 22:27:11 2012
*nat
:INPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:3128
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
# Completed on Fri Mar 9 22:27:11 2012
# Generated by iptables-save v1.4.12 on Fri Mar 9 22:27:11 2012
*mangle
:PREROUTING ACCEPT [1:40]
:INPUT ACCEPT [1:40]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Fri Mar 9 22:27:11 2012
# Generated by iptables-save v1.4.12 on Fri Mar 9 22:27:11 2012
*filter
:INPUT ACCEPT [12:767]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7:753]
-A FORWARD -i eth0 -j ACCEPT
COMMIT
# Completed on Fri Mar 9 22:27:11 2012


And this is my squid config file:


acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 192.168.1.0/16
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 192.168.1.2:3128 transparent
cache_dir ufs /var/spool/squid3 7000 16 256
coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880
refresh_pattern . 0 20% 4320


I never have any problems with non https sites... just https site which is a little weird to me.

This server is running DHCP, DNS, NAT and SQUID3.

Any help would be appreciated it... thanks.

Doug S
May 1st, 2012, 04:09 PM
I do exactly the same as SeijiSensei posted on 2012.02.12.
I do not run Squid. When I said our setups are similair, I was referring to when you had taken squid out for testing.
Your treatment of http (port 80) and https (port 443) is different, so maybe it is not so weird that they behave differenly.

tehtide
May 1st, 2012, 05:01 PM
I do exactly the same as SeijiSensei posted on 2012.02.12.
I do not run Squid. When I said our setups are similair, I was referring to when you had taken squid out for testing.
Your treatment of http (port 80) and https (port 443) is different, so maybe it is not so weird that they behave differenly.

Doh... when I get in front of the box I'll test out that solution. I can't believe I didn't see that one.

Thanks for the heads up. I'll test it out and see if that helps anything.