* Reject on a Bridge
@ 2008-09-03 22:41 Gilad Benjamini
2008-09-04 16:18 ` Grant Taylor
2008-09-15 8:03 ` Gilad Benjamini
0 siblings, 2 replies; 4+ messages in thread
From: Gilad Benjamini @ 2008-09-03 22:41 UTC (permalink / raw)
To: netfilter
I am using iptables to run a firewall on a bridge.
The bridge consists of eth1 and eth2. Neither interface, nor the
bridge itself, have an IP address.
eth0, which is not on the bridge, does have an IP address.
Trying to use the REJECT target with --tcp-reset doesn't work.
If I understand the code correctly, the route for the RST packet is
determined through ip_route_me_harder in the send_reset function,
implying in my case that the RST packet will leave through eth0, which
is not the desired behavior. Theoretically, eth0 might be even
physically disconnected from the bridged network.
Am I missing something, or is this a real problem ?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reject on a Bridge
2008-09-03 22:41 Reject on a Bridge Gilad Benjamini
@ 2008-09-04 16:18 ` Grant Taylor
2008-09-04 16:44 ` billycrook
2008-09-15 8:03 ` Gilad Benjamini
1 sibling, 1 reply; 4+ messages in thread
From: Grant Taylor @ 2008-09-04 16:18 UTC (permalink / raw)
To: Mail List - Netfilter
On 09/03/08 17:41, Gilad Benjamini wrote:
> I am using iptables to run a firewall on a bridge. The bridge
> consists of eth1 and eth2. Neither interface, nor the bridge itself,
> have an IP address. eth0, which is not on the bridge, does have an IP
> address.
>
> Trying to use the REJECT target with --tcp-reset doesn't work. If I
> understand the code correctly, the route for the RST packet is
> determined through ip_route_me_harder in the send_reset function,
> implying in my case that the RST packet will leave through eth0,
> which is not the desired behavior. Theoretically, eth0 might be even
> physically disconnected from the bridged network.
>
> Am I missing something, or is this a real problem ?
I'm not sure where the rejection is going to come from. At least as I
understand it the rejection comes from a system (with an IP) in the path
that is refusing to pass the packet. Thus I don't see how the bridge
can reject the packet because there is no source IP to send the
rejection from. Can you add an IP to the bridge interface that is with
in the subnet that is being bridged through it so that there is a source
IP for the rejection?
Grant. . . .
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reject on a Bridge
2008-09-04 16:18 ` Grant Taylor
@ 2008-09-04 16:44 ` billycrook
0 siblings, 0 replies; 4+ messages in thread
From: billycrook @ 2008-09-04 16:44 UTC (permalink / raw)
To: Grant Taylor; +Cc: Mail List - Netfilter
On 2008-09-04, Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 09/03/08 17:41, Gilad Benjamini wrote:
>> I am using iptables to run a firewall on a bridge. The bridge
>> consists of eth1 and eth2. Neither interface, nor the bridge itself,
>> have an IP address. eth0, which is not on the bridge, does have an IP
>> address.
>>
>> Am I missing something, or is this a real problem ?
>
> I'm not sure where the rejection is going to come from. At least as I
> understand it the rejection comes from a system (with an IP) in the path
> that is refusing to pass the packet. Thus I don't see how the bridge
> can reject the packet because there is no source IP to send the
> rejection from. Can you add an IP to the bridge interface that is with
> in the subnet that is being bridged through it so that there is a source
> IP for the rejection?
That does make it pretty clear. Rejecting an IP packet is done with
another IP packet. Packets have to come from a layer-3 interface, of
a machine with an IP, so it doesn't make sense that an interface
that's not participating in IP itself could send a
ICMP-host-prohibited message if it doesn't have an IP from which to
send the message.
I understand you want to reject with an RST packet, but that packet
still has to come from somewhere. It sounds like you want the rule to
fabricate an RST packet from the intended recipient of whatever you're
blocking. I doubt the kernel will send any packets (let alone forged
ones) from an interface where IP is not bound.
Perhaps an easier solution would be to just DROP the unwanted traffic,
rather than REJECT.
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Reject on a Bridge
2008-09-03 22:41 Reject on a Bridge Gilad Benjamini
2008-09-04 16:18 ` Grant Taylor
@ 2008-09-15 8:03 ` Gilad Benjamini
1 sibling, 0 replies; 4+ messages in thread
From: Gilad Benjamini @ 2008-09-15 8:03 UTC (permalink / raw)
To: netfilter
Following the replies I got I understand this is not supported by the code.
I played around with the code and was able to make this work in some
scenarios but not in others.
If I understand correctly, my main obstacle is the call to
ip_route_me_harder, which is completely wrong for my case, as no routing is
involved.
Anyone has an idea for a simple patch that might solve this ?
In case I wasn't clear, the idea is simple; on the bridge, fake a RST packet
as if it came from the destination of the original packet.
Thanks for any help
-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of Gilad Benjamini
Sent: Wednesday, September 03, 2008 3:41 PM
To: netfilter@vger.kernel.org
Subject: Reject on a Bridge
I am using iptables to run a firewall on a bridge.
The bridge consists of eth1 and eth2. Neither interface, nor the
bridge itself, have an IP address.
eth0, which is not on the bridge, does have an IP address.
Trying to use the REJECT target with --tcp-reset doesn't work.
If I understand the code correctly, the route for the RST packet is
determined through ip_route_me_harder in the send_reset function,
implying in my case that the RST packet will leave through eth0, which
is not the desired behavior. Theoretically, eth0 might be even
physically disconnected from the bridged network.
Am I missing something, or is this a real problem ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-09-15 8:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-03 22:41 Reject on a Bridge Gilad Benjamini
2008-09-04 16:18 ` Grant Taylor
2008-09-04 16:44 ` billycrook
2008-09-15 8:03 ` Gilad Benjamini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox