Exempt one IP from DNAT for the whole network

Exempt one IP from DNAT for the whole network

[alok.shukla]

[-- Attachment #1: Type: text/html, Size: 711 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

Powered by Xgen(Next Generation Email Client)
http://www.datainfosys.com
Do not remove this:[XGEN]210120043820224284:NM[-XGEN-]

Re: Exempt one IP from DNAT for the whole network

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

On Wed, 2004-01-21 at 13:08, alok.shukla@soft.dil.in wrote:
> hi everybody ,,, 
> I have a unique problem. 
>  
> I have created a rule in the prerouting chain in the nat table to DNAT
> every packet coming from 10.11.12.0/24 network to the webserver
> running on the local machine
>  
> Now i want one of the IP from this pool to be exempted from this rule.
> I had put a rule in the mangle table so as to RETURN  from prerouting
> chain.
You need to put the rule in the same chain, just above your other rule.

iptables -t nat -A PREROUTING -i eth0 -p tcp -s 10.11.12.1 -j RETURN
iptables -t nat -A PREROUTING -i eth0 -p tcp -s 10.11.12.0/24 -j DNAT
--to 1.2.3.4

This works for me ...

>  
> I think that this RETURN is not working. I would like to know the
> other ways i can make a machine exempted from the DNAT that is
> occuring.
>  
> Kindly suggest
>  
> Alok Shukla
> 
> 
> ______________________________________________________________________
> Powered by Xgen(Next Generation Email Client)
> http://www.datainfosys.com
> Do not remove this:[XGEN]210120043820224284:NM[-XGEN-]
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Kirk Reiser]

Hi Folks:  I am not exactly sure how to relate my problem because it
is partly out of my own confusion after reading the documentation
available to me.

I have set up a box as a firewall/server to the net with two nics in
it.  I have gathered the netfilter/bridging patches from
sourceforge.net and applied them with a fair chunk of hand patching to
linux 2.4.24.  Some documentation seemed to indicate that they weren't
necessary on newer kernels but I couldn't find any solid confirmation
on that.  The site doesn't appear to have been updated or modified
since sometime in late 2002.

After patching it compiled just fine and the actual bridging seems to
be working fine.  I have two nics bridged to one interface br0.  My
problem seems to be with the actual filtering rules.  Although I can
control net flow in and out of the actual box itself I cannot get any
consistant results on controlling traffic into or out of the network.
I amlooking to control traffic in both directions.  I want to stop
incoming traffic on ports I do not aprove of and outgoing traffic from
possibly forged addresses which do not match their mac address from
the internal network.

I have tried using the INPUT and FORWARD chains with no apparent
results on the entire network.  If I use the actual NIC interfaces I
can control traffic to the machine but using the bridged interface
don't have much luck in either case.  The FORWARD chain doesn't seem
to have any affect at all and all the examples I've found use that
chain which is what is making me think it may not be working
correctly.  I have made sure I turned ip_forward on when trying the
FORWARD chain.  I have tried using 0/0 and the actual ip address for rules
to or from and it doesn't seem to make a noticible difference.  Here
is a sample of the rules I am trying:

iptables -A INPUT -s www.xxx.yyy.zzz -m mac --mac-source
xx:xx:xx:xx:... -d 0/0 -j ACCEPT -v
iptables -A INPUT -i $netaddress -s ! my-net-and-mask -d 0/0 -j ACCEPT

I have general purpose drop rules below each of these type statements
to catch non-matches which fall through.  I have replaced INPUT with
FORWARD in the append lines.  I have substituded the gateway machines
address in for the 0/0 component above and I am hopelessly lost
because I see no reason the rules should not work.  I will include the
most recent version of my script below.  The VALIDIP variable
represents lines with an ip address followed by the flags -m mac
--mac-source mac-address.

Did I say that I think most of the documentation out there on this
subject sucks!  They all seem to be long on do as I say and very very
short on why.  Any suggestions would be appreciated 'cause I'm not
sure what else to try. 'grin'

  Kirk

#!/bin/bash
clear
#
#Firewall, Port Filtering, and Port Forwarding Script for Linux Netfilter (IPTABLES)

#Define variables for NICS, IP addresses, and internal hosts we forward to and from
net=eth0
netportsallowed=20,21,22,25,110,113,115,143,220,443,515,873,995,3389
bridge=machine-address
sdc=eth1
sdcaddress=lan-address/24

# Turn on source address verification and spoof 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
  else
  echo "Problem setting up IP Spoofing protection!"
  fi
#Turn on SYN COOKIES PROTECTION Must be enabled in the kernel 
if [ -e /proc/sys/net/ipv4/tcp_syncookies ]
 then
  echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi

#Flush any previous rules
iptables -F -v
iptables -X  -v

#Default Policies
iptables -P INPUT DROP  # this'll change to DROP later
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# allow connections already established to continue
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -v

#internal localhost access
iptables -A INPUT -i lo -j ACCEPT -v

