Re: [SLUG] iptables & netfilter TCP timeouts

[Martin Visser]

I haven't done a heck of a lot in anger with tuning iptables/netfilter
based firewalls

I know that on a Cisco ASA (formerly know as PIX) firewall the default
TCP established time-out is 1 hour and half-closed (which I think is
FIN wait) is 10 minutes.

These timers/counters are always a compromise between making sure
legitimate traffic is still allowed to work without needing
application "keep-alive" hacks, and make sure badly behaved or
malicious sources don't consume resources in the stateful connection
tables.

So that said, unless you are seeing something that looks like
resources are being consumed badly I would leave it. (And as you have
probably figured out these probably aren't likely to be connected to
delay issues)


Regards, Martin

martinvisse...@gmail.com



On Tue, May 4, 2010 at 12:35 PM, Kyle  wrote:
> I've been investigating some delays in my net connection recently and have
> become aware of the std tcp timeouts set in sysctl by netfilter's conntrack
> module.
>
> Namely;
>   ip_conntrack_tcp_timeout_established       5 days
> ip_conntrack_tcp_timeout_fin_wait           2 min's
> ip_conntrack_tcp_timeout_max_retrans    300
> ip_conntrack_tcp_timeout_syn_sent         2 min's
> ip_conntrack_tcp_timeout_time_wait        2 min's
>
> And it strikes me that these appear to be considerably long given the
> present day state of connectivity and general speed of connections.
> Especially, the 5 day timeout on an established connection. Isn't that just
> a recipe for leaving a no longer wanted connection open well beyond it's
> desirable lifespan?
>
> Can anyone offer up some form of opinion as to why I shouldn't reduce these
> values a bit (especially the established timeout) pls?
>
> For example;
>
> ip_conntrack_tcp_timeout_established       1 day
> ip_conntrack_tcp_timeout_fin_wait           2 min's  (might leave this or
> possible to end up with unnecessary "established" conn's. waiting for
> timeout)
> ip_conntrack_tcp_timeout_max_retrans    300      (Can see why this might be
> set high, but question it's genuine necessity)
> ip_conntrack_tcp_timeout_syn_sent         1 min
> ip_conntrack_tcp_timeout_time_wait        1 min
>
> Am I about to completely screw things up by doing this?
>
> --
> 
> Kind Regards
>
> Kyle
>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables & netfilter TCP timeouts

[Kyle]

I've been investigating some delays in my net connection recently and 
have become aware of the std tcp timeouts set in sysctl by netfilter's 
conntrack module.


Namely;
   
ip_conntrack_tcp_timeout_established   5 days

ip_conntrack_tcp_timeout_fin_wait   2 min's
ip_conntrack_tcp_timeout_max_retrans300
ip_conntrack_tcp_timeout_syn_sent 2 min's
ip_conntrack_tcp_timeout_time_wait2 min's

And it strikes me that these appear to be considerably long given the 
present day state of connectivity and general speed of connections. 
Especially, the 5 day timeout on an established connection. Isn't that 
just a recipe for leaving a no longer wanted connection open well beyond 
it's desirable lifespan?


Can anyone offer up some form of opinion as to why I shouldn't reduce 
these values a bit (especially the established timeout) pls?


For example;

ip_conntrack_tcp_timeout_established   1 day
ip_conntrack_tcp_timeout_fin_wait   2 min's  (might leave this 
or possible to end up with unnecessary "established" conn's. waiting for 
timeout)
ip_conntrack_tcp_timeout_max_retrans300  (Can see why this might 
be set high, but question it's genuine necessity)

ip_conntrack_tcp_timeout_syn_sent 1 min
ip_conntrack_tcp_timeout_time_wait1 min

Am I about to completely screw things up by doing this?

--

Kind Regards

Kyle

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables / Bridged

[Grant Parnell]

Andrew Hendrik Bootsma wrote:
> Hi Guys;
>
> I recently setup a server with a main ip of x.x.x.x and a subnet which I
> have bridged to an internal qtap0 adapter.
> My current iptables setup however blocks all traffic of the subnet, and
> when I allow the subnet;
> iptables -I FORWARD -s 213.133.127.0/29 -j ACCEPT
> iptables -I INPUT -s 213.133.127.0/29 -j ACCEPT
> It still continues to block all traffic to it; any ideas? I am fairly
> newbish with iptables.
>
> Andrew Bootsma
>
>   
So I think you're saying you've got a virtual machine on qtap0 inside a
physical machine with for argument's sake eth0 as it's physical
interface. Is this what you're saying? Or is qtap0 something like an
ethernet going to some other internal LAN? Doesn't matter greatly for
this discussion.

[LAN/WAN/Internet?]
 |
 |
[[eth0 x.x.x.x]
[ |
[ |
[[qtap0] 213.133.127.y]
[
[physical machine]


Firstly... `cat /proc/sys/net/ipv4/ip_forward` should result in '1'
being displayed. If not you need to adjust your /etc/sysctl.conf and
then reload it with `sysctl -p`. This is the master switch that says
your host is actually a router as well.

Secondly, and I suppose you've already done this, check that you can
ping the virtual from the host and that you can ping the host from the
virtual. If not, get that working first.

Next if the outside world has an appropriate route to your subnet (it
appears to) that's great. If not you'll have to NAT it's traffic coming
out of eth0 with something like `iptables -t nat -A POSTROUTING -s
213.133.127.0/29 -j MASQUERADE` which will translate everything to your
x.x.x.x address somewhat defeat the purpose of the /29 net but it'll work.

Next failing that you'll have to supply more information like what
x.x.x.x is, your routing table, your iptables setup. `iptables -t filter
-L -n -v` and `iptables -t nat -L -n -v` and some examples of the output
of tcpdump on eth0 and qtap0 concurrently. EG `tcpdump -n -i eth0 icmp`
in one terminal and `tcpdump -n -i qtap0 icmp` in another terminal. Then
pings from your virtual machine to a known IP address (avoiding DNS lookup).

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Iptables / Bridged

[Andrew Hendrik Bootsma]

Hi Guys;

I recently setup a server with a main ip of x.x.x.x and a subnet which I
have bridged to an internal qtap0 adapter.
My current iptables setup however blocks all traffic of the subnet, and
when I allow the subnet;
iptables -I FORWARD -s 213.133.127.0/29 -j ACCEPT
iptables -I INPUT -s 213.133.127.0/29 -j ACCEPT
It still continues to block all traffic to it; any ideas? I am fairly
newbish with iptables.

Andrew Bootsma

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Kyle]

Rick,

it dawned on at 04:30 this morning (don't ask) that you probably want to 
tighten this up even more (and simplify it too) by doing the following;


iptables -A INPUT -i ethX  -s  -m multiport -p tcp 
--dport www,ssh -j ACCEPT

iptables -A INPUT -j DROP
iptables -A OUTPUT -o ethX -d  -j ACCEPT
iptables -A OUTPUT -j DROP

Just be aware that the two drop statements now prevent host A talking to 
any machine other than host B and only over ethX.  So if ethX ever 
fails, you're screwed. And if you don't want host A initiating calls, 
change line 3 above back to include '-m state --state RELATED,ESTABLISHED'



Kind Regards

Kyle



r...@greyheads.net wrote:

Kyle apologies for the top posting - mail2web is a bit dumb as this.

Do you mean that the script should look like this

iptables -A INPUT -m state --state NEW -m multiport -p tcp --dport 
www,ssh -i ethX -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -o ethX -m state --state RELATED,ESTABLISHED -j 
ACCEPT

iptables -A OUTPUT -o ethX -j DROP

Can you have two -m statements on the one line?

Regards,

Rick





--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Kyle]

Rick,

I do. I don't know whether it makes any difference or not your using the 
multiport keyword (I would imagine not), but I use three '-m' statements 
on one line as in;


-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m limit --limit 2/minute 
--limit-burst 2 -m state --state NEW -j ACCEPT


Without wishing to join the debate others have initiated about DNS & 
NTP, etc., but I would suggest that if you are going to open 22 up to 
the big bad world, I would at least rate limit the connection[1] so as 
to avoid DOS, dictionary attacks and the like.


Likewise, as mentioned previously by someone else, a very limited ping 
enables connectivity checking.


-A INPUT -i eth0 -p icmp --icmp-type any -m state --state NEW -j REJECT 
--reject-with icmp-host-prohibited


Finally, the second rule will still presently allow established 
connections from ethY, ethZ, ethA, ethB, ethC (you get the picture) IF 
they exist on the host.


[1] Depending upon your needs.


Kind Regards

Kyle



r...@greyheads.net wrote:

Kyle apologies for the top posting - mail2web is a bit dumb as this.

Do you mean that the script should look like this

iptables -A INPUT -m state --state NEW -m multiport -p tcp --dport www,ssh -i 
ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -o ethX -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

Can you have two -m statements on the one line?

Regards,

Rick




No guarantees, as I'd have to think about it a bit more, but

I would think you might want to add '-m state --state NEW' to the first 
rule otherwise the 2nd rule is irrelevant.


The 2nd rule will presently allow ALL established connections from 
anywhere that managed to get in to the machine (from other interfaces as 
well)


If you want B to talk to A ONLY, add a  '-o ethX' to the 3rd rule.

Then you also need a 'iptables -A INPUT -j DROP' (depending line above, 
add a '-i ethX' to this)



I think...



Kind Regards

Kyle



Rick Phillips wrote:
  

I am not very good at IPTables and was seeking opinions as to whether
this formula would work to fully block a connection from computer A to B
but allow ssh and web only from B to A.  The tables would reside on A.

iptables -A INPUT -m multiport -p tcp --dport www,ssh -i ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

The network is off site and quite a distance away with no external admin
so I would like to have it "right" before I visit.

Thanks in advance.

Rick

  


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Dean Hamstead]

also, not syncing the clock makes date stamps in logs almost entirely
unreliable.


Also very true unless maybe his sever is a virtual one on top of a
platform which provides an accurate clock.


Or an external clock, perhaps GPS or some other solution for time sync.

Dean
--
http://fragfest.com.au
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Amos Shapira]

2009/11/11 Dean Hamstead :
> sshd for example, will stall for quite an annoying amount of time trying to
> do a reverse lookup. unless you dont actually have name servers configured
> at all.

Correct. Though specifically with sshd you can turn off reverse-dns
lookup with "UseDNS no" in /etc/ssh/sshd_config.

He should probably sniff his own traffic and see what needs to be
allowed through or turned off.

> also, not syncing the clock makes date stamps in logs almost entirely
> unreliable.

Also very true unless maybe his sever is a virtual one on top of a
platform which provides an accurate clock.

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Sonia Hamilton]

On Tue, 10 Nov 2009 18:06:50 +1000, "Rick Phillips" 
said:
> I am not very good at IPTables and was seeking opinions as to whether
> this formula would work to fully block a connection from computer A to B
> but allow ssh and web only from B to A.  The tables would reside on A.

In addition to rate limiting, dns, ntp (which others have mentioned),
you should also consider protecting against route spoofing and RFC1918
addresses (192.168, etc).

You can write all the iptables rules yourselves, or better use something
like Shorewall http://www.shorewall.net/

Sonia.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[r...@greyheads.net]

Kyle apologies for the top posting - mail2web is a bit dumb as this.

Do you mean that the script should look like this

iptables -A INPUT -m state --state NEW -m multiport -p tcp --dport www,ssh
-i ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j DROP
iptables -A OUTPUT -o ethX -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

Can you have two -m statements on the one line?

Regards,

Rick




No guarantees, as I'd have to think about it a bit more, but

I would think you might want to add '-m state --state NEW' to the first 
rule otherwise the 2nd rule is irrelevant.

The 2nd rule will presently allow ALL established connections from 
anywhere that managed to get in to the machine (from other interfaces as 
well)

If you want B to talk to A ONLY, add a  '-o ethX' to the 3rd rule.

Then you also need a 'iptables -A INPUT -j DROP' (depending line above, 
add a '-i ethX' to this)


I think...



Kind Regards

Kyle



Rick Phillips wrote:
> I am not very good at IPTables and was seeking opinions as to whether
> this formula would work to fully block a connection from computer A to B
> but allow ssh and web only from B to A.  The tables would reside on A.
>
> iptables -A INPUT -m multiport -p tcp --dport www,ssh -i ethX -j ACCEPT
> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A OUTPUT -o ethX -j DROP
>
> The network is off site and quite a distance away with no external admin
> so I would like to have it "right" before I visit.
>
> Thanks in advance.
>
> Rick
>
>   
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html



mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Nicholas Jefferson]

You can also allow ping requests and limit the rate and packet size, 
which gives you the niceties of being able to determine some level of 
connectivity, whilst reducing scope for abuse.


You can rate limit by source IP address with the "recent" module. For 
example the following rules limit new SSH connections to 20 per minute 
from the same IP address:


iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m recent --name ssh --rcheck --hitcount 20 --seconds 
60 -j DROP

iptables -A INPUT -p tcp --dport ssh -m recent --name ssh --set -j ACCEPT

Thanks,

Nicholas
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Dean Hamstead]

Even though dns may not be 'turned on', almost everything tcpip related
wants dns look ups.

sshd for example, will stall for quite an annoying amount of time trying 
to do a reverse lookup. unless you dont actually have name servers 
configured at all.


also, not syncing the clock makes date stamps in logs almost entirely 
unreliable.



Dean

Rick Phillips wrote:

HI Dean

You most likely want to allow outbound dns and the subsequent reply

Keep in mind that blocking outbound usually requires a few more 
allowances than just the basic service you plan the box to provide.


NTP also springs to mind, so that you can keep the clock in sync.

You can also allow ping requests and limit the rate and packet size, 
which gives you the niceties of being able to determine some level of 
connectivity, whilst reducing scope for abuse.


Thanks for the comments but none of the services you mention are used or
even turned on.  It's an unusual situation I know.

Regards,

Rick


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Kyle]

No guarantees, as I'd have to think about it a bit more, but

I would think you might want to add '-m state --state NEW' to the first 
rule otherwise the 2nd rule is irrelevant.


