[iptables NAT]Wel pingen, wel ssh, geen http-data

[Verwijderd]

Hulp gevraagd bij het volgende probleem:
Ik krijg mijn Linux NAT router niet werkend geconfigureerd.

Vanaf een client in mijn LAN:
Kan zoals de titel zegt wel pingen.
Kan ook ssh-en naar een computer op internet.
Ik kan echter niet wgetten van bijvoorbeeld nu.nl
(resolven lukt wel)

Ik heb de handleiding gevolgd die hier te vinden valt:
http://www.gentoo.org/doc/en/home-router-howto.xml


Al heel wat gezocht op “mijn probleem”, maar kennelijk komt het niet al te veel voor op internet. :-)
Ik zie vast iets over het hoofd, maar ik weet het echt niet meer... [zucht]


NAT Router Hard- en Software.
Mijn NAT router draait Gentoo PPC64. Laatste stabiele kernel. (2.6.38-gentoo-r6) Alle software up-to-date.
Kernel is zelf gecompileerd. Configuratie “min of meer” overgenomen van een al werkende router. (ook Gentoo, maar een wat oudere software-config)

Overigens:
Van de Code Listing 5.2: Setting up iptables heb ik zelf een bash-scriptje gemaakt. Toevallig komt mijn LAN-reeks overeen.
Ik wist dat ik “dat script” ook had draaien op mijn oude router. Nog even met dat scriptje getest omdat ik misschien een typfoutje over het hoofd zou zien. Nee, zelfde resultaat.


iptables-shell-scriptje:

code:

#!/bin/sh

echo "First we flush our current rules"
iptables --verbose --flush
iptables --verbose --table nat --flush
echo

echo "Setup default policies to handle unmatched traffic"
iptables --verbose --policy INPUT ACCEPT
iptables --verbose --policy OUTPUT ACCEPT
iptables --verbose --policy FORWARD DROP
echo

echo "Defining interfaces..."
export LAN=eth0
export WAN=eth1

echo "LAN interface = ${LAN}"
echo "WAN interface = ${WAN}"
echo


echo "Then we lock our services so they only work from the LAN"
iptables --verbose --insert INPUT 1 --in-interface ${LAN} --jump ACCEPT
iptables --verbose --insert INPUT 1 --in-interface lo --jump ACCEPT
iptables --verbose --append INPUT --proto UDP --dport bootps ! --in-interface ${LAN} --jump REJECT
iptables --verbose --append INPUT --proto UDP --dport domain ! --in-interface ${LAN} --jump REJECT
echo

echo "Allow access to our ssh server from the WAN"
iptables --verbose --append INPUT --proto TCP --dport 22 --in-interface ${WAN} --jump ACCEPT
echo


echo "Drop TCP / UDP packets to privileged ports"
iptables --verbose --append INPUT --proto TCP ! --in-interface ${LAN} -d 0/0 --dport 0:1023 --jump DROP
iptables --verbose --append INPUT --proto UDP ! --in-interface ${LAN} -d 0/0 --dport 0:1023 --jump DROP
echo

echo "Finally we add the rules for NAT"
iptables --verbose --insert FORWARD --in-interface ${LAN} --destination 192.168.0.0/255.255.0.0 --jump DROP
iptables --verbose --append FORWARD --in-interface ${LAN} --source 192.168.0.0/255.255.0.0 --jump ACCEPT
iptables --verbose --append FORWARD --in-interface ${WAN} --destination 192.168.0.0/255.255.0.0 --jump ACCEPT
iptables --verbose --table nat --append POSTROUTING --out-interface ${WAN} --jump MASQUERADE
echo

echo "Tell the kernel that ip forwarding is OK"
echo 1 > /proc/sys/net/ipv4/ip_forward
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done
echo

echo "This is so when we boot we don't have to run the rules by hand"
/etc/init.d/iptables save
echo

# route -output:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
84.105.182.0    0.0.0.0         255.255.254.0   U     3      0        0 eth1
127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo
0.0.0.0         84.105.182.1    0.0.0.0         UG    3      0        0 eth1

For the record:
# iptables -L -output:

code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     udp  --  anywhere             anywhere             udp dpt:bootps reject-with icmp-port-unreachable
REJECT     udp  --  anywhere             anywhere             udp dpt:domain reject-with icmp-port-unreachable
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:22
DROP       tcp  --  anywhere             anywhere             tcp dpts:0:1023
DROP       udp  --  anywhere             anywhere             udp dpts:0:1023

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DROP       all  --  anywhere             192.168.0.0/16      
ACCEPT     all  --  192.168.0.0/16       anywhere            
ACCEPT     all  --  anywhere             192.168.0.0/16      

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# iptables -t nat -L

code:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere

wget-output op de client:

code:

$ wget nu.nl
--2011-08-03 23:41:08--  http://nu.nl/
Resolving nu.nl... 62.69.179.198
Connecting to nu.nl|62.69.179.198|:80... connected.
HTTP request sent, awaiting response... 301 This object has moved
Location: http://www.nu.nl/ [following]
--2011-08-03 23:41:08--  http://www.nu.nl/
Resolving www.nu.nl... 62.69.184.24
Connecting to www.nu.nl|62.69.184.24|:80... connected.
HTTP request sent, awaiting response...

En dat blijft dan "eeuwig" zo staan...

[ Voor 4% gewijzigd door Verwijderd op 03-08-2011 23:44 . Reden: wget-output toegevoegd ]

[Verwijderd]

Opgelost!
Het bleek te liggen aan de MTU waarde van de WAN-interface.
Ziggo gaf 'm "automatisch" de waarde 576.

Handmatig terugzetten naar 1500 loste het probleem op: ifconfig eth1 mtu 1500

In dit topic werd gesproken over vertraging. In mijn geval was het dus afhankelijk van het protocol écht geen data.
([Ziggo] Ervaringen Topic - Deel 4)

Typisch was overigens dat als ik er een goedkoop Sitecom routertje aan hing alles wel werkte.
Of die sitecom dan de die MTU-verandering van Ziggo gewoon negeerde of intern een hele coole truc deed weet ik niet. Maar het werkte wel!
En het routertje was dus ook zo goedkoop dat ik de MTU op de WAN-interface niet uit kon lezen.

Gentoo-dingetje:
Overigens heb ik die MTU opgenomen in /etc/conf.d/net: mtu_eth1="1500"
Werkt niet!

Dat iedereen het maar even weet...