#Let's handle SDC side checks.
#if your ip matches your mac you're cool!
while read line; do
   VALIDIP=$(echo $line | sed 's/\n//')
   if [ "$VALIDIP" != "" ] ; then
      iptables -A INPUT -i $sdc -s $VALIDIP -d 0/0 -j ACCEPT -v
   fi
done < /etc/firewall/validips

#You got here we don't know you log and drop
iptables -A INPUT -i $sdc -s $sdcaddress -d 0/0 -j LOG --log-prefix "unknown sdc packets: "
iptables -A INPUT -i $sdc -s $sdcaddress -d 0/0 -j DROP -v


#Okay, let's handle net side packets.
#Some denys, before we open any of the "allow everyone" ports like SMTP
#New, but SYN flag not set? DROP it
iptables -A INPUT -i $net -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -A INPUT -i $net -p tcp ! --syn -m state --state NEW -j DROP -v

# Deny the addresses we don't like.
while read line; do
   BADDRESS=$(echo $line |awk ' {print $1 }' | sed 's/#//g')
   if [ "$BADDRESS" != "" ] ; then
      iptables -A INPUT -i $net -s "$BADDRESS" -d 0/0 -j DROP -v
   fi
done < /etc/firewall/baddresses

#individual service drops
#Drop icmp, but only after letting certain types through
iptables -A INPUT -i $net -p icmp --icmp-type 0 -j ACCEPT -v
iptables -A INPUT -i $net -p icmp --icmp-type 3 -j ACCEPT -v
iptables -A INPUT -i $net -p icmp --icmp-type 11 -j ACCEPT -v
iptables -A INPUT -i $net -p icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT -v
 
#Well, if we got here they've almost made it.
iptables -A INPUT -i $net -p tcp -d 0/0 -s ! $sdcaddress -m multiport --dports $netportsallowed -j ACCEPT -v
iptables -A INPUT -i $net -p udp -d 0/0 -s ! $sdcaddress -m multiport --dports $netportsallowed -j ACCEPT -v

#You got here not good, log and drop.
iptables -A INPUT -i $net -d 0/0 -j LOG --log-prefix "packets unknown: "
iptables -A INPUT -i $net -d 0/0 -s ! $sdcaddress -j DROP -v

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Cedric Blancher]

Le mer 21/01/2004 à 13:19, Kirk Reiser a écrit :
[...]
> iptables -A INPUT -s www.xxx.yyy.zzz -m mac --mac-source
> xx:xx:xx:xx:... -d 0/0 -j ACCEPT -v
> iptables -A INPUT -i $netaddress -s ! my-net-and-mask -d 0/0 -j ACCEPT
[...]

Bridge traffic appears within FORWARD chain only.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Kirk Reiser]

Okay, but are all interfaces available for filtering?  If not, how do
you distinguish incoming from the net verses lan?  As I stated earlier
I tried using FORWARD with no better results.

  Kirk

-- 

Kirk Reiser				The Computer Braille Facility
e-mail: kirk@braille.uwo.ca		University of Western Ontario
phone: (519) 661-3061

Re: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Cedric Blancher]

Le mer 21/01/2004 à 14:36, Kirk Reiser a écrit :
> Okay, but are all interfaces available for filtering?

Yes.
Just use -i and -o switches for input and output interfaces.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 

Re: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Philip Craig]

Kirk Reiser wrote:
> I'm having a bit of trouble with this statement because to me it
> doesn't seem to make sense without the notion of the interface cards.
> If eth0 is our interface to the net and eth1 our interface to the lan
> then input to an interface makes sense because input to eth0 means one
> set of rules while input to eth1 means a totally separate set.  When
> you are talking about a virtual interface such as br0 how do input and
> output relate?  Is input meaning packets entering both real interfaces
> eth0 and eth1 or does input mean to the virtual device br0.  If the
> latter what direction is input verses output, the order you add the
> NICs?  I don't see how this can be.

The bridging patch introduces the concept of physical interfaces.  If you
still have eth0 as the Internet interface, and eth1 as the lan interface,
but have them bridged by br0, then a packet from the Internet to the lan
has a physical input interface of eth0, an input interface of br0, a
physical ouput interface of eth1, and an output interface of br0. The -i
and -o matches will match either the physical or 'normal' interface.
So any of the following will match this packet: -i eth0, -i br0, -o eth1,
or -o br0.  The -i eth0 and -o eth1 matches will be the most useful.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com

RE: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[bmcdowell]

From my point of view, you can ignore physical/virtual interfaces with
respect to INPUT, OUTPUT, and FORWARD.  It's all about where the IP
address resides, and whether or not that IP is local or remote.  Let me
whip up a quick example.

Say we have a bridging firewall with two ethX interfaces and one brX
interface:

eth0-br0-eth1

Not that you would normally want to, but lets put IP's on all of these
interfaces:

eth0(10.10.10.1)-br0(10.10.10.2)-eth1(10.10.10.3)

Now lets add a few clients:

client1(10.10.10.5) -
[eth0(10.10.10.1)-br0(10.10.10.2)-eth1(10.10.10.3)] -
client2(10.10.10.6)

With me so far?

Now let's apply those to filter chains.  Examples:

	Situation				Chain (from the point of
view of the bridge)

Client1 pings Client2			FORWARD
Client2 pings Client1			FORWARD
Client1 pings 10.10.10.1		INPUT (and OUTPUT for the reply)
Client1 pings 10.10.10.2		INPUT (and OUTPUT for the reply)
Client1 pings 10.10.10.3		INPUT (and OUTPUT for the reply)
Client2 pings 10.10.10.1		Probably INPUT/OUTPUT - not sure
here

It isn't recommended to have IP's on ethX's.  Really, my bridge should
look more like this:

eth0(0.0.0.0)-br0(10.10.10.2)-eth1(0.0.0.0)

In this case, only traffic dealing with 10.10.10.2 would be handled by
the INPUT/OUTPUT chains.  Everything else is FORWARD, because it deals
with two non-local IPs.

Have I confused you yet?


Bob

-----Original Message-----
From: Kirk Reiser [mailto:kirk@braille.uwo.ca]
Sent: Wednesday, January 21, 2004 10:35 AM
To: Bob McDowell
Cc: netfilter@lists.netfilter.org
Subject: Re: netfiltering and ethernet bridging doesn't appear to work
as advertised, help!

<SNIP>
I'm having a bit of trouble with this statement because to me it
doesn't seem to make sense without the notion of the interface cards.
If eth0 is our interface to the net and eth1 our interface to the lan
then input to an interface makes sense because input to eth0 means one
set of rules while input to eth1 means a totally separate set.  When
you are talking about a virtual interface such as br0 how do input and
output relate?  Is input meaning packets entering both real interfaces
eth0 and eth1 or does input mean to the virtual device br0.  If the
latter what direction is input verses output, the order you add the
NICs?  I don't see how this can be.
<SNIP>

Re: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[Kirk Reiser]

<bmcdowell@coxhealthplans.com> writes:

> I can attest that it does work.  Hang in there.

Good! that means it's a documentation misunderstanding thank you.

> As for patching, it is my understanding that the statement about 'newer
> kernels' is only half right.  You do not need to patch your kernel to
> add bridging functionality (just enable it in the menu).  You DO need to
> patch it if you want to use netfilter to filter said bridge traffic.  I
> use this patch:
> http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.
> 4.19.diff

Right and on 2.4.24 for the bennefit of anyone else reading
net/core/skbuff.c and include/linux/skbuff.h the patches fail and need
to be patched by hand.  The structure physin_dev also needs to be
added to the .h file because it isn't there in the diff.

> To clarify a tad on the chains, INPUT and OUTPUT refer to traffic for
> and from the firewall itself.  FORWARD refers to traffic crossing the
> firewall.  These are two separate things and the rules do not effect
> chains they aren't applied to.  For example, your rule...

I'm having a bit of trouble with this statement because to me it
doesn't seem to make sense without the notion of the interface cards.
If eth0 is our interface to the net and eth1 our interface to the lan
then input to an interface makes sense because input to eth0 means one
set of rules while input to eth1 means a totally separate set.  When
you are talking about a virtual interface such as br0 how do input and
output relate?  Is input meaning packets entering both real interfaces
eth0 and eth1 or does input mean to the virtual device br0.  If the
latter what direction is input verses output, the order you add the
NICs?  I don't see how this can be.

> ...needs a FORWARD counterpart (if you also want that behavior on
> traffic crossing the firewall):
>
> 	iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
> ACCEPT -v

Auh, right.  I missed that point.

> Also your policy on FORWARD is accept.  Your post didn't show any
> FORWARD drop rules, so if traffic is passing right through the firewall
> with these rules, well, it's working correctly.  On the other hand, if
> you switch them all to FORWARD then there is no filtering on traffic to
> the firewall.

My whole problem with this stuff is I get predictable results on the
connections to the firewall box but not across it to the lan or
external net.  Which will probably clear up once I have this
interface/input/output point straight in my mind.

> Hope that helps.

A greate deal so far thank you once again.

  Kirk

RE: netfiltering and ethernet bridging doesn't appear to work as advertised, help!

[bmcdowell]

I can attest that it does work.  Hang in there.

As for patching, it is my understanding that the statement about 'newer
kernels' is only half right.  You do not need to patch your kernel to
add bridging functionality (just enable it in the menu).  You DO need to
patch it if you want to use netfilter to filter said bridge traffic.  I
use this patch:
http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.
4.19.diff

With only that patch, I have successfully enabled bridges netfilter
under both RedHat 7.3 and 9.

To clarify a tad on the chains, INPUT and OUTPUT refer to traffic for
and from the firewall itself.  FORWARD refers to traffic crossing the
firewall.  These are two separate things and the rules do not effect
chains they aren't applied to.  For example, your rule...

	iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-v

...needs a FORWARD counterpart (if you also want that behavior on
traffic crossing the firewall):

	iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
ACCEPT -v

Also your policy on FORWARD is accept.  Your post didn't show any
FORWARD drop rules, so if traffic is passing right through the firewall
with these rules, well, it's working correctly.  On the other hand, if
you switch them all to FORWARD then there is no filtering on traffic to
the firewall.

Hope that helps.


Bob