* [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.