The 2nd rule will presently allow ALL established connections from 
anywhere that managed to get in to the machine (from other interfaces as 
well)


If you want B to talk to A ONLY, add a  '-o ethX' to the 3rd rule.

Then you also need a 'iptables -A INPUT -j DROP' (depending line above, 
add a '-i ethX' to this)



I think...



Kind Regards

Kyle



Rick Phillips wrote:

I am not very good at IPTables and was seeking opinions as to whether
this formula would work to fully block a connection from computer A to B
but allow ssh and web only from B to A.  The tables would reside on A.

iptables -A INPUT -m multiport -p tcp --dport www,ssh -i ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

The network is off site and quite a distance away with no external admin
so I would like to have it "right" before I visit.

Thanks in advance.

Rick

  

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Rick Phillips]

HI Dean
> You most likely want to allow outbound dns and the subsequent reply
> 
> Keep in mind that blocking outbound usually requires a few more 
> allowances than just the basic service you plan the box to provide.
> 
> NTP also springs to mind, so that you can keep the clock in sync.
> 
> You can also allow ping requests and limit the rate and packet size, 
> which gives you the niceties of being able to determine some level of 
> connectivity, whilst reducing scope for abuse.

Thanks for the comments but none of the services you mention are used or
even turned on.  It's an unusual situation I know.

Regards,

Rick

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTables

[Dean Hamstead]

You most likely want to allow outbound dns and the subsequent reply

Keep in mind that blocking outbound usually requires a few more 
allowances than just the basic service you plan the box to provide.


NTP also springs to mind, so that you can keep the clock in sync.

You can also allow ping requests and limit the rate and packet size, 
which gives you the niceties of being able to determine some level of 
connectivity, whilst reducing scope for abuse.


Dean

Rick Phillips wrote:

I am not very good at IPTables and was seeking opinions as to whether
this formula would work to fully block a connection from computer A to B
but allow ssh and web only from B to A.  The tables would reside on A.

iptables -A INPUT -m multiport -p tcp --dport www,ssh -i ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

The network is off site and quite a distance away with no external admin
so I would like to have it "right" before I visit.

Thanks in advance.

Rick


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] IPTables

[Rick Phillips]

I am not very good at IPTables and was seeking opinions as to whether
this formula would work to fully block a connection from computer A to B
but allow ssh and web only from B to A.  The tables would reside on A.

iptables -A INPUT -m multiport -p tcp --dport www,ssh -i ethX -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o ethX -j DROP

The network is off site and quite a distance away with no external admin
so I would like to have it "right" before I visit.

Thanks in advance.

Rick

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: [SLUG] iptables DNAT broadcast packets

[Troy Rollo]

Set up an ethernet tunnel interface (not an IP tunnel!) between the two
systems and bridge the physical interface to the tunneled interface. The
remote end will need an IP address on the local network. 

Trying to NAT a broadcast address seems to me to be asking for trouble.

Note that by doing this the remote host will end up seeing all your
broadcast traffic (including ARP, WINS, and other atrocities).

Regards, 
Troy Rollo 
Solicitor 
Parry Carroll 
Commercial Lawyers 
Direct:   (02) 8257 3177 
Fax:  (02) 9221 1375 
Switch:  (02) 9221 3899 
E-mail:   t...@parrycarroll.com.au 
Web:  www.parrycarroll.com.au   

Liability limited by a scheme approved under Professional Standards
Legislation 

This message and any attachments are confidential to Parry Carroll. If you
have received it my mistake, please let us know by reply and then delete it
from your system. You must not copy the message, alter it or disclose its
contents to anyone. Thank you.



smime.p7s
Description: S/MIME cryptographic signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables DNAT broadcast packets

[Jake Anderson]

On 14/08/09 12:04, Tony Sceats wrote:

Hi Sluggers,

I have a strange requirement to redirect UDP packets sent to
255.255.255.255, forwarding them to another machine in a remote network...
yes, this is borked - there is an application sending data to
255.255.255.255, not multicast or unicast, but broadcasting UPD packets, and
I'm in no position to change or question this strangeness..

Anyway, so this should be quite simple - run a DNAT rule changing the
destination address in the pre-routing chain of the nat table

ie

iptables -t nat -I PREROUTING -d 255.255.255.255 -j DNAT --to-dest
192.168.x.y

however this doesn't work.. it doesn't even work if I specify the source of
the broadcasts rather than the destination, eg

iptables -t nat -I PREROUTING -s 192.168.y.z -j DNAT --to-dest 192.168.x.y

and specifying input and output interfaces doesn't help either

I have ip_forwarding enabled, and if I change this rule to be from my
workstation, then I can see that it works - ie

iptables -t nat -I PREROUTING -s my.ip.add.ress -j DNAT --to-dest
192.168.x.y

and then ping the host with the iptables rules, I can see with tcpdump that
my pings go back out and onto the remote network.. so, I know iptables is
working, and I know forwarding is working, I just can't make a rule that
effects packets sent to 255.255.255.255

Has anyone got any clues as to why broadcasts aren't being matched and
DNAT'd?

Thanks
   

No clue as to that but potentially another way to solve the problem.
You could try using netcat as a proxy for the traffic.
perhaps something along these lines?
http://zarb.org/~gc/html/udp-in-ssh-tunneling.html

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables DNAT broadcast packets

[Tony Sceats]

Hi Sluggers,

I have a strange requirement to redirect UDP packets sent to
255.255.255.255, forwarding them to another machine in a remote network...
yes, this is borked - there is an application sending data to
255.255.255.255, not multicast or unicast, but broadcasting UPD packets, and
I'm in no position to change or question this strangeness..

Anyway, so this should be quite simple - run a DNAT rule changing the
destination address in the pre-routing chain of the nat table

ie

iptables -t nat -I PREROUTING -d 255.255.255.255 -j DNAT --to-dest
192.168.x.y

however this doesn't work.. it doesn't even work if I specify the source of
the broadcasts rather than the destination, eg

iptables -t nat -I PREROUTING -s 192.168.y.z -j DNAT --to-dest 192.168.x.y

and specifying input and output interfaces doesn't help either

I have ip_forwarding enabled, and if I change this rule to be from my
workstation, then I can see that it works - ie

iptables -t nat -I PREROUTING -s my.ip.add.ress -j DNAT --to-dest
192.168.x.y

and then ping the host with the iptables rules, I can see with tcpdump that
my pings go back out and onto the remote network.. so, I know iptables is
working, and I know forwarding is working, I just can't make a rule that
effects packets sent to 255.255.255.255

Has anyone got any clues as to why broadcasts aren't being matched and
DNAT'd?

Thanks
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables error msg

[Rodolfo Martínez]

Hi Adam,

You are using an undefined variable on the lines below

-
## FROM INTRANET ##
$IPTABLES -A INPUT -p ALL -i $INTERNAL_DEVICE -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $INTERNAL_DEVICE -j ACCEPT
-

INTERNAL_DEVICE variable is not defined, it is commented at the
beginning of the script

#INTERNAL_DEVICE="eth1" # device for Intranet


Rodolfo Martínez



