LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 02-21-2003, 07:38 AM   #1
poulaum
LQ Newbie
 
Registered: Feb 2003
Posts: 7

Rep: Reputation: 0
Unhappy 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.
 
Old 02-21-2003, 10:30 AM   #2
Pcghost
Senior Member
 
Registered: Feb 2003
Location: The Real Washington
Distribution: Ubuntu, Debian, SuSE, UnSlung, Android
Posts: 1,819

Rep: Reputation: 46
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.
 
Old 02-21-2003, 11:23 AM   #3
poulaum
LQ Newbie
 
Registered: Feb 2003
Posts: 7

Original Poster
Rep: Reputation: 0
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
 
Old 02-21-2003, 01:16 PM   #4
geoffm33
Member
 
Registered: May 2002
Distribution: RH 7.3 - YDL 2.3
Posts: 63

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

Try to ping www.yahoo.com
 
Old 02-21-2003, 01:28 PM   #5
poulaum
LQ Newbie
 
Registered: Feb 2003
Posts: 7

Original Poster
Rep: Reputation: 0
good point

I tried yahoo - it times out too.

Thanks,

Marc.
 
Old 02-25-2003, 03:59 PM   #6
peter_robb
Senior Member
 
Registered: Feb 2002
Location: Szczecin, Poland
Distribution: Gentoo, Debian
Posts: 2,458

Rep: Reputation: 47
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

Last edited by peter_robb; 02-25-2003 at 04:00 PM.
 
Old 02-26-2003, 02:57 AM   #7
poulaum
LQ Newbie
 
Registered: Feb 2003
Posts: 7

Original Poster
Rep: Reputation: 0
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.
 
Old 02-26-2003, 03:19 AM   #8
peter_robb
Senior Member
 
Registered: Feb 2002
Location: Szczecin, Poland
Distribution: Gentoo, Debian
Posts: 2,458

Rep: Reputation: 47
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...
 
Old 02-26-2003, 03:56 AM   #9
dunkyb
Member
 
Registered: Nov 2002
Distribution: Debian testing.
Posts: 143

Rep: Reputation: 15
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
 
Old 02-26-2003, 04:25 AM   #10
peter_robb
Senior Member
 
Registered: Feb 2002
Location: Szczecin, Poland
Distribution: Gentoo, Debian
Posts: 2,458

Rep: Reputation: 47
-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...
 
Old 02-26-2003, 05:14 AM   #11
dunkyb
Member
 
Registered: Nov 2002
Distribution: Debian testing.
Posts: 143

Rep: Reputation: 15
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
 
Old 02-26-2003, 08:40 AM   #12
peter_robb
Senior Member
 
Registered: Feb 2002
Location: Szczecin, Poland
Distribution: Gentoo, Debian
Posts: 2,458

Rep: Reputation: 47
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.

Last edited by peter_robb; 02-26-2003 at 08:54 AM.
 
Old 02-27-2003, 03:57 PM   #13
poulaum
LQ Newbie
 
Registered: Feb 2003
Posts: 7

Original Poster
Rep: Reputation: 0
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.

Quote:
Originally posted by peter_robb
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem iptables stomach Linux - Software 3 09-22-2005 02:21 PM
problem with iptables Israfel2000 Linux - Security 3 07-18-2004 12:30 AM
problem with iptables bladrag Linux - Networking 2 03-24-2004 03:08 PM
iptables problem bhagat_panwar Linux - Software 0 08-27-2003 06:45 AM
Problem with IPTABLES jfall Linux - Networking 3 11-04-2002 03:10 PM


All times are GMT -5. The time now is 12:28 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration