All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Trouble redirecting traffic on transparent bridge.
@ 2005-12-02 13:49 Kran Kor
  2005-12-02 20:12 ` Carl-Daniel Hailfinger
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Kran Kor @ 2005-12-02 13:49 UTC (permalink / raw)
  To: lartc

I have posted this question to the netfilter mailing list along with #ebtables, #iptables, and #netfilter.  Nobody has really responded, so I'm led to believe  
that it is either incredibly complicated or *really* simple.  Please, somebody throw me a bone here!  Ok, on with the show...  
  
  
I have a bridge (br0) with two interfaces (eth1 and eth2).  Neither br0, eth1, or eth2 have an IP address assigned to them.  Eth0 is the only interface with an   
IP.  There is a web server running locally on this bridge configured so that any request sent to it returs the only page.  I'm trying to get all web traffic (port   
80 for now) from certain clients transparently redirected to the local web server.  Basically I want to take traffic from a client matching virii/malware traffic   
and redirect it to a web page that has instructions for disinfection/cleaning.  Also I want to isolate any infected clients traffic to only one side of the   
bridge.  I want to keep these bridges as "transparent" as possible.   
   
Here's what I have tried so far:   
   
# netstat -ln   
Active Internet connections (only servers)   
Proto Recv-Q Send-Q Local Address           Foreign Address         State         
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN   
   
# route -n   
Kernel IP routing table   
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   
172.16.110.0    0.0.0.0         255.255.254.0   U     0      0        0 eth0   
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo   
0.0.0.0         172.16.111.254  0.0.0.0         UG    1      0        0 eth0   
   
   
From filter:   
-A FORWARD -p udp -m udp --dport 53 -j ACCEPT    
-A FORWARD -p udp -m udp --sport 53 -j ACCEPT    
-A FORWARD -p tcp -m tcp --dport 53 -j ACCEPT    
-A FORWARD -p tcp -m tcp --sport 53 -j ACCEPT    
-A FORWARD -s $CLIENT_IP -j DROP    
-A icmp-flood -m limit --limit 1/sec -j RETURN    
-A icmp-flood -j DROP    
-A syn-flood -m limit --limit 50/sec --limit-burst 150 -j RETURN    
-A syn-flood -j DROP   
   
From nat:   
-A PREROUTING -s $CLIENT_IP -p tcp -m tcp --dport 80 -j DNAT --to-destination 127.0.0.1:80   
   
Using the DNAT rule above the traffic can be seen on lo:   
15:09:21.474893 IP 172.16.110.139.1782 > 127.0.0.1.80: S 1919280507:1919280507(0) win 65535 <mss 1460,nop,nop,sackOK>   
15:09:24.427208 IP 172.16.110.139.1782 > 127.0.0.1.80: S 1919280507:1919280507(0) win 65535 <mss 1460,nop,nop,sackOK>   
   
As seen from the client side bridge interface eth2:   
15:09:21.474843 IP 172.16.110.139.1782 > 216.193.202.92.80: S 1919280507:1919280507(0) win 65535 <mss 1460,nop,nop,sackOK>   
15:09:24.427183 IP 172.16.110.139.1782 > 216.193.202.92.80: S 1919280507:1919280507(0) win 65535 <mss 1460,nop,nop,sackOK>   
   
But the kernel sees the traffic as "martian" and disards them:   
Dec  1 15:09:45 xxxxxxxx last message repeated 9 times   
Dec  1 15:11:37 xxxxxxxx kernel: martian destination 127.0.0.1 from 172.16.110.139, dev br0   
Dec  1 15:11:46 xxxxxxxx last message repeated 2 times   
   
Ok, that isn't what I want to see... so I tried using a REDIRECT rule in place of the DNAT rule:   
iptables -t nat -A PREROUTING -p tcp -s 172.16.110.139 --dport 80 -j REDIRECT --to-ports 80   
   
Now the only interface I can see the clients web traffic on is eth2 (the interface on the bridge facing the client).   
tcpdump on eth2:   
15:19:29.280597 IP 172.16.110.139.1791 > 216.193.202.92.80: S 3561515512:3561515512(0) win 65535 <mss 1460,nop,nop,sackOK>   
   
Eth1, br0, and lo don't see any of it, nothing in kernel or apache logs either.  Where is it getting redirected to??   
   
I have tried using 2.6.13, 2.6.14, 2.6.14.3, and 2.6.15-rc4, also tried iptables-1.3.3 and 1.3.4.   
   
Any ideas on what I am doing wrong? What is the correct way to do this?   
   
Thanks in advance.  

-- 
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] Trouble redirecting traffic on transparent bridge.
  2005-12-02 13:49 [LARTC] Trouble redirecting traffic on transparent bridge Kran Kor
@ 2005-12-02 20:12 ` Carl-Daniel Hailfinger
  2005-12-03 15:35 ` Jeffrey B. Ferland
  2005-12-05 15:27 ` Kran Kor
  2 siblings, 0 replies; 4+ messages in thread
From: Carl-Daniel Hailfinger @ 2005-12-02 20:12 UTC (permalink / raw)
  To: lartc

Hi,

Kran Kor schrieb:
> I have posted this question to the netfilter mailing list along with
 > #ebtables, #iptables, and #netfilter.  Nobody has really responded,
 > so I'm led to believe that it is either incredibly complicated or
 > *really* simple.  Please, somebody throw me a bone here!  Ok, on with
 > the show...
>   
> I have a bridge (br0) with two interfaces (eth1 and eth2).  Neither
 > br0, eth1, or eth2 have an IP address assigned to them.  Eth0 is the
 > only interface with an IP.  There is a web server running locally on
 > this bridge configured so that any request sent to it returs the only
 > page.  I'm trying to get all web traffic (port 80 for now) from
 > certain clients transparently redirected to the local web server.
 > Basically I want to take traffic from a client matching virii/malware
 > traffic and redirect it to a web page that has instructions for
 > disinfection/cleaning. Also I want to isolate any infected clients
 > traffic to only one side of the bridge.  I want to keep these bridges
 > as "transparent" as possible.

Linux can't do this.

If you doubt the sentence above, prove me wrong.

I tried the same, even got some help from lartc and ebtables and it
still didn't work. Technically, there is no reason why it can't work,
but in reality it fails.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] Trouble redirecting traffic on transparent bridge.
  2005-12-02 13:49 [LARTC] Trouble redirecting traffic on transparent bridge Kran Kor
  2005-12-02 20:12 ` Carl-Daniel Hailfinger
@ 2005-12-03 15:35 ` Jeffrey B. Ferland
  2005-12-05 15:27 ` Kran Kor
  2 siblings, 0 replies; 4+ messages in thread
From: Jeffrey B. Ferland @ 2005-12-03 15:35 UTC (permalink / raw)
  To: lartc

<Lots of snippage>
>
>> From nat:
> -A PREROUTING -s $CLIENT_IP -p tcp -m tcp --dport 80 -j DNAT --to- 
> destination 127.0.0.1:80
>
> But the kernel sees the traffic as "martian" and disards them:
> Dec  1 15:09:45 xxxxxxxx last message repeated 9 times
> Dec  1 15:11:37 xxxxxxxx kernel: martian destination 127.0.0.1 from  
> 172.16.110.139, dev br0
> Dec  1 15:11:46 xxxxxxxx last message repeated 2 times
>

The above part is what really matters... you can't with a source  
address of 127.0.0.1 to any other host.

If you're so inclined, the source code making this check is  
apparently in route.c

Give br0 an IP address, and redirect to that address. (eth1 and eth2  
as part of a bridge don't get ips)

-Jeff
SIG: HUP
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [LARTC] Trouble redirecting traffic on transparent bridge.
  2005-12-02 13:49 [LARTC] Trouble redirecting traffic on transparent bridge Kran Kor
  2005-12-02 20:12 ` Carl-Daniel Hailfinger
  2005-12-03 15:35 ` Jeffrey B. Ferland
@ 2005-12-05 15:27 ` Kran Kor
  2 siblings, 0 replies; 4+ messages in thread
From: Kran Kor @ 2005-12-05 15:27 UTC (permalink / raw)
  To: lartc

Ok I gave br0 an IP.  Now I have a new problem.  When the client tries to access a webserver the traffic redirected to the ip on the bridge to the local web server.  However, the traffic going back to the client machine from the web server has a source port of 1, this isn't what the client expects so it rejects it.  Here's a tethereal dump of eth2, the interface on the bridge between the client and the bridge:

172.16.110.139 is client, 64.233.187.104 is google.com

 10.841477 172.16.110.139 -> 64.233.187.104 TCP 2684 > http [FIN, ACK] Seq=0 Ack=0 Wine535 Len=0
 10.841661 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2684 [ACK] Seq=0 Ack=0 Wind32 Len=0
 10.841853 172.16.110.139 -> 64.233.187.104 TCP 2684 > tcpmux [RST] Seq=0 Ack'30207901 Win=0 Len=0
 10.844408 64.233.187.104 -> 172.16.110.139 TCP [TCP ACKed lost segment] http > 2684 [RST, ACK] Seq'30208227 Ack=2 Win=0 Len=0
 10.868209 172.16.110.139 -> 64.233.187.104 TCP 2685 > http [SYN] Seq=0 Ack=0 Wine535 Len=0 MSS\x1460
 10.868384 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [SYN, ACK] Seq=0 Ack=1 WinX40 Len=0 MSS\x1460
 10.868584 172.16.110.139 -> 64.233.187.104 TCP 2685 > http [ACK] Seq=1 Ack=1 Wine535 Len=0
 10.881201 172.16.110.139 -> 64.233.187.104 HTTP GET /index.html HTTP/1.1
 10.881635 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2685 [ACK] Seq=0 Ack=0 Wind32 Len=0
 10.881824 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 10.882135 64.233.187.104 -> 172.16.110.139 TCP tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Wind32 Len25
 10.882324 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 10.883252 64.233.187.104 -> 172.16.110.139 TCP [TCP ACKed lost segment] [TCP Previous segment lost] http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0
 10.883268 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0
 13.851777 172.16.110.139 -> 64.233.187.104 HTTP [TCP ZeroWindowViolation] [TCP Out-Of-Order] GET /index.html HTTP/1.1
 13.852239 64.233.187.104 -> 172.16.110.139 TCP [TCP Dup ACK 11#1] tcpmux > 2685 [ACK] Seq25 Ack=0 Wind32 Len=0 SLEB94966807 SRE=0
 13.852403 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 13.853102 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0
 13.881844 64.233.187.104 -> 172.16.110.139 TCP [TCP Retransmission] tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Wind32 Len25
 13.882009 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 13.882705 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0
 19.859637 172.16.110.139 -> 64.233.187.104 HTTP [TCP ZeroWindowViolation] [TCP Out-Of-Order] GET /index.html HTTP/1.1
 19.860007 64.233.187.104 -> 172.16.110.139 TCP [TCP Dup ACK 11#2] tcpmux > 2685 [ACK] Seq25 Ack=0 Wind32 Len=0 SLEB94966807 SRE=0
 19.860139 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 19.860874 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0
 19.882250 64.233.187.104 -> 172.16.110.139 TCP [TCP Retransmission] tcpmux > 2685 [PSH, ACK] Seq=0 Ack=0 Wind32 Len25
 19.882496 172.16.110.139 -> 64.233.187.104 TCP 2685 > tcpmux [RST] Seq=0 AckV2108981 Win=0 Len=0
 19.883111 64.233.187.104 -> 172.16.110.139 TCP http > 2685 [RST, ACK] SeqV2108982 AckI1 Win=0 Len=0

#ip route
192.168.200.0/24 dev br0  proto kernel  scope link  src 192.168.200.1 
172.16.110.0/23 dev eth0  proto kernel  scope link  src 172.16.110.150 
127.0.0.0/8 dev lo  scope link 
default via 172.16.111.254 dev eth0  metric 1

# iptables -n -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination          
DNAT       all  --  172.16.110.139       64.233.187.104      to:192.168.200.1 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  192.168.200.1        172.16.110.139      to:64.233.187.104 
 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Any ideas on what's going on?  Why would the source port change?

----- Original Message -----
From: "Jeffrey B. Ferland" <jeff@storyinmemo.com>
To: "Kran Kor" <krankor@linuxmail.org>
Subject: Re: [LARTC] Trouble redirecting traffic on transparent bridge.
Date: Sat, 3 Dec 2005 10:35:06 -0500

> 
> <Lots of snippage>
> >
> >> From nat:
> > -A PREROUTING -s $CLIENT_IP -p tcp -m tcp --dport 80 -j DNAT 
> > --to- destination 127.0.0.1:80
> >
> > But the kernel sees the traffic as "martian" and disards them:
> > Dec  1 15:09:45 xxxxxxxx last message repeated 9 times
> > Dec  1 15:11:37 xxxxxxxx kernel: martian destination 127.0.0.1 
> > from  172.16.110.139, dev br0
> > Dec  1 15:11:46 xxxxxxxx last message repeated 2 times
> >
> 
> The above part is what really matters... you can't with a source  
> address of 127.0.0.1 to any other host.
> 
> If you're so inclined, the source code making this check is  
> apparently in route.c
> 
> Give br0 an IP address, and redirect to that address. (eth1 and 
> eth2  as part of a bridge don't get ips)
> 
> -Jeff
> SIG: HUP


-- 
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-12-05 15:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-02 13:49 [LARTC] Trouble redirecting traffic on transparent bridge Kran Kor
2005-12-02 20:12 ` Carl-Daniel Hailfinger
2005-12-03 15:35 ` Jeffrey B. Ferland
2005-12-05 15:27 ` Kran Kor

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.