Iptables (with masq) troubleshooting, very simple script attached script and logs.
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
Iptables (with masq) troubleshooting, very simple script attached and logs produced.
Hello,
I'm quite an newcomer when it comes to iptables and packets in general.
I've tried many iptables scripts, first to get them working and then adjust.
At the beginning I thought the ones i tried first were broken, or simply not working, now i have come to the conclusion that its not anymore the script's problem.
The final one i tried and adjusted to log everything was win32sux's script gotten from here.
The problem itself is simple, the router/gateway computer can itself connect to everything, i suppose, well atleast http (tried with lynx) works, aswell as ping ofcourse.
Now the computer has two cards:
- eth0 > local network, needs to have access to the internet.
- eth1 > connected to the adsl modem.
- ppp0 > the pppoe interface, so to speak, dynamic ip.
Now the lan_computer with windows xp can ping, can also use dnsmasq to "nslookup" what i started on the router. And ping ofcourse.
Also it can check it's email, not download it. I once managed, i think, to download a message with the size of a kilobyte. Well i managed to send a 500KB message also, but never download it.
Web browsing doesn't work at all, again.
I'll attach the logs covering everything from me opening IE to me pressing stop after a minute or so.
Also i'll throw the modified (just to log) win32sux's script:
I'd like to thank in advance everyone who atleast gives me a hunch where to start correcting the problem.
I changed the MAC address on the first line and my local windows PC's IP (the one that needs NAT) for paranoia reasons :) Probably easier to read too. The other 64.x.x.x ip belongs to google.com.
Code:
#!/bin/bash
IPTABLES="/usr/sbin/iptables"
EXTIF="ppp0"
INTIF="eth0"
INTIF_IP="10.0.0.1"
INTIF_NET="10.0.0.0/8"
LO="lo"
LO_IP="127.0.0.1"
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/secure_redirects
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_nat_irc
#/sbin/modprobe ip_conntrack_irc
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
###############################################################################
### INPUT
###############################################################################
$IPTABLES -A INPUT -p ALL -m state --state INVALID -j LOG --log-level notice --log-prefix "(INPUT-D) INVALID: "
$IPTABLES -A INPUT -p ALL -m state --state INVALID -j DROP
$IPTABLES -A INPUT -p ALL -i $LO -s $LO_IP -j LOG --log-level notice --log-prefix "(INPUT-A) LOCAL: "
$IPTABLES -A INPUT -p ALL -i $LO -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p TCP ! --syn -m state --state NEW -j LOG --log-level notice --log-prefix "(INPUT-D) NEW NOT SYN: "
$IPTABLES -A INPUT -p TCP ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j LOG --log-level notice --log-prefix "(INPUT-A) ESTABLISHED: "
$IPTABLES -A INPUT -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p ICMP ! --fragment --icmp-type 8 -j LOG --log-level notice --log-prefix "(INPUT-A) ICMP 8: "
$IPTABLES -A INPUT -p ICMP ! --fragment --icmp-type 8 -j ACCEPT
$IPTABLES -A INPUT -j LOG --log-level notice --log-prefix "INPUT DROP: "
###############################################################################
### OUTPUT
###############################################################################
$IPTABLES -A OUTPUT -p ALL -m state --state INVALID -j LOG --log-level notice --log-prefix "(OUTPUT-D) INVALID: "
$IPTABLES -A OUTPUT -p ALL -m state --state INVALID -j DROP
$IPTABLES -A OUTPUT -p ALL -o $LO -s $LO_IP -j LOG --log-level notice --log-prefix "(OUTPUT-A) LOCAL: "
$IPTABLES -A OUTPUT -p ALL -o $LO -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $INTIF -s $INTIF_IP -j LOG --log-level notice --log-prefix "(OUTPUT-A) INTIF2LOC: "
$IPTABLES -A OUTPUT -p ALL -o $INTIF -s $INTIF_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $EXTIF -j LOG --log-level notice --log-prefix "(OUTPUT-A) IF 2 INET: "
$IPTABLES -A OUTPUT -p ALL -o $EXTIF -j ACCEPT
$IPTABLES -A OUTPUT -j LOG --log-level notice --log-prefix "OUTPUT DROP: "
###############################################################################
### FORWARD
###############################################################################
$IPTABLES -A FORWARD -p ALL -m state --state INVALID -j LOG --log-level notice --log-prefix "(FORWARD-D) INVALID: "
$IPTABLES -A FORWARD -p ALL -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -p TCP ! --syn -m state --state NEW -j LOG --log-level notice --log-prefix "(FORWARD-D) NEW NOT SYN: "
$IPTABLES -A FORWARD -p TCP ! --syn -m state --state NEW -j DROP
$IPTABLES -A FORWARD -p ALL -i $EXTIF -o $INTIF -m state --state \
ESTABLISHED,RELATED -j LOG --log-level notice --log-prefix "(FORWARD-A) ESTBL: "
$IPTABLES -A FORWARD -p ALL -i $EXTIF -o $INTIF -m state --state \
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -p ALL -i $INTIF -o $EXTIF -s $INTIF_NET -j LOG --log-level notice --log-prefix "(FORWARD-A) INTIF2LOC: "
$IPTABLES -A FORWARD -p ALL -i $INTIF -o $EXTIF -s $INTIF_NET -j ACCEPT
$IPTABLES -A FORWARD -j LOG --log-level notice --log-prefix "FORWARD DROP:
"
###############################################################################
### POSTROUTING
###############################################################################
$IPTABLES -t nat -A POSTROUTING -p ALL -o $EXTIF -j LOG --log-level notice --log-prefix "(POSTROUTING-A) MASQ2EXTIF: "
$IPTABLES -t nat -A POSTROUTING -p ALL -o $EXTIF -j MASQUERADE
echo "So let it be written, so let it be done..."
My short notes (I don't think that's everything):
* You block nearly everyting in INPUT. It's absolutely OK for packets coming from outside, but you should be less restrictive for inside (arp, DNS queries and other things that may be sent to the router).
* (OUTPUT) You only accept things from router's IP to the internal net.
I'll try to forward everything in this script too, but i, to be honest, doubt that it it makes a difference regarding the current situation. I've tried a few scripts before, out of the box, that also didn't work. They probably had everything free from the router too. But i'll give it a go now too.
The dropped UDP logging, i think was a wordpad mix-up perhaps with the new-line character when i opened it, or my own typo. Atleast when running it doesn't give out any errors, but i'll correct this anyway. Thanks.
Still hoping for someone to give me a solution to correct this whole problem
Originally posted by Mara My short notes (I don't think that's everything):
* You block nearly everyting in INPUT. It's absolutely OK for packets coming from outside, but you should be less restrictive for inside (arp, DNS queries and other things that may be sent to the router).
* (OUTPUT) You only accept things from router's IP to the internal net.
Doesn't this line already allow everything out?
Code:
$IPTABLES -A OUTPUT -p ALL -o $EXTIF -j ACCEPT
I added the line to allow everything that comes through the $INTIF (internal interface) and I'll see if it has any effect.
$IPTABLES -A INPUT -p ALL -i $INTIF -j LOG --log-level notice --log-prefix "(INPUT-A) INTIF 2 LOCAL: "
$IPTABLES -A INPUT -p ALL -i $INTIF -j ACCEPT
and
Code:
$IPTABLES -A OUTPUT -p ALL -o $EXTIF -j LOG --log-level notice --log-prefix "(OUTPUT-A) IF 2 INET: "
$IPTABLES -A OUTPUT -p ALL -o $EXTIF -j ACCEPT
After hours testing, no luck.
I can check my email and it managed to download one 2KB message that the linuxquestion-mailer sent
Again as i said, i can browse the net with lynx behind the router itself.
Ping works behind every computer (windows xp and 98, not that OS would matter).
I can also use DNS, straight or through the dnsmasq daemon, both work fine.
Mozilla behind the windows98 machine managed (it seemed) to download half of the google.com webpage, even 3 pixels horisontally of the image.
I also tried to remove the new-not-syn rules when going internal2outside, as i once saw NEW NOT SYN packed being dropped that the windows98 produced (to google's ip).
For clarification, I live in Europe, use ADSL with a dynamic IP, the modem is attached to eth1 and by starting adsl-start (roaring penguin) the ppp0 is "produced" and i've got net. Im running slackware 10 without the fancy whistles
Could it be some kind of a screw-up in connection tracking software, etc? By observing the ip_conntrack i see connections there, a few ESTABLISHED and most of them were FIN_WAIT.
I'm quite looking forward to clearing this problem, using the hardware router is very limiting, not to mention the hardware router has serious bugs, forwarding ports without me setting them up, and so on.
Now after troubleshooting for another 3-4 hours and checking the logs/ip_conntrack constantly i haven't yet managed to solve the problem.
While connecting to (trying to connect) google i saved the conntrack log.
IP's (local and my public) have been replaced for easier reading and security :)
It seems connections are nicely put as ESTABLISHED, the ip-table logging shows no DROPPED packets, on a few occasions i think i saw some SYN packets being dropped, but not constantly.
I have gone over the IP tables script many many times, and i am 99% sure that it is not the problem.
Are there perhaps some system variables that some script overwrote and now have not refreshed themselves after restarts that may have any effect on my problem?
I have to mentiot, that it seems like a little bit of information comes through still, like half of the google page, the <head> tags and the stuff between.
Is there any problems with max packet size etc? I haven't changed the default values as you can see from the script.
I am honestly waiting for someone with ideas, perhaps win32sux, the author of the script could pop a hint or two :P
I'm going to suggest a few additional rules that may help.
I'm not sure if ACK can get through your forward chain when
you initialize a connection, this should do the trick
If I remember the syntax correctly that should allow ACK flags through after you
send a SYN packet out. After recieving the ACK, you will send out a SYN,ACK
and then have an established connection. If I'm wrong someone please call me on
it.
You can also take another approach, and open up specific ports.
That opens destination port 80, which should allow you to access websights
(if your DNS is working). Notice the switching of dport and sport depending on
the direction of the traffic. Information on ports and what they do can be found
at:
Port 110 is for incoming mail, you may want to add your POP3 server
ipaddress into these rules. Use the -d and -s destination and source IP flags
for that.
Another thing I noticed is that ICMP can't get through your forward chain. This
is what I use
Code:
for i in {3,4,8,12};do
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -p icmp --icmp-type $i -j ACCEPT
done
for i in {0,3,4,11,12};do
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p icmp --icmp-type $i -j ACCEPT
done
A simpler way would be to just allow all ICMP, then tweak it once you get things
working.
$IPTABLES -A FORWARD -p icmp -j ACCEPT
Another thing you may want to try is to TEMPORARILY allow and log everything
in the forward chain. This should be done from the command prompt rather
than adding to your script.
Typing those in that order puts them in the top of your FORWARD chain.
Once you know that everything works properly without filtering, remove the rule,
Thank you very much for your hints.
Ill try it as soon as i get home tomorrow after work.
I'm not much of an expert on TCP-IP but it seemed the connection was forwarded but my computers didn't do anything, atleast didn't display any webpages:
According to this log line just before the RST (reset):
Sep 11 20:41:28 router kernel: (FORWARD-A) ESTBL: IN=ppp0 OUT=eth0 SRC=66.102.11.104 DST=lan_computer LEN=1452TOS=0x10 PREC=0x00 TTL=53 ID=8966 PROTO=TCP SPT=80 DPT=3213 WINDOW=32476 RES=0x00 ACK PSH URGP=0
the server sent the ACK PSH (acknowledged and push to application as i found out) over and over. (the ESTBL prefix means that the connection had to be ESTALISHED before it was forwarded.)
So it feels like everything gets through but has a catch :)
Ill try your ICMP rules, and if that doesn't work, i'll try the forward everything, although as i said it seems to be forwarding everything already that needs forwarding (i dont see many DROPPED packets).
The logs prefixes (INPUT-A)/(FORWARD-A)/(INPUT-D) and so on mean the chain and action (A for ACCEPT and D for DROP) to clarify this.
To whomever gives me the solution or working hits towards it, i've got to thank somehow specially. Perhaps with some services, or an e-book or two :D
Hrm,
Is it possible that only the first SYN packets are getting MASQUERADED for some reason?
Otherwise wouldn't you have a
(POSTROUTING-A) MASQ2EXTIF:
after every
(FORWARD-A) INTIF2LOC
I know you do not want to give out IP's, but have you set the windows
IP's to an address in the same subnet as your gateway/router?
Or set up DHCP to do it for you?
Have you made sure they are unique IP addresses?
Is your routers internal interface ip address set up as the gateway on these computers?
If you are not running DHCP you generally have to enter all these manually
into windows.
On a side note, changing the postrouting rule will keep internal traffic internal,
I'm going to try out all the hints that you gave in a minute.
I am quite sure windows is set up correctly, the "lan_computer" on the logs i posted earlier is the windows computer.
The gateway is set to 10.0.0.1
The computers themselves are on different sub-subnets, so to speak.
Computers have 10.0.1.x and DHCP hands out 10.0.2.x addresses. It doesn't seem to be any problem, i think atleast, the subnet on the IP-Table is put to 10.0.0.0/8 which should give me the whole ~1677216 addresses.
Windows itself seems to be set up correct, as i said, i've tried and am trying the both continuesly (via DHCP and manual).
I can ping internet-servers behind the machine, so it makes me feel atleast like i've got internet access.
I can also resolve domains, straight and through the gateway's dnsmasq.
And I'm sure they're unique addresses. For testing here I only have the slackware 10 (gateway) and windows XP machine running, plus an extra hardware router that also has a different IP, but the problem persisted with me disconnecting it.
I'll apply the masquerading side note :)
Just to mention, while installing slackware i did recieve some errors, one was during some X special library or something, and some others from packages that I don't remember.
Nothing as far as i know concerning iptables and network.
Now if those packages would've been also corrupt i think they couldn't even been unpacked, therefor I want to believe that it's not due to some wrong byte in the middle of the packed iptables.tgz.
Thank you for your help, and I'll see if i can sort this problem out today, after a week of constant troubleshooting :)
PS: I forgot to mention that, as i said before too, i am able to check my email. Which is very strange, Outlook checks everything, shows me that there are no messages, incase there is one, it attempts to download it.
And i have managed, not very fast though, to download a 1-3KB email.
Sending mail also works. But MSN etc. seems not to.
Kind of feels like second and so on packets are lost somewhere.
But I'll try the tricks you proposed.
I'm from one side extremely pleased that i got the whole thing working, but from the other side, i'm very confused.
The problem was the switch, my connection setup was made up that the
Gateway computer was connected to the switch.
Switch was connected to my computer and another router.
Now when i moved the gateway cable to that other D-Link home gateway/router's regular slot everything started to work.
Now I don't actually realize why didn't everything work with the gateway computer connected straight to the switch. Everything for the switch remained quite much the same, its just like another computer, why should the switch care that i send him some packets to browse the net.
I can ofcourse route the whole connection through the D-Link router, but i can't figure out the reason what disturbed the switch.
But in general, many thanks to you, scottman.
Perhaps someone could enlighten me about the switch issue :)?
My only idea would be something to do with the layer 2 routing, and the gateway handing out packets with the ip, not the mac address? (Limited network knowledge)
Perhaps someone could enlighten me about the switch issue ?
My only idea would be something to do with the layer 2 routing, and the gateway handing out packets with the ip, not the mac address? (Limited network knowledge)
I ran into the same issue and have been scratching my had for almost a day. I'm not a newbie neither to iptables, nor to linux, but unfortunately get near to linux servers only occasionally these days, so my knowledge is a bit dusty.
I tried a basic iptables script at first and got the same issues as you (some websites worked, some not ... generally it was not only websites of course, but any kind of TCP connection ... some worked, some failed). Then I tried all sorts of iptables scripts I could find on the net for setting up a router.
Finally I've found this topic and your solution (plugging the router/gateway into another switch) instantly rang the bell. :-) I wonder how much time it took to remember if I had not found your hint. The answer to the problem is: MTU.
I quote from the manpage of pppoe (ie. man pppoe):
Code:
-m MSS Causes pppoe to clamp the TCP maximum segment size at the speci-
fied value. Because of PPPoE overhead, the maximum segment size
for PPPoE is smaller than for normal Ethernet encapsulation.
This could cause problems for machines on a LAN behind a gateway
using PPPoE. If you have a LAN behind a gateway, and the gate-
way connects to the Internet using PPPoE, you are strongly rec-
ommended to use a -m 1412 option. This avoids having to set the
MTU on all the hosts on the LAN.
Changing the default mtu=1492 to mtu=1412 fixed all problems. Of course this might be an overkill ... you could play around by increasing the mtu of the DSL connection and see if all sorts of TCP (web, ftp, etc.) still works. For me the fool-proof mtu=1412 is OK, since the router I'm setting up is just a temporary replacement for our broken DrayTek Vigor ADSL-router (we're getting a new one at the office in a few days, but need shared internet access in the meantime too).
I've since then changed the topology and the server multiple times, so I'll never be able to find the actual problem of that ancient issue. Perhaps the PPP software in the newer gateways does its own clamping, or the kernel, or what not.
Nice to hear that the router-workaround gave some hints to others!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