On Thu, Jul 23, 2009 at 6:32 AM, Adam Bogacki wrote:
> Hi, I keep getting
>
>> Setting up IPtables rules
>> Using intrapositioned negation (`--option ! this`) is deprecated in favor
>> of extrapositioned (`! --option this`).
>> Bad argument `ACCEPT'
>> Try `iptables -h' or 'iptables --help' for more information.
>> Bad argument `ACCEPT'
>> Try `iptables -h' or 'iptables --help' for more information.
>
> .. but 'ACCEPT' appears in many places in iptables.
>
> What would it be referring to ?
>
> I have attached my version of iptables (courtesy of Ekiga).
>
> Adam.
>
>> #!/bin/sh
>> echo "Setting up IPtables rules"
>> IPTABLES=/sbin/iptables # where iptables binary lies
>> # Setting up Forwarding
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> # Setting up Dynamic IP for diald/masquerading
>> echo 1 > /proc/sys/net/ipv4/ip_dynaddr
>> # Increase the binding time
>> echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
>> # Setting up IP spoofing protection
>> if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
>> then
>>        for f in /proc/sys/net/ipv4/conf/*/rp_filter
>>        do
>>                echo 1 > $f
>>        done
>> fi
>> # Devices
>> LOCAL_DEVICE="lo" # device for localhost
>> EXTERNAL_DEVICE="eth0" # device for Internet
>> #INTERNAL_DEVICE="eth1" # device for Intranet
>> HALFTRUST_NETS="192.168.1.0/8"
>> KEEPSTATE="-m state --state ESTABLISHED,RELATED"
>> # Flush all Rules
>> $IPTABLES -F
>> $IPTABLES -X
>> $IPTABLES -t nat -F
>> $IPTABLES -t nat -X
>> $IPTABLES -t mangle -F
>> $IPTABLES -t mangle -X
>> # Deny all by default
>> $IPTABLES -P INPUT DROP
>> $IPTABLES -P OUTPUT DROP
>> $IPTABLES -P FORWARD ACCEPT
>> $IPTABLES -N ALLOW_PORTS
>> $IPTABLES -F ALLOW_PORTS
>> ## TCP and UDP ports ##
>> TCP_PORTS=""
>> for PORT in $TCP_PORTS; do
>> $IPTABLES -A ALLOW_PORTS -m state --state NEW -p tcp --dport $PORT -j
>> ACCEPT
>> done
>> UDP_PORTS=""
>> for PORT in $UDP_PORTS; do
>> $IPTABLES -A ALLOW_PORTS -m state --state NEW -p udp --dport $PORT -j
>> ACCEPT
>> done
>> ## MASQUERADE ##
>> $IPTABLES -t nat -A POSTROUTING -d ! 192.168.1.0/24 -o $EXTERNAL_DEVICE -j
>> MASQUERADE
>> ## LOCALHOST ##
>> $IPTABLES -A INPUT -p ALL -i $LOCAL_DEVICE -j ACCEPT
>> $IPTABLES -A OUTPUT -p ALL -o $LOCAL_DEVICE -j ACCEPT
>> $IPTABLES -A FORWARD -p ALL -i $LOCAL_DEVICE -j ACCEPT
>> ## FROM INTRANET ##
>> $IPTABLES -A INPUT -p ALL -i $INTERNAL_DEVICE -j ACCEPT
>> $IPTABLES -A OUTPUT -p ALL -o $INTERNAL_DEVICE -j ACCEPT
>> ## ICMP ##
>> $IPTABLES -A INPUT -p ICMP -i $EXTERNAL_DEVICE -j ACCEPT
>> $IPTABLES -A OUTPUT -p ICMP -o $EXTERNAL_DEVICE -j ACCEPT
>> $IPTABLES -A INPUT -p ICMP -s $HALFTRUST_NETS -j ACCEPT
>> $IPTABLES -A OUTPUT -p ICMP -d $HALFTRUST_NETS -j ACCEPT
>> ## ALLOWED PORTS ##
>> $IPTABLES -A INPUT -i $EXTERNAL_DEVICE -s "0.0.0.0/0" -j ALLOW_PORTS
>> ## ESTABLISHED MODE ##
>> $IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p TCP $KEEPSTATE -j ACCEPT
>> $IPTABLES -A INPUT -i $EXTERNAL_DEVICE -p TCP $KEEPSTATE -j ACCEPT
>> $IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p UDP $KEEPSTATE -j ACCEPT
>> $IPTABLES -A INPUT -i $EXTERNAL_DEVICE -p UDP $KEEPSTATE -j ACCEPT
>> ## OUTPUT ##
>> $IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p ALL -j ACCEPT
>
>
>
>
>
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
>
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables error msg

[Daniel Pittman]

Adam Bogacki  writes:

>> Setting up IPtables rules Using intrapositioned negation (`--option !
>> this`) is deprecated in favor of extrapositioned (`! --option this`).  Bad
>> argument `ACCEPT' Try `iptables -h' or 'iptables --help' for more
>> information.  Bad argument `ACCEPT' Try `iptables -h' or 'iptables --help'
>> for more information.
>
> .. but 'ACCEPT' appears in many places in iptables.
> What would it be referring to ?
> I have attached my version of iptables (courtesy of Ekiga).

Nothing obvious leaps out; perhaps you can find out by running:

sh -x /path/to/script 2>&1

That should show you the commands before they are run, along with the error
messages, and let you identify which command it was generated the error.

Regards,
Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables error msg

[Adam Bogacki]

Hi, I keep getting


Setting up IPtables rules
Using intrapositioned negation (`--option ! this`) is deprecated in 
favor of extrapositioned (`! --option this`).

Bad argument `ACCEPT'
Try `iptables -h' or 'iptables --help' for more information.
Bad argument `ACCEPT'
Try `iptables -h' or 'iptables --help' for more information.


.. but 'ACCEPT' appears in many places in iptables.

What would it be referring to ?

I have attached my version of iptables (courtesy of Ekiga).

Adam.


#!/bin/sh
echo "Setting up IPtables rules"
IPTABLES=/sbin/iptables # where iptables binary lies
# Setting up Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Setting up Dynamic IP for diald/masquerading
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
# Increase the binding time
echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
# Setting up IP spoofing protection
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for f in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $f
done
fi
# Devices
LOCAL_DEVICE="lo" # device for localhost
EXTERNAL_DEVICE="eth0" # device for Internet
#INTERNAL_DEVICE="eth1" # device for Intranet
HALFTRUST_NETS="192.168.1.0/8"
KEEPSTATE="-m state --state ESTABLISHED,RELATED"
# Flush all Rules
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t mangle -F
$IPTABLES -t mangle -X
# Deny all by default
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -N ALLOW_PORTS
$IPTABLES -F ALLOW_PORTS
## TCP and UDP ports ##
TCP_PORTS=""
for PORT in $TCP_PORTS; do
$IPTABLES -A ALLOW_PORTS -m state --state NEW -p tcp --dport $PORT -j 
ACCEPT

done
UDP_PORTS=""
for PORT in $UDP_PORTS; do
$IPTABLES -A ALLOW_PORTS -m state --state NEW -p udp --dport $PORT -j 
ACCEPT

done
## MASQUERADE ##
$IPTABLES -t nat -A POSTROUTING -d ! 192.168.1.0/24 -o 
$EXTERNAL_DEVICE -j MASQUERADE

## LOCALHOST ##
$IPTABLES -A INPUT -p ALL -i $LOCAL_DEVICE -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $LOCAL_DEVICE -j ACCEPT
$IPTABLES -A FORWARD -p ALL -i $LOCAL_DEVICE -j ACCEPT
## FROM INTRANET ##
$IPTABLES -A INPUT -p ALL -i $INTERNAL_DEVICE -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -o $INTERNAL_DEVICE -j ACCEPT
## ICMP ##
$IPTABLES -A INPUT -p ICMP -i $EXTERNAL_DEVICE -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP -o $EXTERNAL_DEVICE -j ACCEPT
$IPTABLES -A INPUT -p ICMP -s $HALFTRUST_NETS -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP -d $HALFTRUST_NETS -j ACCEPT
## ALLOWED PORTS ##
$IPTABLES -A INPUT -i $EXTERNAL_DEVICE -s "0.0.0.0/0" -j ALLOW_PORTS
## ESTABLISHED MODE ##
$IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p TCP $KEEPSTATE -j ACCEPT
$IPTABLES -A INPUT -i $EXTERNAL_DEVICE -p TCP $KEEPSTATE -j ACCEPT
$IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p UDP $KEEPSTATE -j ACCEPT
$IPTABLES -A INPUT -i $EXTERNAL_DEVICE -p UDP $KEEPSTATE -j ACCEPT
## OUTPUT ##
$IPTABLES -A OUTPUT -o $EXTERNAL_DEVICE -p ALL -j ACCEPT






--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables defualt policy

[Amos Shapira]

On 10/09/2007, Alex Samad <[EMAIL PROTECTED]> wrote:
>
> iptables -P INPUT REJECT
> iptables: Bad policy name


This complies with what I understand from the man page of iptables
1.3.6(Debian Etch):

-P, --policy chain target
Set  the policy for the chain to the given target.  See the section TARGETS
for the legal targets...neither built-in nor user-defined chains can be
policy targets.

TARGETS
...one of the special values ACCEPT, DROP, QUEUE, or RETURN.

I haven't analysed this too much but I suspect that this limitation was put
to prevent rule loops.

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables defualt policy

[Amos Shapira]

On 10/09/2007, Mark Chandler <[EMAIL PROTECTED]> wrote:
>
> Odd. My recollection was also that REJECT could be used in a policy.
> However, it seems clear from the man pages and searching around that
> ACCEPT, DROP, QUEUE, and RETURN are the only options. There are extended
> targets that include REJECT, but as you mentioned above, that only seems
> available for user chains.


Maybe REJECT's implementation was moved from being an internal special
target to a yet-another module, there is a REJECT module now
(/lib/iptables/libipt_REJECT.so) and it is listed under "TARGET EXTENSIONS".

--Amos
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables defualt policy

[Mark Chandler]

Alex Samad wrote:

On Mon, Sep 10, 2007 at 02:42:48PM +1000, Jamie Wilkinson wrote:
  

This one time, at band camp, Alex Samad wrote:


Hi

I am just going through my firewall setup and I notice I can no longer do  
iptables -P INPUT REJECT


when did this happen ? I could have sworn that is what I used to use as a 
default, yes I know I can drop and add a -A -j REJECT
  

News to me.  What version of iptables do you have?


amd64 lenny
iptables -V
iptables v1.3.8
uname -r
2.6.20-1-amd64

 iptables -P INPUT REJECT
iptables: Bad policy name

but I can do a iptables -A INPUT -j REJECT

strange


  

What's the error message?
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Odd. My recollection was also that REJECT could be used in a policy. 
However, it seems clear from the man pages and searching around that 
ACCEPT, DROP, QUEUE, and RETURN are the only options. There are extended 
targets that include REJECT, but as you mentioned above, that only seems 
available for user chains.

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables defualt policy

[Alex Samad]

On Mon, Sep 10, 2007 at 02:42:48PM +1000, Jamie Wilkinson wrote:
> This one time, at band camp, Alex Samad wrote:
> >Hi
> >
> >I am just going through my firewall setup and I notice I can no longer do  
> >iptables -P INPUT REJECT
> >
> >when did this happen ? I could have sworn that is what I used to use as a 
> >default, yes I know I can drop and add a -A -j REJECT
> 
> News to me.  What version of iptables do you have?
amd64 lenny
iptables -V
iptables v1.3.8
uname -r
2.6.20-1-amd64

 iptables -P INPUT REJECT
iptables: Bad policy name

but I can do a iptables -A INPUT -j REJECT

strange


> 
> What's the error message?
> -- 
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables defualt policy

[Jamie Wilkinson]

This one time, at band camp, Alex Samad wrote:
>Hi
>
>I am just going through my firewall setup and I notice I can no longer do  
>iptables -P INPUT REJECT
>
>when did this happen ? I could have sworn that is what I used to use as a 
>default, yes I know I can drop and add a -A -j REJECT

News to me.  What version of iptables do you have?

What's the error message?
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables defualt policy

[Alex Samad]

Hi

I am just going through my firewall setup and I notice I can no longer do  
iptables -P INPUT REJECT

when did this happen ? I could have sworn that is what I used to use as a 
default, yes I know I can drop and add a -A -j REJECT

Alex 


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPTABLES rule change to allow interface with AD

[Phil Scarratt]

[EMAIL PROTECTED] wrote:

We have a server running in a DMZ servicing intranet and extranet.

In the past we have blocked all traffic originating on the server from the
two internal networks we run (eth1 and eth2) but have accepted traffic
coming from the networks outside of the server.  Eth0 is the direct
connection to the internet and a solid state firewall looks after port
redirection to eth0.  No traffic is blocked on eth0 so that we can apply
patches and updates to the server (Mandriva 2007).  The tables below have
done the job.

We now need to allow access to port 389 (Active Director) only, from the
DMZ server to an AD server on eth2.  I am no good at this and was wondering
if someone could suggest the change/changes to the rules below to allow
this to happen.
|---|
eth2-->-|   |---eth0 <--> Internet
eth1-->-|   |
|---|
iptables -A INPUT -m state --state NEW -i eth2 -j ACCEPT
iptables -A INPUT -m state --state NEW -i eth1 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth2 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth2 -j DROP
iptables -A OUTPUT -o eth1 -j DROP



This was not the question but it seems to me that the first 2 rules and 
rules 4 and 5 are duplicates in that rules 4 and 5 would accept anything 
the first 2 do. Rules 4 and 5 basically allow any packet coming in on 
eth1 and eth2 regardless of source/port/protocol/state.


I am making a lot of assumptions about the rest of the rules and default 
policies and other things but something like


iptables -A OUTPUT -o eth2 -d ip.address.of.adserver -p !icmp --dport 
ldap -j ACCEPT


placed before the second last line above (the "...-o eth2 -j DROP" line) 
should do it. In plain english this says


Allow any packet going out on interface eth2 whose destination (-d) is 
ip.address.of.adserver and whose protocol (-p) is not icmp (!icmp) and 
whose destination port (--dport) is that of the ldap entry in /etc/services.


To be safe you could put 389 instead of ldap after --port. There may be 
other ports you may need to let through such as 135 (MS-RPC) depending 
on your purpose/configuration. I also know very little about AD.


Fil
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] IPTABLES rule change to allow interface with AD

[[EMAIL PROTECTED]]

We have a server running in a DMZ servicing intranet and extranet.

In the past we have blocked all traffic originating on the server from the
two internal networks we run (eth1 and eth2) but have accepted traffic
coming from the networks outside of the server.  Eth0 is the direct
connection to the internet and a solid state firewall looks after port
redirection to eth0.  No traffic is blocked on eth0 so that we can apply
patches and updates to the server (Mandriva 2007).  The tables below have
done the job.

We now need to allow access to port 389 (Active Director) only, from the
DMZ server to an AD server on eth2.  I am no good at this and was wondering
if someone could suggest the change/changes to the rules below to allow
this to happen.
|---|
eth2-->-|   |---eth0 <--> Internet
eth1-->-|   |
|---|
iptables -A INPUT -m state --state NEW -i eth2 -j ACCEPT
iptables -A INPUT -m state --state NEW -i eth1 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth2 -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth2 -j DROP
iptables -A OUTPUT -o eth1 -j DROP

Many thanks in advance.

Rick Phillips


mail2web - Check your email from the web at
http://mail2web.com/ .


--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables

[jam]

On Wednesday 22 February 2006 02:39, [EMAIL PROTECTED] wrote:
> > Hi sluggers,
> >
> > Im quite ashamed to say it, but for a couple of years now all my
> > firewalling and routing has been done using either webmin or
> > firestarter. I have no idea how to  use iptables! I find I just dont
> > feel totally in control when using gui front end and have now decided to
> > learn how to use iptables. My question is, can anyone point me to  
> > either a good online tutorial, or a book that will show me step by step
> > what to do and why?
> > I use debian stable for my server, and the tutorials that I have found
> > (I have never been good with google) usually give redhat examples
> > including config files that dont exist in debian (or are in a different
> > location).
>
> Don't use iptables. Use shorewall. You will still understand
> firewalling, but don't need to worry about the iptables syntax biting
> you. also you get dual net connections in a nicely integrated script

Interesting perspective: Not only did yast make the whole process easy and 
understandable but when I needed 3 interfaces (one for openVPN) that too was 
sensibly and understandably handled.
Reinforces my resolution that yast is one of the best sys-admin tools around.

James
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables

[David Kempe]

tuxta2 wrote:

Hi sluggers,

Im quite ashamed to say it, but for a couple of years now all my 
firewalling and routing has been done using either webmin or 
firestarter. I have no idea how to  use iptables! I find I just dont 
feel totally in control when using gui front end and have now decided to 
learn how to use iptables. My question is, can anyone point me to  
either a good online tutorial, or a book that will show me step by step 
what to do and why?
I use debian stable for my server, and the tutorials that I have found 
(I have never been good with google) usually give redhat examples 
including config files that dont exist in debian (or are in a different 
location).


Don't use iptables. Use shorewall. You will still understand 
firewalling, but don't need to worry about the iptables syntax biting 
you. also you get dual net connections in a nicely integrated script


dave
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Iptables

[tuxta2]

Hi sluggers,

Im quite ashamed to say it, but for a couple of years now all my 
firewalling and routing has been done using either webmin or 
firestarter. I have no idea how to  use iptables! I find I just dont 
feel totally in control when using gui front end and have now decided to 
learn how to use iptables. My question is, can anyone point me to  
either a good online tutorial, or a book that will show me step by step 
what to do and why?
I use debian stable for my server, and the tutorials that I have found 
(I have never been good with google) usually give redhat examples 
including config files that dont exist in debian (or are in a different 
location).


Any help would be appreciated.

Tuxta
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables weirdness

[Howard Lowndes]

Grant Parnell wrote:
On Tue, 5 Apr 2005, Howard Lowndes wrote:

I've just upgraded a box (hardware & software) from RH 7.1 with an early 
2.4.x kernel to FC3 with the latest 2.6.x kernel, but most of the config 
files I have brought over from the old box including the iptables rules 
sets, and it's these that are giving me grief.

The box acts as a gateway filter/router/NAT box.
Specifically the problem relates to a workstation behind the firewall 
trying to establish a tcp connection out onto the I'net.

The relevant iptable is one that ACCEPTs all TCP packets that are state 
ESTABLISHED,RELATED.  Something like:
iptables -A chain_name -p TCP -m state --state ESTABLISHED,RELATED \
-j ACCEPT

Shouldn't this be
iptables -A chain_name -m state --state ESTABLISHED,RELATED \
-j ACCEPT
Ie no mention of '-p TCP' (which should be '-p tcp' anyway - ie lower 
case). I guess ESTABLISHED pretty much only applies to TCP but I could be 
wrong (GRE?)
The protocol name is not case sensitive, unlike the chain name and the 
target name.

in or out, -p tcp makes no difference.
I know it works because it has worked in the old box for years, and is 
now continuing to work in the old box which is back on line whilst I try 
to fathom out the new box.  The rule sets were an scp copy from one box 
to the other, so I guess the problem has to be something to do with 
either the new kernel or the updates iptables program and the way it or 
both handle established connections.


--
Howard.
LANNet Computing Associates - Your Linux people 
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
begin:vcard
fn:Howard Lowndes
n:Lowndes;Howard
org:LANNet Computing Associates
adr:;;PO Box 1174;Lavington;NSW;2641;Australia
email;internet:howard [AT] lowndes [DOT] name
tel;work:02 6040 0222
tel;fax:02 6040 0222
tel;cell:0419 464 430
note:I am heartily sick and tired of telemarketers, therefore I do not answer phone calls which do not present Caller Line Identification, they get flicked to voicemail.  I apologise if this inconveniences you, and I respect your right to not identify yourself, but I also ask that you respect my right to not answer your call if you choose not to identify yourself.  Try dialing 1832 (#32# from mobiles) before the number, to present Caller Line Identification.
x-mozilla-html:FALSE
url:http://www.lannet.com.au
version:2.1
end:vcard

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables weirdness

[Grant Parnell]

On Tue, 5 Apr 2005, Howard Lowndes wrote:

> I've just upgraded a box (hardware & software) from RH 7.1 with an early 
> 2.4.x kernel to FC3 with the latest 2.6.x kernel, but most of the config 
> files I have brought over from the old box including the iptables rules 
> sets, and it's these that are giving me grief.
> 
> The box acts as a gateway filter/router/NAT box.
> 
> Specifically the problem relates to a workstation behind the firewall 
> trying to establish a tcp connection out onto the I'net.
> 
> The relevant iptable is one that ACCEPTs all TCP packets that are state 
> ESTABLISHED,RELATED.  Something like:
> iptables -A chain_name -p TCP -m state --state ESTABLISHED,RELATED \
> -j ACCEPT

Shouldn't this be
iptables -A chain_name -m state --state ESTABLISHED,RELATED \
-j ACCEPT
Ie no mention of '-p TCP' (which should be '-p tcp' anyway - ie lower 
case). I guess ESTABLISHED pretty much only applies to TCP but I could be 
wrong (GRE?)

> 
> The SYN packet goes out fine, the SYN ACK packet comes back fine and the 
>   bare ACK packet goes out fine, so the connection gets established.
> 
> When I look in /proc/.../ip_conntrack I can see the connection defined 
> as ESTABLISHED.
> 
> The client next sends out a PSH ACK packet with a data payload and the 
> I'net sends back a bare ACK packet, which gets matched by the iptables rule.
> 
> The I'net then sends a PSH ACK packet with data payload, but this does 
> not get accepted by the iptables rule and consequently drops thru until 
> it gets REJECTed further down.
> 
> Needless to say this push and shove goes on for a few minutes until 
> everything times out.
> 
> Why would an iptable rule that is defined to ACCEPT TCP packets state 
> ESTABLISHED,RELATED do so when there is no data payload, but fail when 
> there is a data payload.
> 
> Is there something in sysctl in the 2.6.x kernel that needs to be set 
> and was not in the 2.4.x kernel.
> 
> 

-- 
--
** ROOM FOR RENT $120pw (neg) near Newington Shops 525/401 buses **
Electronic Hobbyist, Former Arcadia BBS nut, Occasional nudist, 
Linux Guru, SLUG President, AUUG and Linux Australia member, Sydney 
Flashmobber, Tenpin Bowler, BMX rider, Walker, Raver & rave music 
lover, Big kid that refuses to grow up. I'd make a good family pet, 
take me home today!
Some people actually read these things it seems.


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables weirdness

[mlh]

Howard,

I'd have to see the rest of your rules, but here's an excerpt
from my fc3 box for incoming ssh.

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

i.e. you still need the 2nd rule.  Actually I presume you have something like
this, but it's worth mentioning/asking.

Have you tried logging all packets before you reject them?
What protocol are you talking about?


Matt
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables weirdness

[Howard Lowndes]

I've just upgraded a box (hardware & software) from RH 7.1 with an early 
2.4.x kernel to FC3 with the latest 2.6.x kernel, but most of the config 
files I have brought over from the old box including the iptables rules 
sets, and it's these that are giving me grief.

The box acts as a gateway filter/router/NAT box.
Specifically the problem relates to a workstation behind the firewall 
trying to establish a tcp connection out onto the I'net.

The relevant iptable is one that ACCEPTs all TCP packets that are state 
ESTABLISHED,RELATED.  Something like:
iptables -A chain_name -p TCP -m state --state ESTABLISHED,RELATED \
-j ACCEPT

The SYN packet goes out fine, the SYN ACK packet comes back fine and the 
 bare ACK packet goes out fine, so the connection gets established.

When I look in /proc/.../ip_conntrack I can see the connection defined 
as ESTABLISHED.

The client next sends out a PSH ACK packet with a data payload and the 
I'net sends back a bare ACK packet, which gets matched by the iptables rule.

The I'net then sends a PSH ACK packet with data payload, but this does 
not get accepted by the iptables rule and consequently drops thru until 
it gets REJECTed further down.

Needless to say this push and shove goes on for a few minutes until 
everything times out.

Why would an iptable rule that is defined to ACCEPT TCP packets state 
ESTABLISHED,RELATED do so when there is no data payload, but fail when 
there is a data payload.

Is there something in sysctl in the 2.6.x kernel that needs to be set 
and was not in the 2.4.x kernel.

--
Howard.
LANNet Computing Associates - Your Linux people 
--
When you just want a system that works, you choose Linux;
When you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
begin:vcard
fn:Howard Lowndes
n:Lowndes;Howard
org:LANNet Computing Associates
adr:;;PO Box 1174;Lavington;NSW;2641;Australia
email;internet:howard [AT] lowndes [DOT] name
tel;work:02 6040 0222
tel;fax:02 6040 0222
tel;cell:0419 464 430
note:I am heartily sick and tired of telemarketers, therefore I do not answer phone calls which do not present Caller Line Identification, they get flicked to voicemail.  I apologise if this inconveniences you, and I respect your right to not identify yourself, but I also ask that you respect my right to not answer your call if you choose not to identify yourself.  Try dialing 1832 (#32# from mobiles) before the number, to present Caller Line Identification.
x-mozilla-html:FALSE
url:http://www.lannet.com.au
version:2.1
end:vcard

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables SNAT not working

[Howard Lowndes]

Just a couple of lines from my iptables rule set:


iptables -A FORWARD -p UDP -s 192.168.254.17 --dport 4569 -i eth2 -o ppp0 -j 
ACCEPT

iptables -t nat -A POSTROUTING -p UDP -s 192.168.254.17 --dport 4569 -o ppp0 -j 
SNAT --to-source 218.214.47.111

Can anyone think of any obvious reason why the POSTROUTING rule is not
working.

-- 
Howard.
LANNet Computing Associates;
Your Linux people 
--
"When you just want a system that works, you choose Linux;
when you want a system that just works, you choose Microsoft."
--
"Flatter government, not fatter government;
Get rid of the Australian states."


-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables / proxy server madness

[Peter Rundle]

Robert Collins wrote:
[snip]
If everything is fine until the second CR, then you probably have a MTU
issue. See man iptables and put a MSS clamp rule in as they describe.
Bingo!
Thanks so much Rob this was exactly the problem. :-)
For the curious, the relevant man iptables info is,
   TCPMSS
   This target allows to alter the MSS value of TCP SYN packets,  to  con-
   trol  the maximum size for that connection (usually limiting it to your
   outgoing interfaces MTU minus 40).  Of course, it can only be used  in
   conjunction with -p tcp.
   This  target  is  used to overcome criminally braindead ISPs or servers
   which block ICMP Fragmentation Needed packets.  The  symptoms  of  this
   problem are that everything works fine from your Linux firewall/router,
   but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
   Workaround: activate this option and add a rule to your  firewall  con-
   figuration like:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
Cheers
P.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] SLUG] Iptables / proxy server madness

[Roger Salisbury]

I would suggest put DNS by hand (not automatic detection) on client machine.

Any IP DNS should do.

EG

Try Telstra's primary.61.9.192.14

& 

Try Telstra's secondary.61.9.192.15

Cheers Roger





Sluggers,

I'm hoping that someone can shed some light on this problem, otherwise I must be going mad.

I have two linux boxen, one of which is an internet gateway masquerading for the other 
using iptables. When I try to access a web site using Mozilla from the masqueraded box it 
fails miserably waiting forever for the reply packets. However, if I telnet to port 80 of 
the site I get an immediate response. I can also ssh out to other servers on the net no 
problems. Now before you jump to any conclusions, the advanced proxy settings in Mozilla 
are set to direct connection to the internet.

Now things get really weird. If I run squid on the gateway and use an iptables redirect of 
80 to 3128 (Rob's comments about transparent proxying not withstanding) then Mozilla is 
happy as Larry. ???

Ok what gives am I

a) going mad

b) being suckered by some hidden mozilla (drive pete crazy) option selected.

c) something else I don't know about I.e Internet bug #23876412282?

Cluesticks?

TIA's

Pete

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] Iptables / proxy server madness

[Peter Rundle]

Sluggers,

I'm hoping that someone can shed some light on this problem, otherwise I must be going mad.

I have two linux boxen, one of which is an internet gateway masquerading for the other 
using iptables. When I try to access a web site using Mozilla from the masqueraded box it 
fails miserably waiting forever for the reply packets. However, if I telnet to port 80 of 
the site I get an immediate response. I can also ssh out to other servers on the net no 
problems. Now before you jump to any conclusions, the advanced proxy settings in Mozilla 
are set to direct connection to the internet.

Now things get really weird. If I run squid on the gateway and use an iptables redirect of 
80 to 3128 (Rob's comments about transparent proxying not withstanding) then Mozilla is 
happy as Larry. ???

Ok what gives am I

a) going mad

b) being suckered by some hidden mozilla (drive pete crazy) option selected.

c) something else I don't know about I.e Internet bug #23876412282?

Cluesticks?

TIA's

Pete

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables / proxy server madness

[Robert Collins]

On Tue, 2004-05-04 at 09:30, Peter Rundle wrote:
> Sluggers,
> 
> I'm hoping that someone can shed some light on this problem, otherwise I must be 
> going mad.
> 
> I have two linux boxen, one of which is an internet gateway masquerading for the 
> other 
> using iptables. When I try to access a web site using Mozilla from the masqueraded 
> box it 
> fails miserably waiting forever for the reply packets. However, if I telnet to port 
> 80 of 
> the site I get an immediate response. I can also ssh out to other servers on the net 
> no 
> problems. Now before you jump to any conclusions, the advanced proxy settings in 
> Mozilla 
> are set to direct connection to the internet.
> 
> Now things get really weird. If I run squid on the gateway and use an iptables 
> redirect of 
> 80 to 3128 (Rob's comments about transparent proxying not withstanding) then Mozilla 
> is 
> happy as Larry. ???

Ok, here's a checklist to run on the machine running mozilla (with the
interception rule in iptables disabled)
1) dig/host/ping bad-wed-address  
   we are just looking for correct name resolution - we don't need to
actually ping.
2) telnet  80
   type in between the ==='s (case unfortunately matters on some
servers):
===
GET / HTTP/1.1
Host: 



If this gives you the web page, then mozilla is whacked. Chances are
though that something will break.

If everything is fine until the second CR, then you probably have a MTU
issue. See man iptables and put a MSS clamp rule in as they describe.

Rob




-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] Iptables / proxy server madness

[Greg Cockburn]

Also,

Something that has tripped me up in the past when telneting to port 80 is 
transparent proxies.

But using http 1.1 and not just typing GET, will work.

Good luck,
Greg.

On Tue, 4 May 2004 10:09 am, Robert Collins wrote:
> On Tue, 2004-05-04 at 09:30, Peter Rundle wrote:
> > Sluggers,
> >
> > I'm hoping that someone can shed some light on this problem, otherwise I
> > must be going mad.
> >
> > I have two linux boxen, one of which is an internet gateway masquerading
> > for the other using iptables. When I try to access a web site using
> > Mozilla from the masqueraded box it fails miserably waiting forever for
> > the reply packets. However, if I telnet to port 80 of the site I get an
> > immediate response. I can also ssh out to other servers on the net no
> > problems. Now before you jump to any conclusions, the advanced proxy
> > settings in Mozilla are set to direct connection to the internet.
> >
> > Now things get really weird. If I run squid on the gateway and use an
> > iptables redirect of 80 to 3128 (Rob's comments about transparent
> > proxying not withstanding) then Mozilla is happy as Larry. ???
>
> Ok, here's a checklist to run on the machine running mozilla (with the
> interception rule in iptables disabled)
> 1) dig/host/ping bad-wed-address
>we are just looking for correct name resolution - we don't need to
> actually ping.
> 2) telnet  80
>type in between the ==='s (case unfortunately matters on some
> servers):
> ===
> GET / HTTP/1.1
> Host: 
>
> 
>
> If this gives you the web page, then mozilla is whacked. Chances are
> though that something will break.
>
> If everything is fine until the second CR, then you probably have a MTU
> issue. See man iptables and put a MSS clamp rule in as they describe.
>
> Rob
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables - filtering not working.

[Robert Collins]

On Mon, 2004-05-03 at 20:52, Ken Foskey wrote:
> Here are the rules, I want to stop port 80 being accepted from any
> network except squid on this machine.  This is not working.
> 
> I think I have a drop all INPUT for port 80 and it is not dropping.

get rid of the INPUT drop rule. You need a FORWARD drop (reject
suggested) rule for port 80.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables - filtering not working.

[Ken Foskey]

Here are the rules, I want to stop port 80 being accepted from any
network except squid on this machine.  This is not working.

I think I have a drop all INPUT for port 80 and it is not dropping.

Help...


gateway:~# iptables -L INPUT
Chain INPUT (policy DROP)
target prot opt source   destination
DROP   tcp  --  anywhere anywhere   tcp dpt:www
ACCEPT all  --  anywhere anywhere
LOGall  --  127.0.0.0/8  anywhere   LOG level
warning
DROP   all  --  127.0.0.0/8  anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  192.168.0.0/24   anywhere
ACCEPT!tcp  --  anywhere BASE-ADDRESS.MCAST.NET/4
LOGall  --  192.168.0.0/24   anywhere   LOG level
warning
DROP   all  --  192.168.0.0/24   anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  anywhere
c211-30-226-107.rivrw4.nsw.optusnet.com.au
ACCEPT all  --  anywhere 211.30.226.255
LOGall  --  anywhere anywhere   LOG level
warning
DROP   all  --  anywhere anywhere
DROP   tcp  --  anywhere anywhere   tcp dpt:www
gateway:~# iptables -L
Chain INPUT (policy DROP)
target prot opt source   destination
DROP   tcp  --  anywhere anywhere   tcp dpt:www
ACCEPT all  --  anywhere anywhere
LOGall  --  127.0.0.0/8  anywhere   LOG level
warning
DROP   all  --  127.0.0.0/8  anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  192.168.0.0/24   anywhere
ACCEPT!tcp  --  anywhere BASE-ADDRESS.MCAST.NET/4
LOGall  --  192.168.0.0/24   anywhere   LOG level
warning
DROP   all  --  192.168.0.0/24   anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  anywhere me.rivrw4.nsw.optusnet.com.au
ACCEPT all  --  anywhere 211.30.226.255
LOGall  --  anywhere anywhere   LOG level
warning
DROP   all  --  anywhere anywhere
DROP   tcp  --  anywhere anywhere   tcp dpt:www

Chain FORWARD (policy DROP)
target prot opt source   destination
ACCEPT all  --  192.168.0.0/24   anywhere
ACCEPT all  --  anywhere anywhere   state
RELATED,ESTABLISHED
LOGall  --  anywhere 192.168.0.0/24 LOG level
warning
DROP   all  --  anywhere 192.168.0.0/24
LOGall  --  anywhere anywhere   LOG level
warning
DROP   all  --  anywhere anywhere

Chain OUTPUT (policy DROP)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  anywhere 192.168.0.0/24
ACCEPT!tcp  --  anywhere BASE-ADDRESS.MCAST.NET/4
LOGall  --  anywhere 192.168.0.0/24 LOG level
warning
DROP   all  --  anywhere 192.168.0.0/24
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  me.rivrw4.nsw.optusnet.com.au  anywhere
ACCEPT all  --  211.30.226.255   anywhere
LOGall  --  anywhere anywhere   LOG level
warning
DROP   all  --  anywhere anywhere



-- 
Thanks
KenF
OpenOffice.org developer

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables DNAT question

[Peter Rundle]

Alexander Samad wrote:

Why not something differnt and reverse proxy ?
 

Because that means installing and configuring software such as squid or 
apache on the gateway, where as if I can do it with iptables that's a 
whole bunch less configuration I have to do. Also if  I can figure this 
out with IP tables for port 80 then I can get it to work for other 
protocols such as e-mail.

Thanks for the replies so far, I figure that SNAT is the way to go, 
hadn't thought of marking the packet though that might be worth trying, 
was hoping someone on the list might have done this but time to be brave 
(foolish?) and go where others have yet to tread?

P.

P.S Not currently subscribed --> fragile internet link. (working on that 
as we byte)

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables DNAT question

[Robert Collins]

On Fri, 2004-02-20 at 10:43, Alexander Samad wrote:
> Why not something differnt and reverse proxy ?

Because I was answering the question.

If we were talking reverse proxy, I'd be pimping squid, naturally.

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables DNAT question

[Alexander Samad]

Why not something differnt and reverse proxy ?

On Fri, Feb 20, 2004 at 09:54:40AM +1100, Robert Collins wrote:
> On Fri, 2004-02-20 at 09:49, Phil Scarratt wrote:
> > Peter Rundle wrote:
> > > Sluggers,
> > > 
> > > I'm D'nating access to my web server via my Linux Gateway with this 
> > > statement.
> > > 
> > >iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 
> > > 172.16.0.148
> > > 
> > > This works great as long as the default gateway on the web server 
> > > (172.16.0.148) points to the Linux Gateway.
> > > 
> > > However, I need to set the default gateway of the web server to 
> > > somewhere else (an alternate internet connection) When I do this the 
> > > reply packets never make it back to the gateway, and I have an asymetric 
> > > routing situation (Kinda as expected really).
> > > 
> > > My Question is;
> > > 
> > > Is there a complimentary iptables statement that I can use to SNAT's the 
> > > inbound packet so that the web server
> > > see's the source as the Linux gateway hence the packet is returned there 
> > > where upon it is readdressed back to the real originating client in the 
> > > outside world?
> 
> yes, surprisingly enough it's 'SNAT'. 
> I suggest you use a mark rule in the mangle table to mark the packet
> before DNAT and SNAT, then DNAT & SNAT based on the fwmark.
> 
> Rob
> 
> 
> -- 
> GPG key available at: .



> -- 
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html



signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables DNAT question

[Robert Collins]

On Fri, 2004-02-20 at 09:49, Phil Scarratt wrote:
> Peter Rundle wrote:
> > Sluggers,
> > 
> > I'm D'nating access to my web server via my Linux Gateway with this 
> > statement.
> > 
> >iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 
> > 172.16.0.148
> > 
> > This works great as long as the default gateway on the web server 
> > (172.16.0.148) points to the Linux Gateway.
> > 
> > However, I need to set the default gateway of the web server to 
> > somewhere else (an alternate internet connection) When I do this the 
> > reply packets never make it back to the gateway, and I have an asymetric 
> > routing situation (Kinda as expected really).
> > 
> > My Question is;
> > 
> > Is there a complimentary iptables statement that I can use to SNAT's the 
> > inbound packet so that the web server
> > see's the source as the Linux gateway hence the packet is returned there 
> > where upon it is readdressed back to the real originating client in the 
> > outside world?

yes, surprisingly enough it's 'SNAT'. 
I suggest you use a mark rule in the mangle table to mark the packet
before DNAT and SNAT, then DNAT & SNAT based on the fwmark.

Rob


-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables DNAT question

[Phil Scarratt]

Peter Rundle wrote:
Sluggers,

I'm D'nating access to my web server via my Linux Gateway with this 
statement.

   iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 
172.16.0.148

This works great as long as the default gateway on the web server 
(172.16.0.148) points to the Linux Gateway.

However, I need to set the default gateway of the web server to 
somewhere else (an alternate internet connection) When I do this the 
reply packets never make it back to the gateway, and I have an asymetric 
routing situation (Kinda as expected really).

My Question is;

Is there a complimentary iptables statement that I can use to SNAT's the 
inbound packet so that the web server
see's the source as the Linux gateway hence the packet is returned there 
where upon it is readdressed back to the real originating client in the 
outside world?

I know that I can put Apache on the Linux Gateway and reverse-proxy 
but... just wondering if there was
"a better way (tm)"

TIA's

P.
I've never had to use SNAT but it does exist, so presumably it can do 
what you want it to. Checkout the man page for iptables or I'm sure 
there's a howto somewhere.

Fil
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] IPtables DNAT question

[Peter Rundle]

Sluggers,

I'm D'nating access to my web server via my Linux Gateway with this 
statement.

   iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 
172.16.0.148

This works great as long as the default gateway on the web server 
(172.16.0.148) points to the Linux Gateway.

However, I need to set the default gateway of the web server to 
somewhere else (an alternate internet connection) When I do this the 
reply packets never make it back to the gateway, and I have an asymetric 
routing situation (Kinda as expected really).

My Question is;

Is there a complimentary iptables statement that I can use to SNAT's the 
inbound packet so that the web server
see's the source as the Linux gateway hence the packet is returned there 
where upon it is readdressed back to the real originating client in the 
outside world?

I know that I can put Apache on the Linux Gateway and reverse-proxy 
but... just wondering if there was
"a better way (tm)"

TIA's

P.



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables (debian)

[James Gray]

Andrew Cowie wrote:
On Sat, 2003-12-20 at 22:26, Daniel Bush wrote:

am wondering if the LOG facility of iptables and syslogd are the
problem.  Have also disabled any '(x)console/tty' items from /etc/syslog.conf )


It's always possible you missed something...

In any case, I always found on my Debian systems that to be sane and
happy I would do the following:
rm /dev/console
ln -s /dev/tty2 /dev/console
[where 2 was a vt I removed the getty from and had it just for logging]

That, in turn, is a trick I learned from years and years ago on Xenix
systems when the default resulting in the same effect you're describing
- caused because /dev/console was pointing at /dev/tty0 - which results
in any and all console [virtual] ttys being sprayed.
Just my 0.02:

My /etc/syslog.conf file has a customised entry:
*.*   /dev/tty12  # Log EVERYTHING to tty12
/dev/tty12 is reached by ALT+F12.

I also symlinked /dev/console -> /dev/tty11 (ALT+F11).  This way I see 
*everything* on tty12 and only the critical stuff on tty11.

tty's 1-6 are usually getty's, tty7=Xserver, this leaves tty8-12 for 
playing around with this console logging stuff.  I started at 12 and 
worked backwards as sometimes I run more than one X session and they 
increment from 7 upwards.  So if I had console logging to tty8, it might 
cause problems.

Just a thought :) YMMV

--James

--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables (debian)

[Daniel Bush]

Hi Rene,
That's bang on the money!
And for a bonus, you've told me how to get a separate firewall log file without
having to do too much extra work.  
You've seriously made my day. Thanks.

My thanks also goes to Andrew and Julian for helpful extras in earlier posts.
Cheers, 
Daniel.

On 18:37 21-12-2003, Rene Cunningham wrote:
> On Sun, Dec 21, 2003 at 02:26:40PM +1100, Daniel Bush wrote:
> > example (iptables 'seems' to print this both to tty and
> > /var/log/messages... )
> > -
> >   IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
> > TOS=0x00 PREC=0x00 TTL=110 ID=12283 DF PROTO=TCP SPT=3830 DPT=135
> > WINDOW=8760 RES=0x00 SYN URGP=0
> >   IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
> > TOS=0x00 PREC=0x00 TTL=110 ID=12305 DF PROTO=TCP SPT=3830 DPT=135
> > WINDOW=8760 RES=0x00 SYN URGP=0
> > -
> 
> You need to configure klogd to display messages with loglevels lower
> than what your logging with iptables. Any sane firewall shouldnt be
> logging these messages lower than KERN_WARNING (4).
> 
> To configure klogd the debian (sid) way edit /etc/init.d/klogd and instead of
> KLOGD="" use KLOGD="-c 3".
> 
> Nifty trick is to log iptables stuff with --log-level debug, then throw
> all kern.=debug into a file via syslog. That way you have a nice
> firewall log that sits in a file. Dont forget to logrotate.
> 
> -- 
> 
> Rene Cunningham
> DCLabs Pty Ltd
> http://www.dclabs.com.au
> 
> We are governed not by armies and police but by ideas.
>   -- Mona Caird, 1892
> -- 
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables (debian)

[Rene Cunningham]

On Sun, Dec 21, 2003 at 02:26:40PM +1100, Daniel Bush wrote:
> example (iptables 'seems' to print this both to tty and
> /var/log/messages... )
> -
>   IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
> TOS=0x00 PREC=0x00 TTL=110 ID=12283 DF PROTO=TCP SPT=3830 DPT=135
> WINDOW=8760 RES=0x00 SYN URGP=0
>   IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
> TOS=0x00 PREC=0x00 TTL=110 ID=12305 DF PROTO=TCP SPT=3830 DPT=135
> WINDOW=8760 RES=0x00 SYN URGP=0
> -

You need to configure klogd to display messages with loglevels lower
than what your logging with iptables. Any sane firewall shouldnt be
logging these messages lower than KERN_WARNING (4).

To configure klogd the debian (sid) way edit /etc/init.d/klogd and instead of
KLOGD="" use KLOGD="-c 3".

Nifty trick is to log iptables stuff with --log-level debug, then throw
all kern.=debug into a file via syslog. That way you have a nice
firewall log that sits in a file. Dont forget to logrotate.

-- 

Rene Cunningham
DCLabs Pty Ltd
http://www.dclabs.com.au

We are governed not by armies and police but by ideas.
-- Mona Caird, 1892
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: [SLUG] iptables (debian)

[Julian Melville]

> It doesn't just print to any tty; it assiduously finds the one I'm
> currently on and prints to that (ie the one currently on-screen
> locally).  It doesn't seem to happen when I log in remotely but still,
> this is starting to get me down.

I've noticed this with the Shorewall firewall. It was driving me nuts, until
I read their FAQ

"Shorewall is writing log messages all over my console making it unusable!

Answer: If you are running Shorewall version 1.4.4 or 1.4.4a then check the
errata. Otherwise, see the 'dmesg' man page ("man dmesg"). You must add a
suitable 'dmesg' command to your startup scripts or place it in
/etc/shorewall/start. Under RedHat, the max log level that is sent to the
console is specified in /etc/sysconfig/init in the LOGLEVEL variable."

(http://www.shorewall.net/FAQ.htm#faq16)

I added "dmesg -n 2" to the Shorewall startup script (it could also go in
another startup script) and haven't seen anything since.

Cheers,

Julian.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] iptables (debian)

[Andrew Cowie]

On Sat, 2003-12-20 at 22:26, Daniel Bush wrote:
> am wondering if the LOG facility of iptables and syslogd are the
> problem.  Have also disabled any '(x)console/tty' items from /etc/syslog.conf )

It's always possible you missed something...

In any case, I always found on my Debian systems that to be sane and
happy I would do the following:

rm /dev/console
ln -s /dev/tty2 /dev/console

[where 2 was a vt I removed the getty from and had it just for logging]

That, in turn, is a trick I learned from years and years ago on Xenix
systems when the default resulting in the same effect you're describing
- caused because /dev/console was pointing at /dev/tty0 - which results
in any and all console [virtual] ttys being sprayed.

I never actually saw anything like /dev/tty0 being linked to
/dev/console, but it sure seemed that way on my Debian boxes.

This all assumes that replacing /dev/console as I suggest is a sane and
ok idea - Lord knows I could have been committing some horrible faux
pas.

I'm sure the Debian people out there in our lovely community will have a
more authoritative answer for you; it hasn't ever seemed to be a problem
on my lovely shiny Gentoo machines... :)

AfC
Toronto

-- 
Andrew Frederick Cowie
Operational Dynamics Consulting Pty Ltd

Australia +61 2 9977 6866   North America +1 646 472 5054

http://www.operationaldynamics.com/
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

[SLUG] iptables (debian)

[Daniel Bush]

Hi,
Just recently tried out debian on one of my old machines in place of a
redhat system I had been using for the past year.  But I am having
trouble with an iptables firewall script which keeps insisting on
spraying stuff to my terminal (tty1,2,3...) even though its being
syslogged into /var/log/messages with syslog priority of 'info' using a
LOG target.  
It doesn't just print to any tty; it assiduously finds the one I'm
currently on and prints to that (ie the one currently on-screen
locally).  It doesn't seem to happen when I log in remotely but still,
this is starting to get me down.

example (iptables 'seems' to print this both to tty and
/var/log/messages... )
-
  IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
TOS=0x00 PREC=0x00 TTL=110 ID=12283 DF PROTO=TCP SPT=3830 DPT=135
WINDOW=8760 RES=0x00 SYN URGP=0
  IN=ppp0 OUT= MAC= SRC=63.154.36.125 DST=203.206.0.244 LEN=48
TOS=0x00 PREC=0x00 TTL=110 ID=12305 DF PROTO=TCP SPT=3830 DPT=135
WINDOW=8760 RES=0x00 SYN URGP=0
-

(I compiled and installed a 2.4.13 kernel over the 'vanilla' 2.2.20 and
am wondering if the LOG facility of iptables and syslogd are the
problem.  Have also disabled any '(x)console/tty' items from /etc/syslog.conf )

It can't be a big thing.  Can anyone help?
Thanks, 
Daniel.

-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Re: [SLUG] IPtables Script

[Grant Parnell]

On Wed, 15 Oct 2003, Robert Collins wrote:

> On Wed, 2003-10-15 at 15:08, Craig Mead wrote:
> > G'day,
> > 1 - force it to come up on ppp0
> 
> unit 0 in the ppp config.

Oh nice! BUT that's not in the current release of pppd (2.4.1) but is in 
the new beta version (2.4.2b3). 
Thanks for alerting me to the possibility though, it's made me read the 
release notes for the beta, which includes some good stuff. MS-CHAP-v2, 
MPPE, PPPOE for example.

> 
> > 2 - set a var. @ the top of the script so its just one change per down
> 
> or use ppp+ in the iptables script, which will match all ppp interfaces.
> And doesn't need to be bounced on link failure/resumption.

Didn't know that either! Pity half my customers have ethX/pppX 
combinations ethX being the ADSL router and ppp0 being the modem backup 
:-( Also depends on the ADSL modem being used.

-- 
--
Electronic Hobyist, Former Arcadia BBS nut, Occasonal nudist, 
Linux Guru, SLUG/AUUG/Linux Australia member, Sydney Flashmobber,
BMX rider, Walker, Raver & rave music lover, Big kid that refuses
grow up. I'd make a good family pet, take me home today!
Do people actually read these things?

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Fw: [SLUG] IPtables Script

[Craig Mead]

- Original Message - 
From: "Robert Collins" <[EMAIL PROTECTED]>
To: "Craig Mead" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 15, 2003 3:11 PM
Subject: Re: [SLUG] IPtables Script


> 2 - set a var. @ the top of the script so its just one change per down

or use ppp+ in the iptables script, which will match all ppp interfaces.
And doesn't need to be bounced on link failure/resumption.

Rob


Rob,

Perfect!

Thank you!

Cheers, Craig
On Wed, 2003-10-15 at 15:08, Craig Mead wrote:
> G'day,
> 1 - force it to come up on ppp0

unit 0 in the ppp config.

> 2 - set a var. @ the top of the script so its just one change per down

or use ppp+ in the iptables script, which will match all ppp interfaces.
And doesn't need to be bounced on link failure/resumption.

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.


signature.asc
Description: Binary data
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPtables Script

[scott]

[EMAIL PROTECTED] wrote on 15-10-2003 03:08:16 PM:

> G'day,
> 
> Got an iptables script which shares the DSL out over the network. Thanks 
to
> the joys of being on Telstra the connections been up and down quite
> regularly lately.
> 
> Problem is the script is (well, was) based around ppp0
> 
> When the connection goes down it usually doesn't come back up as ppp0, 
it'll
> be ppp1 > ppp4 etc.
> 
> Currently just going thru the script and replacing any instances of pppX
> with pppY each time it comes up on a diff. i/f
> 
> 2 thoughts on how I could try and fix it
> 
> 1 - force it to come up on ppp0
> 2 - set a var. @ the top of the script so its just one change per down
> 
> Problem!
> 
You could use ip-up.
What flavor of Linux are you using? All I know is between Redhat and 
Debian they are different.
man pppd and search for ip-up for details. I think the pppX is file 
descriptor 1.

An example script would be for redhat in /etc/ppp/ip-up.local (providing 
you are only using ppp on your dsl, and nothing else):

/path/to/firewall.sh $1

And put in your firewall script: $ppp=$1

Don't forget to make the ip-up.local executable for the user that pppd 
launches as.

Cheers,

Scott
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPtables Script

[Robert Collins]

On Wed, 2003-10-15 at 15:08, Craig Mead wrote:
> G'day,
> 1 - force it to come up on ppp0

unit 0 in the ppp config.

> 2 - set a var. @ the top of the script so its just one change per down

or use ppp+ in the iptables script, which will match all ppp interfaces.
And doesn't need to be bounced on link failure/resumption.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] IPtables Script

[Craig Mead]

G'day,

Got an iptables script which shares the DSL out over the network. Thanks to
the joys of being on Telstra the connections been up and down quite
regularly lately.

Problem is the script is (well, was) based around ppp0

When the connection goes down it usually doesn't come back up as ppp0, it'll
be ppp1 > ppp4 etc.

Currently just going thru the script and replacing any instances of pppX
with pppY each time it comes up on a diff. i/f

2 thoughts on how I could try and fix it

1 - force it to come up on ppp0
2 - set a var. @ the top of the script so its just one change per down

Problem!

I dunno how to do either.

Thoughts / comments / flames appreciated.

TIA.

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[Adam Hewitt]

I guess it helps when I look at the info I am posting about...the HOWTO
is actually the IP-MASQ HOWTO, which does talk about iptables, and
although it is called the IP-MASQ howto, it is very easy to work out
from the info how to turn of MASQ if you don't need it.

Adam.

On Thu, 2003-01-23 at 15:41, Graeme Robinson wrote:
> On 23 Jan 2003, Adam Hewitt wrote:
> 
> > Hi Peter,
> > 
> > Have a look at the HOWTO (firewall iirc) under the documentation section
> > at linux.org, you can cut and paste that script and it will work and you
> > will learn nuts and bolts while you are reading throught the
> > documentation...
> 
> this howto appears deprecated 
> http://www.linux.org/docs/ldp/howto/Firewall-HOWTO.html 
> as it doesn't include information on IPTables 
> configuration. 
> 
> Theres a tutorial here however;
> 
>http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html#STATEMACHINEINTRODUCTION
> 
> 
> -=-=-==-=-=--=-=-=-=-=-=-=-=-=-=-=-=
> Graeme Robinson - Graenet consulting
> www.graenet.com - internet solutions
> -=-=-=-=-=-=-=-=-=-=-==---=-=--=-=-=
> 


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[mlh]

On Thu, Jan 23, 2003 at 01:29:42PM +1100, Peter Vogel wrote:
> I am trying to configure a firewall for my new Reddhat 8 installation,
> operating as a masquerading internet gateway.
> 
> I have tried various IPTABLES scripts I have found on the net, but they
> generate lots of errors when I  try to run them; some examples:
> 
> Unkown arg --sport
> --state Command not found
> -j Command not found
> DNAT command not found

You probably have something like 

$IPTABLES --state .. --sport ... -j ... blah blah

and IPTABLES var is not defined.

Set it to iptables and you should be ok, but the other
respondents on this thread had some good (better?) suggestions.

Matt
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

RE: [SLUG] IPTABLES/RH8

[Jon Biddell]

Even better than Firestarter is ShoreWall - www.shorewall.net -
firewalling on Redhat (or anything else !!) couldn't be simpler.

Mine is running on Redhat 8 at the moment with no problems.

Jon

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Robert Collins
Sent: Thursday, 23 January 2003 1:39 PM
To: Peter Vogel
Cc: [EMAIL PROTECTED]
Subject: Re: [SLUG] IPTABLES/RH8


On Thu, 2003-01-23 at 13:29, Peter Vogel wrote:
> I am trying to configure a firewall for my new Reddhat 8
installation, 
> operating as a masquerading internet gateway.

You might try firestarter - its quite nice. (If you don't want to
get down to the metal, that is)

Rob
-- 
GPG key available at:
<http://users.bigpond.net.au/robertc/keys.txt>.

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[Graeme Robinson]

On 23 Jan 2003, Adam Hewitt wrote:

> Hi Peter,
> 
> Have a look at the HOWTO (firewall iirc) under the documentation section
> at linux.org, you can cut and paste that script and it will work and you
> will learn nuts and bolts while you are reading throught the
> documentation...

this howto appears deprecated 
http://www.linux.org/docs/ldp/howto/Firewall-HOWTO.html 
as it doesn't include information on IPTables 
configuration. 

Theres a tutorial here however;
http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html#STATEMACHINEINTRODUCTION


-=-=-==-=-=--=-=-=-=-=-=-=-=-=-=-=-=
Graeme Robinson - Graenet consulting
www.graenet.com - internet solutions
-=-=-=-=-=-=-=-=-=-=-==---=-=--=-=-=

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[Adam Hewitt]

Hi Peter,

Have a look at the HOWTO (firewall iirc) under the documentation section
at linux.org, you can cut and paste that script and it will work and you
will learn nuts and bolts while you are reading throught the
documentation...

Adam.

On Thu, 2003-01-23 at 13:29, Peter Vogel wrote:
> I am trying to configure a firewall for my new Reddhat 8 installation,
> operating as a masquerading internet gateway.
> 
> I have tried various IPTABLES scripts I have found on the net, but they
> generate lots of errors when I  try to run them; some examples:
> 
> Unkown arg --sport
> --state Command not found
> -j Command not found
> DNAT command not found
> 
> Iptables version is V1.2.6a
> 
> Any suggeestions what I've done wrong? 
> 
> Can anyone direct me to a script that would be a suitable template (for
> an  internet server/gateway connected to a lan)?
> 
> Thanks
> 
> Peter
> 
> 
> -- 
> SLUG - Sydney Linux User's Group - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[Erik de Castro Lopo]

Hi Peter,

On Thu, 23 Jan 2003 13:29:42 +1100
Peter Vogel <[EMAIL PROTECTED]> wrote:

> I am trying to configure a firewall for my new Reddhat 8 installation,
> operating as a masquerading internet gateway.
> 
> I have tried various IPTABLES scripts I have found on the net, but they
> generate lots of errors when I  try to run them; some examples:
>
> Unkown arg --sport
> --state Command not found
> -j Command not found
> DNAT command not found
> 
> Iptables version is V1.2.6a
> 
> Any suggeestions what I've done wrong? 

If the Monmotha scripts (see below) don't work, there is a good chance 
that you may not have all the necessary iptable and NAT stuff compiled 
into your kernel.

Is your's a custom kernel or the default Redhat one?

> Can anyone direct me to a script that would be a suitable template (for
> an  internet server/gateway connected to a lan)?

I found the Monmotha firewall script very easy to set up. Its available
here:

http://monmotha.mplug.org/firewall/index.php

Its basically a shell script with some configuration stuff at the top
and a whole bunch of stuff below that should be ignored :-).

Cheers,
Erik (Fairlight ESP employee from 1995 to 2000 :-))
-- 
+---+
  Erik de Castro Lopo  [EMAIL PROTECTED] (Yes it's valid)
+---+
"Two hands working can do more than a thousand clasped in prayer." 
-- anonymous
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES/RH8

[Robert Collins]

On Thu, 2003-01-23 at 13:29, Peter Vogel wrote:
> I am trying to configure a firewall for my new Reddhat 8 installation,
> operating as a masquerading internet gateway.

You might try firestarter - its quite nice. (If you don't want to get
down to the metal, that is)

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

[SLUG] IPTABLES/RH8

[Peter Vogel]

I am trying to configure a firewall for my new Reddhat 8 installation,
operating as a masquerading internet gateway.

I have tried various IPTABLES scripts I have found on the net, but they
generate lots of errors when I  try to run them; some examples:

Unkown arg --sport
--state Command not found
-j Command not found
DNAT command not found

Iptables version is V1.2.6a

Any suggeestions what I've done wrong? 

Can anyone direct me to a script that would be a suitable template (for
an  internet server/gateway connected to a lan)?

Thanks

Peter


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

RE: [SLUG] Iptables - UDP Frag?

[MacFarlane, Jarrod]

Thanks for the info!  I think I will follow your last two suggestions.

Cheers,
Jarrod

chesty wrote:

> I think its safer to tell the kernel to always reassemble fragments,
> therefore iptables will never see fragments.
> Its done automatically if you load a NAT or connection 
> tracking module, 
> I'm not really sure how to do it manually any more, there used to be 
> a kernel option.
> 
> You also might want to look at why its being fragmented in the first
> place, check MTUs, etc. If you can avoid the fragmentation, it might
> make things more efficient and reliable.
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] Iptables - UDP Frag?

[chesty]

On Fri, Jan 10, 2003 at 09:22:15AM +1100, MacFarlane, Jarrod wrote:
> Jan 10 08:57:58 firewall kernel: __FORWARD_DROP__IN=eth1 OUT=eth2
> SRC=10.1.1.72 DST=10.2.0.11 LEN=89 TOS=0x00 PREC=0x00 TTL=127 ID=11435
> FRAG:185 PROTO=UDP 
 
> Wondering what it is, and how I can allow it?

If a packet is bigger than the MTU of an interface, and
doesn't have the DF (don't fragment) flag set, it gets
split up into multiple, smaller sized fragments. (not a
text book answer, but rough enough I think).  

> I've allowed tcp/udp on the required ports between the src/dst hosts.  If I
> allow ALL udp between these hosts it doesn't produce this error message and
> works, but I'd prefer to keep the rules as tight as I can.

man iptables and search for fragment, it says that with second and
further fragments, there is no way to tell the source and destination
ports (none are displayed in your syslog message). Theres also some 
information in the iptables HOWTO.

You need to match second plus fragments from particular host
regardless of ports with the iptables -f option.
-i eth1 -o eth2 -s 10.1.1.72 -d 10.2.0.11 -p udp -f -j ACCEPT

I think its safer to tell the kernel to always reassemble fragments,
therefore iptables will never see fragments.
Its done automatically if you load a NAT or connection tracking module, 
I'm not really sure how to do it manually any more, there used to be 
a kernel option.

You also might want to look at why its being fragmented in the first
place, check MTUs, etc. If you can avoid the fragmentation, it might
make things more efficient and reliable.

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] Iptables - UDP Frag?

[MacFarlane, Jarrod]

Hi all,

I'm having the following show up in my internal firewall logs.

Jan 10 08:57:58 firewall kernel: __FORWARD_DROP__IN=eth1 OUT=eth2
SRC=10.1.1.72 DST=10.2.0.11 LEN=89 TOS=0x00 PREC=0x00 TTL=127 ID=11435
FRAG:185 PROTO=UDP 

Wondering what it is, and how I can allow it?

I've allowed tcp/udp on the required ports between the src/dst hosts.  If I
allow ALL udp between these hosts it doesn't produce this error message and
works, but I'd prefer to keep the rules as tight as I can.

Cheers,
Jarrod

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables ip-address format question...

[Andy Eager]

[EMAIL PROTECTED] wrote:


G'day all...

When creating my iptables firewall rules, if I specify an address as 
192.168.0.0 will that match all 192.168.*.* addresses?

No, you'd want 192.168.0.0/16 for that

Andy


--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables ip-address format question...

[Tim White]

No,

but 192.168.0.0/16 will (or 192.168.0.0/24 for 192.168.0.*)

Tim White



On Tue, 2002-11-19 at 14:05, [EMAIL PROTECTED] wrote:
> G'day all...
> 
> When creating my iptables firewall rules, if I specify an address as 
> 192.168.0.0 will that match all 192.168.*.* addresses?
> 
> Thanks...
> 
> Mike
> ---
> Michael S. E. Kraus
> Administration
> Capital Holdings Group (NSW) Pty Ltd
> [EMAIL PROTECTED]
> phone (02) 9955 8000 fax (02) 9955 8144
> -- 
> SLUG - Sydney Linux User's Group - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables ip-address format question...

[Matthew Palmer]

On Tue, 19 Nov 2002 [EMAIL PROTECTED] wrote:

> When creating my iptables firewall rules, if I specify an address as 
> 192.168.0.0 will that match all 192.168.*.* addresses?

No, that'll match the IP address 192.168.0.0 (it isn't necessarily a network
address, you know).  You'd be wanting 192.168.0.0/16, methinks.


-- 
---
#include 
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] iptables ip-address format question...

[mkraus]

G'day all...

When creating my iptables firewall rules, if I specify an address as 
192.168.0.0 will that match all 192.168.*.* addresses?

Thanks...

Mike
---
Michael S. E. Kraus
Administration
Capital Holdings Group (NSW) Pty Ltd
[EMAIL PROTECTED]
phone (02) 9955 8000 fax (02) 9955 8144
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables problems

[Crossfire]

Matt M was once rumoured to have said:
> At 17:31 11/11/2002, you wrote:
> >I'm having a hard time deciphering iptables rules.  Would any of these 
> >rules cause a "sendto: operation not permitted" error?
> 
> Short answer: Probably not.
[much snipped]

Gah, I can't trust anybody on this list to answer these questions
properly, can I? :P

The answer is yes, but you haven't given us enough information to
point to a specific rule.

Your ruleset suggests to me you're using interface specific rules, but
since you're not listing using -v, that information isn't being shown.

The "operation not permitted" error will occur if the sendto will be
denied by a DROP rule in your OUTPUT chain.  Remember, iptables is not
ipchains, and the OUTPUT chain has no effect on forwarded traffic.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables problems

[Howard Lowndes]

On Mon, 11 Nov 2002, Rob B wrote:

> I'm having a hard time deciphering iptables rules.  Would any of these
> rules cause a "sendto: operation not permitted" error?

Look at /proc/sys/net/ipv4/ip_forward  It should be = 1 if you are doing
forwarding.  Also look at your routing table - route -n

Your problem sounds more like something not responding to an arp request -
tcpdump might just be your friend.

>
> bunbun:~# iptables --list
> Chain INPUT (policy DROP)
> target prot opt source   destination
> ipac_inall  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> LOGall  --  127.0.0.0/8  anywhere   LOG level warning
> DROP   all  --  127.0.0.0/8  anywhere
> ACCEPT all  --  anywhere 255.255.255.255
> ACCEPT all  --  10.0.0.0/24  anywhere
> LOG   !tcp  --  anywhere 224.0.0.0/4LOG level warning
> DROP  !tcp  --  anywhere 224.0.0.0/4
> LOGall  --  10.0.0.0/24  anywhere   LOG level warning
> DROP   all  --  10.0.0.0/24  anywhere
> ACCEPT all  --  anywhere 255.255.255.255
> LOGall  --  anywhere anywhere   LOG level warning
> DROP   all  --  anywhere anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> ipac_inall  --  anywhere anywhere
> ipac_out   all  --  anywhere anywhere
> ACCEPT all  --  10.0.0.0/24  anywhere
> LOGall  --  anywhere 10.0.0.0/24LOG level warning
> DROP   all  --  anywhere 10.0.0.0/24
> LOGall  --  anywhere anywhere   LOG level warning
> DROP   all  --  anywhere anywhere
>
> Chain OUTPUT (policy DROP)
> target prot opt source   destination
> ipac_out   all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere 255.255.255.255
> ACCEPT all  --  anywhere 10.0.0.0/24
> ACCEPT!tcp  --  anywhere 224.0.0.0/4
> LOGall  --  anywhere 10.0.0.0/24LOG level warning
> DROP   all  --  anywhere 10.0.0.0/24
> ACCEPT all  --  anywhere 255.255.255.255
> LOGall  --  anywhere anywhere   LOG level warning
> DROP   all  --  anywhere anywhere
>
> The ipac_in and ipac_out rules consist only of LOG targets, so I haven't
> included them.
>
> cheers,
> rob
>
>
> --
> Decisions terminate panic.
>
> This is random quote 417 of a collection of 1255
>
> Distance from the centre of the brewing universe:
> [15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian
>
> Public Key fingerprint = 6219 33BD A37B 368D 29F5  19FB 945D C4D7 1F66 D9C5
>
>

-- 
Howard.
LANNet Computing Associates - Your Linux people
Contact detail at http://www.lannetlinux.com
"Flatter government, not fatter government." - me
 Get rid of the Australian states.
--
If electricity comes from electrons, does morality come from morons?


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables problems

[Matt M]

At 17:31 11/11/2002, you wrote:

I'm having a hard time deciphering iptables rules.  Would any of these 
rules cause a "sendto: operation not permitted" error?

Short answer: Probably not.

Long answer: Yes, but only if your IP is in the range 10.0.0.0/24, and if 
it was, well, you wouldn't be able to send any traffic at all.

Also, your IPTables config is kinda weird. There are several redundant 
rules in there, notably the DROP rule at the end of each chain (since your 
policy on each chain is DROP, IPTables will automatically drop any packets 
not captured by a rule at the end of a chain), and the ACCEPT and DROP 
rules relating to 10.0.0.0/24 in the OUTPUT chain (IPTables runs through a 
chain in a top to bottom linear fashion. Thus, allowing packets going to a 
destination and then later dropping them is kinda silly).

The IPTables documentation on the netfilter (aka iptables) site is very 
good. I'd suggest you read some of it. http://www.netfilter.org

HTH,

Matt

bunbun:~# iptables --list
Chain INPUT (policy DROP)
target prot opt source   destination
ipac_inall  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
LOGall  --  127.0.0.0/8  anywhere   LOG level warning
DROP   all  --  127.0.0.0/8  anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  10.0.0.0/24  anywhere
LOG   !tcp  --  anywhere 224.0.0.0/4LOG level warning
DROP  !tcp  --  anywhere 224.0.0.0/4
LOGall  --  10.0.0.0/24  anywhere   LOG level warning
DROP   all  --  10.0.0.0/24  anywhere
ACCEPT all  --  anywhere 255.255.255.255
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ipac_inall  --  anywhere anywhere
ipac_out   all  --  anywhere anywhere
ACCEPT all  --  10.0.0.0/24  anywhere
LOGall  --  anywhere 10.0.0.0/24LOG level warning
DROP   all  --  anywhere 10.0.0.0/24
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

Chain OUTPUT (policy DROP)
target prot opt source   destination
ipac_out   all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  anywhere 10.0.0.0/24
ACCEPT!tcp  --  anywhere 224.0.0.0/4
LOGall  --  anywhere 10.0.0.0/24LOG level warning
DROP   all  --  anywhere 10.0.0.0/24
ACCEPT all  --  anywhere 255.255.255.255
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

The ipac_in and ipac_out rules consist only of LOG targets, so I haven't 
included them.

cheers,
rob


--
Decisions terminate panic.

This is random quote 417 of a collection of 1255

Distance from the centre of the brewing universe:
[15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian

Public Key fingerprint = 6219 33BD A37B 368D 29F5  19FB 945D C4D7 1F66 D9C5

--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] iptables problems

[Rob B]

I'm having a hard time deciphering iptables rules.  Would any of these 
rules cause a "sendto: operation not permitted" error?

bunbun:~# iptables --list
Chain INPUT (policy DROP)
target prot opt source   destination
ipac_inall  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
LOGall  --  127.0.0.0/8  anywhere   LOG level warning
DROP   all  --  127.0.0.0/8  anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  10.0.0.0/24  anywhere
LOG   !tcp  --  anywhere 224.0.0.0/4LOG level warning
DROP  !tcp  --  anywhere 224.0.0.0/4
LOGall  --  10.0.0.0/24  anywhere   LOG level warning
DROP   all  --  10.0.0.0/24  anywhere
ACCEPT all  --  anywhere 255.255.255.255
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ipac_inall  --  anywhere anywhere
ipac_out   all  --  anywhere anywhere
ACCEPT all  --  10.0.0.0/24  anywhere
LOGall  --  anywhere 10.0.0.0/24LOG level warning
DROP   all  --  anywhere 10.0.0.0/24
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

Chain OUTPUT (policy DROP)
target prot opt source   destination
ipac_out   all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere 255.255.255.255
ACCEPT all  --  anywhere 10.0.0.0/24
ACCEPT!tcp  --  anywhere 224.0.0.0/4
LOGall  --  anywhere 10.0.0.0/24LOG level warning
DROP   all  --  anywhere 10.0.0.0/24
ACCEPT all  --  anywhere 255.255.255.255
LOGall  --  anywhere anywhere   LOG level warning
DROP   all  --  anywhere anywhere

The ipac_in and ipac_out rules consist only of LOG targets, so I haven't 
included them.

cheers,
rob


--
Decisions terminate panic.

This is random quote 417 of a collection of 1255

Distance from the centre of the brewing universe:
[15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian

Public Key fingerprint = 6219 33BD A37B 368D 29F5  19FB 945D C4D7 1F66 D9C5

--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables / ipchains - Which suits me best?

[Kevin Saenz]

Really iptables is native for kernel 2.4, ipchains is perfect under 
kernel 2.2
I have tried running my ipchains rules under redhat 7.1 and found that 
it would
not run. So I upgraded my firewall rules to iptable based.

If you are a little lazy :) have a look at guarddog it requres KDE and from
what I have been told it is very easy to create icq, irc, ftp passive mode,
and netmeeting access no problems.

>I'm looking to share my dialup Internet connection on a soon to be 
>Redhat 7.3 machine, with two clients behind it on a private IP range.
>
>It has been about 3 years since I last did this, and I remember at the 
>time there was fiddling that was required to get things like IRC and 
>ICQ to work, specifically file transfers.
>
>Iptables is standard with RH 7.3, and in the latest kernels, so this 
>seemed the logical way to go.  In my brief research I noticed on 
>iptables.org that they say there is no ICQ module available.
>
>Basically I'd like the following to work for both machines behind my RH 
>box:
>
>- IRC (including DCC's)
>- ICQ (including file send/receive)
>- Netmeeting (nice, but not essential)
>- Music stealing programs? :)
>
>Does anyone have any experiences with getting these to work under 
>iptables?  Should I install and use SOCKS?
>
>Any feedback on the best way to attack this would be great!
>
>Thanks
>Sarah
>
>
>
>Powered by telstra.com
>
> 
>
>  
>



-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

RE: [SLUG] iptables / ipchains - Which suits me best?

[Marty Richards]

 
> > I'm looking to share my dialup Internet connection on a soon to be
> > Redhat 7.3 machine, with two clients behind it on a private 
> IP range.

[snip]

> 
> Works for me also.
> > - Netmeeting (nice, but not essential)

Netmeeting was a broken protocol last I looked (~18 mths ago), embedding IP
info deep within the packet where no header-mangler is likely to look.
"Forget it" is my recommedation. If Microsoft wants to write broken software
then leave them to it. (M$ wrote their own proprietary extension to M$ proxy
to handle this - maybe some one really keen has done so for Linux?)

> Never tried.
> > - Music stealing programs? :)

don't these things work over a pair of coathangers? They've been designed to
circumvent everything so they'll probably work. 

Cheers,
Marty
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables / ipchains - Which suits me best?

[michael]

> I'm looking to share my dialup Internet connection on a soon to be
> Redhat 7.3 machine, with two clients behind it on a private IP range.

Excellent, I've been doing this for a few years on and off, depending of
when I have a permenant or dynamic circuit to the net.>
> It has been about 3 years since I last did this, and I remember at the
> time there was fiddling that was required to get things like IRC and
> ICQ to work, specifically file transfers.

Yeah I know what you mean, I remember compiling the add on module for
2.2.x kernels with ipchains.
These days I use iptables and I have no problems with using ICQ and IRC
behind the nat box. My ICQ sends and receives files no problems. etc. As
for IRC that works fine also.>
> Iptables is standard with RH 7.3, and in the latest kernels, so this
> seemed the logical way to go.  In my brief research I noticed on
> iptables.org that they say there is no ICQ module available.

As stated icq works fine, and I have no need to use a module like we did
back in the 2.2.x kernel days with ipchains. iptables i must say is pretty
good like this.>
> Basically I'd like the following to work for both machines behind my RH
>  box:
>
> - IRC (including DCC's)

Works for me..
> - ICQ (including file send/receive)

Works for me also.
> - Netmeeting (nice, but not essential)

Never tried.
> - Music stealing programs? :)

Not tried.
>
> Does anyone have any experiences with getting these to work under
> iptables?  Should I install and use SOCKS?

You could install a socks server for anything that doesn't work, but ICQ
and IRC gives me no problems, as for your other apps, I don't use so I
can't comment. Hope my feedback helps with your decision :P>
> Any feedback on the best way to attack this would be great!
>
> Thanks
> Sarah
>
>
> 
> Powered by telstra.com
>
>
>
> --
> SLUG - Sydney Linux User's Group - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug



-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] iptables / ipchains - Which suits me best?

[sarahb_123]

I'm looking to share my dialup Internet connection on a soon to be 
Redhat 7.3 machine, with two clients behind it on a private IP range.

It has been about 3 years since I last did this, and I remember at the 
time there was fiddling that was required to get things like IRC and 
ICQ to work, specifically file transfers.

Iptables is standard with RH 7.3, and in the latest kernels, so this 
seemed the logical way to go.  In my brief research I noticed on 
iptables.org that they say there is no ICQ module available.

Basically I'd like the following to work for both machines behind my RH 
box:

- IRC (including DCC's)
- ICQ (including file send/receive)
- Netmeeting (nice, but not essential)
- Music stealing programs? :)

Does anyone have any experiences with getting these to work under 
iptables?  Should I install and use SOCKS?

Any feedback on the best way to attack this would be great!

Thanks
Sarah



Powered by telstra.com

 

-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] IPTABLES help needed

[Peter Rundle]

Hi Bernhard,

Sorry don't have an answer for you but would be
very interested in any you got.

> What do I need to do to get the return packet to go out on the
> correct interface?

Yeah, run into this issue many a time, "asymetric routing".
Perhaps you can re-write the source address to be the ip of the
isdn connection in some pre-routing command that will then force
it to go out that interface.

P.


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] IPTABLES help needed

[Bernhard Lüder]

Hi,

I want to make this short. So the situation is:

A gateway Linux box with 3 interfaces.
1 to a DSL link (Default route)
2 to a ISDN link
3 LAN

A web server on the LAN. Its default route is via the above
gateway server.

I want to serve web pages from the web server via the ISDN link
and keep the default route via the DSL.

I have used these rules:

/sbin/iptables -t nat -A PREROUTING -i $IFWW2 -p tcp -d
$IPWW2 --dport 80 -j DNAT --to $IPWEBSRV:80
/sbin/iptables -t nat -A POSTROUTING -o $IFMYNET -p tcp -d
$IPWEBSRV --dport 80 -j SNAT --to $IPMYNET

The problem is, that the request packet comes in correctly via
the ISDN link.
Then it's re-written to the web server on the LAN
The web server responds and the packet goes back into the LAN
interface.
It is de-SNAT'd,
but then goes out of the DSL interface instead of the ISDN
interface.

What do I need to do to get the return packet to go out on the
correct interface?
Is there a PREROUTING SNAT rule?
What exactly does MANGLE do?
Any suggestions?

Regards
Bernhard







-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] IPTables and routing

[Richard Hayes]

Dear list,

I have a Linux box acting as a NAT router with a number of ethernet ports.  
Each port uses the accounting features of IPTables but the masquerading is 
interfering with accounting functions.

Should I use IProute2 and ignore the masquerading?

The example in the Advanced Routing Howto is very close to my real problem

http://www.linuxguruz.org/iptables/howto/2.4routing-4.html#ss4.1

Any ideas or suggestions

regards,

Richard Hayes
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] IPTables modules .gz??

[Richard Hayes]

Dear list,

I am trying to install some IPTables rules on Mandrake 8.2.

I have an sample rule set and tried to modify it and install it.

1. Using iptables -L  
I get the following error " insmod error caused by incorrect modules 
parameters

2. iptables can't initiate  iptables 'filter'

After doing a locate a found 
/lib/modules/2.4.18-6mdk/kernel/net/ipv4/netfilter

BTW, why are all the modules blah.gz?


I have locked myself out of network connection, do I just go in and comment 
out the new rules or what?
 
Any advised or pointers would be gratefully received.

regards,

Richard Hayes
  
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables: newbie question

[Russell Davie]

Thanks for all the great suggestions, especially like ntsysv

I found its a Mandrake distro thing, which has its own quirks.  Mdk has a 
different directory system to what the ipchains compile and as a result it 
doesn't get started.   I found this by installing 
iptables-ipv6-1.2.6a-1mdk.i586.rpm, and whala! it worked!
an inspiration after re-reading Oskar Andreasson's treatise :-)
Hhhmph to non-standards in distros, hopefully that is fixed in more recent 
Mdk distro.
regards
Russell

At 11:40 PM 22/06/02 +1000, you wrote:

>Apparently some issues with > 1.2.6 and the 2.4.18 as the iptables had 
>bugging turned on by default. I know you are using 1.2.6, however I would 
>download the latest version and compile it too see if this fixes it. Is 
>the source you are talking about from the install cd-rom or a newer 
>download. If not from cd-rom, back to the monitor throwing.:)
>
>Russell Davie wrote:
>
>>Hi,
>>I'm having few challenges getting iptables up and running.
>>please help!
>>The kernel can't seem to see iptables when its called >start>
>>and replies with 
>>The kernel is 2.4.18, iptables is 1.2.6a, iptables has been compiled from
>>source, and kernel recompiled to include iptables and netfilter as per 
>>instructions from Iptables Tutorial 1.1.11 by Oskar Andreasson.  This box 
>>runs v smooth with Mandrake 7.2 with KDE 2.0.1.  This is sent this using 
>>the other PC OS and would really like to get fire wall installed before 
>>connecting to net with linux
>>regards Russell
>>
>>
>>
>>
>>---
>>Outgoing mail is certified Virus Free.
>>Free Antivirus @  http://www.grisoft.com/
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02
>>
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02




---
Outgoing mail is certified Virus Free.
Free Antivirus @  http://www.grisoft.com/
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02

Re: [SLUG] iptables: newbie question

[Antony Clarke]

Shouldn't post this late. I meant < 1.2.6. :(

Antony Clarke wrote:

> Apparently some issues with > 1.2.6 and the 2.4.18 as the iptables had 
> bugging turned on by default. I know you are using 1.2.6, however I 
> would download the latest version and compile it too see if this fixes 
> it. Is the source you are talking about from the install cd-rom or a 
> newer download. If not from cd-rom, back to the monitor throwing.:)
>
> Russell Davie wrote:
>
>> Hi,
>> I'm having few challenges getting iptables up and running.
>> please help!
>> The kernel can't seem to see iptables when its called > iptables start>
>> and replies with 
>> The kernel is 2.4.18, iptables is 1.2.6a, iptables has been compiled 
>> from
>> source, and kernel recompiled to include iptables and netfilter as 
>> per instructions from Iptables Tutorial 1.1.11 by Oskar Andreasson.  
>> This box runs v smooth with Mandrake 7.2 with KDE 2.0.1.  This is 
>> sent this using the other PC OS and would really like to get fire 
>> wall installed before connecting to net with linux
>> regards Russell
>>
>> 
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Free Antivirus @  http://www.grisoft.com/
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02
>>  
>>
>
>
>



-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables: newbie question

[Antony Clarke]

Apparently some issues with > 1.2.6 and the 2.4.18 as the iptables had 
bugging turned on by default. I know you are using 1.2.6, however I 
would download the latest version and compile it too see if this fixes 
it. Is the source you are talking about from the install cd-rom or a 
newer download. If not from cd-rom, back to the monitor throwing.:)

Russell Davie wrote:

> Hi,
> I'm having few challenges getting iptables up and running.
> please help!
> The kernel can't seem to see iptables when its called  iptables start>
> and replies with 
> The kernel is 2.4.18, iptables is 1.2.6a, iptables has been compiled from
> source, and kernel recompiled to include iptables and netfilter as per 
> instructions from Iptables Tutorial 1.1.11 by Oskar Andreasson.  This 
> box runs v smooth with Mandrake 7.2 with KDE 2.0.1.  This is sent this 
> using the other PC OS and would really like to get fire wall installed 
> before connecting to net with linux
> regards Russell
>
>
>
>
>---
>Outgoing mail is certified Virus Free.
>Free Antivirus @  http://www.grisoft.com/
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02
>  
>



-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] iptables: newbie question

[Russell Davie]

Hi,
I'm having few challenges getting iptables up and running.
please help!
The kernel can't seem to see iptables when its called 
and replies with 
The kernel is 2.4.18, iptables is 1.2.6a, iptables has been compiled from
source, and kernel recompiled to include iptables and netfilter as per 
instructions from Iptables Tutorial 1.1.11 by Oskar Andreasson.  This box 
runs v smooth with Mandrake 7.2 with KDE 2.0.1.  This is sent this using 
the other PC OS and would really like to get fire wall installed before 
connecting to net with linux
regards Russell



---
Outgoing mail is certified Virus Free.
Free Antivirus @  http://www.grisoft.com/
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 29/05/02

Re: [SLUG] iptables DNAT help required

[Peter Rundle]

Oops,

Ignore that last question, I forgot to re-enable forwarding.

Doh!

But hey I love it when it's that easy.

Cheers

Pete


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables DNAT help required

[Peter Rundle]

>
>
>s/POSTROUTING/PREROUTING/
>
>DNAT has to be applied before a routing decision is made so the
>packets can be routed correctly.
>

Hmmm, ok that makes sense. 'spose I should send a mail to the author and 
let him
know that his webpage is wrong (uh hmm "incorrect" :-)

Anyways the rule sticks now but I don't have successful connection yet. 
Is there
a way to log / watch the packets?

Do I need another matching rule to allow the return packets to be 
reverse nat'd
so that they go back out to the internet?

Thanks

Pete



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables DNAT help required

[Daniel Stone]

On Sun, Mar 24, 2002 at 07:12:52PM +1100, Crossfire wrote:
> Peter Rundle was once rumoured to have said:
> > # iptables -t nat -A POSTROUTING -p tcp -s 0/0 --dport 80 -j DNAT --to 
> > 192.168.1.99
> > iptables: Invalid argument
> > 
> > Cluesticks?
> 
> s/POSTROUTING/PREROUTING/
> 
> DNAT has to be applied before a routing decision is made so the
> packets can be routed correctly.

Conversely, SNAT has to be applied in POSTROUTING.

-- 
Daniel Stone<[EMAIL PROTECTED]>
 OMFG ... yesterday's head hunter wants contact information for Linus
now that I told him he's probably the only person with 10 years of
continuous Linux experience ;)



msg21895/pgp0.pgp
Description: PGP signature

Re: [SLUG] iptables DNAT help required

[Crossfire]

Peter Rundle was once rumoured to have said:
> Sluggers,
> 
> I'm playing around with DNAT on iptables but whenever I try to put
> the rule in I just get an error "Invalid argument". I've looked at a
> number of examples on the net and they all seem to be doing the same
> thing that I am. Does anyone know if there is a version problem? 
> I've got kernel 2.4.7-10 and iptables 1.2.3-1
> 
> Basically I want to have my firewall allow http traffic through from
> the outside world to a linux box on the internal net but this is
> what happens..
> 
> # iptables -t nat -A POSTROUTING -p tcp -s 0/0 --dport 80 -j DNAT --to 
> 192.168.1.99
> iptables: Invalid argument
> 
> Cluesticks?

s/POSTROUTING/PREROUTING/

DNAT has to be applied before a routing decision is made so the
packets can be routed correctly.

C.
-- 
--==--
  Crossfire  | This email was brought to you
  [EMAIL PROTECTED] | on 100% Recycled Electrons
--==--
-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

[SLUG] iptables DNAT help required

[Peter Rundle]

Sluggers,

I'm playing around with DNAT on iptables but whenever I try to put the 
rule in I just
get an error "Invalid argument". I've looked at a number of examples on 
the net and
they all seem to be doing the same thing that I am. Does anyone know if 
there is
a version problem? I've got kernel 2.4.7-10 and iptables 1.2.3-1

Basically I want to have my firewall allow http traffic through from the 
outside world
to a linux box on the internal net but this is what happens..

# iptables -t nat -A POSTROUTING -p tcp -s 0/0 --dport 80 -j DNAT --to 
192.168.1.99
iptables: Invalid argument

Cluesticks?

Thanks

Pete



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables help required

[Jon Biddell]

At 12:57 22/03/02 +1100, Kevin Saenz wrote:
>Peter,
>
>Firstly don't try by trial and error. Someone has already gone thru the
>same trouble as yourself. I would suggest that you go to freshmeat.net
>and do a search for iptables, there is a tutorial there I think it's
>boingworld.com or something like that. He is pretty good with his examples

Courtesy of Richard Hayes, there is an excellent iptables tutorial 
available at;

http://www-105.ibm.com/developerworks/education.nsf/dw/linux-onlinecourse-bytitle?OpenDocument&Count=500

And they're all FREE !!!

Jon

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Re: [SLUG] iptables accounting

[Jean-Francois Dive]

In fact,instead of loggging each packet, you should simply use the 2 counters
associated with each rule. So, for example:

Chain FORWARD (policy ACCEPT 2408 packets, 1136110 bytes)
pkts  bytes target prot opt in out source   
destination 
   00all  --  *  *   192.168.1.1  
0.0.0.0/0  

Then account on it. ip-ng does this parsing and store the counters.
Pay attention that thoses counters are 64bit ones and not 32 bit as usual. 

On Fri, Mar 22, 2002 at 01:59:05PM +1100, [EMAIL PROTECTED] wrote:
> Hi to everybody on the list
> 
> Thanks to all who replied to my Solaris / Linux query a couple of weeks
> ago.
> 
> I need a little help with a iptables problem.
> 
> I am trying to configure a linux machine to sit between two networks and
> log data downloads by hosts.
> 
> ie   192.168.10.0 - - - - - - - - - - - --eth0 - linux box  - eth1  - - - -
> - - - - - - - - - - - - - - - 192.168.20.0
> 
> I can currently log traffic using iptables to all destinations on y.0 using
> a separate rule under OUTPUT
> 
> -A FORWARD -j LOG --log-level 6 -d 192.168.2.0/255.255.255.0 -i eth1
> -A OUTPUT -j LOG --log-level 6 -d 192.168.20.8
> -A OUTPUT -j LOG --log-level 6 -d 192.168.20.9
> -A OUTPUT -j LOG --log-level 6 -d 192.168.20.10
> 
> And these messages are being logged to a file.
> 
> Does anyone have a suggestion for software that generates reports on the
> amount of data going to each server that I can use for billing on a monthly
> basis??
> 
> regards
> 
> Grant
> 
> 
> -- 
> SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug
-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug