iptables problem?
 

My iptables seem to be doing something funny to the forwarding from my local lan on to my NTL broadband internet.

What is the simplest form of setting up iptables so that it doesn't mess with anything yet forwards packets on my local lan?

I've followed the Redhat Bible 8 section on Masquerading, and it sort of works (messenger on my XP machine gets through) but can't ping anything on the internet or access any other sites.

Thanks,

Marc.

Your post is a bit confusing. What exactly is the problem? You may want to post your Iptables script so we can have a look. I have been wrestling with Iptables for a month straight and just finished so it's fresh in my mind. Also when you post it give us a brief description of your needs, ie. I need this or that port forwarded.

My problem is my xp laptop on the lan side of my linux machine isn't getting out consistently on the internet side of my linux machine - I'm assuming the problem is the iptables are messing with the packets somehow.

The behaviour of my laptop is:
- I can't ping anything on the internet, but it's picking up the right ip address
- Microsoft Messenger manages to connect through ok (so some stuff is definitely getting through)
- Outlook starts to download a little - like it connects, gets a few bytes and then just hangs
- Strange as it may sound, I can http to www.microsoft.com (but can't ping it) and I can http a little to some other sites (but this just stops after a few bytes)

The behaviour of my linux machine is:
- perfect; it does everything I want i.e. it connects nicely to the internet

As to what I'd like to happen is, on my laptop:
- http, smtp, pop, telnet to be routed from my laptop (10.0.0.2) to my eth1 (10.0.0.1) and then out on to eth0 (out to NTL broadband) with appropriate natting
- have all inbound traffic associated with this do the opposite so it finds its way back to my xp laptop (10.0.0.2)

iptables currently reports (although I've had various other things in at various times :):

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- 10.0.0.0/24 anywhere
ACCEPT all -- anywhere 10.0.0.0/24
DROP all -- !10.0.0.0/24 anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

The script for this is:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s ! 10.0.0.0/24 -j DROP

Marc

As an answer to one of your problems...Microsoft blocks ICMP requests, ie: no pings.

Try to ping www.yahoo.com

good point

I tried yahoo - it times out too.

Thanks,

Marc.

You need sone state matching rules to allow return traffic back into the local LAN...
eg,
iptables -I FORWARD -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

This picks up all the associated dns traffic with the conntrack mechanism and attaches it to the MASQUERADING tables to send it back to the LAN.

You will need some protection in there too... have a read of this tutorial

Peter,

I've managed to resolve the issue - it turns out it was a de-fragmentation issue on the XP client. When I did a fixed size ping of 1400 to the non-working websites, it worked! It was a regedit job to add an MTU value in to the TCP/IP workings.

As for your comment, although I'm trying to chomp my way thru the tutorial, I would have thought that setting up the MASQ on eth0 (the internet side) would translate the addresses on their return journey to eth1? Is your point that internet originating packets would not know how to find their way to eth1 if I added your suggested FORWARD? I guess this might be good idea for Messenger VOIP connections?

Thanks!

Marc.

Not exactly..

With traffic to external sites, there can be a lot of 'additional' return requests, eg dns replies, auth requests, icmp state replies.
The conntrack module ties these back to the original outgoing session to avoid them being thought of as new.
Most firewall setups block new incoming requests unless there is a specific server operating. They wouldn't normally get to the routing decision to be passed back into the LAN via the FORWARD chain if they are considerd NEW.
This is one of the many advantages over ipchains which must use external resources to do this.

I'm interested in your de-frag comment.
So long as the ip_conntrack module is loaded in the firewall, it should reassemble these packets before passing them back to the LAN.
Do lsmod and see if ip_conntrack is loaded...

So what EXACTLY is the difference between using -A and -I to add rules? (insert and add) ... do you use -A first, then the rest are -I'd?

Cheers

-A adds them to the end of the rule list
-I inserts them at a given line number, first line if you don't specify anything...

So what is the difference?

Surely appending the rules using -A, is the same as inserting them to the next free line, using -I ??

I think I am missing the point of -I ....

Perhaps you could give a practical example? Maybe using my ruleset in my previous post :)

Cheers

Yeah, the rules run in a sequence...
The first rule to match a packet wins... from the beginning to the last one.

The order of the rules is V important !
eg
Chain FORWARD (policy ACCEPT)
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s ! 10.0.0.0/24 -j DROP

Place the last rule first as an example...
What would get through?
Anything that came from the 10.0.0.0/24 network.
This would interfere with the other rules a lot...
You would only want a -s 10.0.0.0/24 if it came in on eth1 (local lan), certainly drop them if they came from anywhere else !!
and -d 10.0.0.0/24 only if the packets were verified as part of an ESTABLISHED,RELATED connection not from eth1.

The first rule that matches a packet takes that packet out of the chain. No further rules are looked at...
And it's not as simple as DROP rules go last... I have many DROP rules before ACCEPT rules to cut the crap out early,
but they are very specific rules... eg
iptables -A FORWARD -o eth1 -d 192.168.17.101 -j allowed_ip
makes sure that anything entering the eth1 lan for my server on .101 comes from a list of trusted ip's in the 'allowed_ip' chain.
Each ip in the allowed_ip chain has -j RETURN to step back to the next FORWARD rule & a final -j LOG & -j DROP to record activity.
This would live in the first 3 or 4 rules, before the state matching rules to block any server generated requests. (there are no users on this server)
The tutorial I mentioned is a good read, & it explains the reasoning behind the placement of the rules.

Hi Peter,

Meant to respond before now....

The defrag comment was from me cross-posting my problem on ExpertsExchange - the referenced article that cured by problem (although I'm still getting a few funnies, but this is probably something else) is:

http://www.annoyances.org/exec/show/article04-107

(credit to Stephen Lewis who pointed me in this direction).

Although I said a defrag problem, it doesn't mention it on this page, but I'm sure I read it somewhere else in relation to my problem.

Does this make sense?

BTW, thanks for all the other iptables stuff - it helps my understanding.

Marc.