All of lore.kernel.org
 help / color / mirror / Atom feed
* iptables not possible to respond on request which comes from ebtables
@ 2016-07-15 21:31 marko.rakamaric
  2016-07-16  7:37 ` Pascal Hambourg
  0 siblings, 1 reply; 2+ messages in thread
From: marko.rakamaric @ 2016-07-15 21:31 UTC (permalink / raw)
  To: netfilter

Hello guys, hope someone can help me here. 

I have one device, with two physical nics in it. Those nic's eth0 and eth1 are enslaved in one logical bridge interface br0.

My goal here is to have L2 filtering based on MAC source, at the same time no meter if MAC is blacklisted or not always allow access
to 192.168.1.1, which is box itself.

Things should work like this:

pc: 192.168.1.44
br0: 192.168.1.1

When device receive frame, ebtables will trigger broute table, specifically BROUTING chain, and check if destination frame has
IP 192.168.1.1, if this is true it should allow traffic to this IP. if it is not true then it should trigger ebtables nat PREROUTING
chain, and check if frame has src MAC address XX:XX:XX:XX:XX:XX, if it matches DROP it. 

When frame is received and destination is 192.168.1.1 it will be passed to higher network layers, thus iptables will 
be in-charge for packet decisions. This is perfectly fine. 

At this stage, passing ebtables ipv4 traffic if destination is 192.168.1.1 works but only in 1 way. When iptables receive
packet in INPUT chain i am not able to forward it to 192.168.1.1 which is box itself, so even simple ICMP doesn't work. 

Looking at the logs, I am able to see perfectly fine made decisions, packet counter is incremented thus INPUT chain have's it. Afterward 
OUTPUT chain should return response to requested src which is 192.168.1.44. Unfortunately this response never arrives back to request 
host. 

I have also tried to set all relevant default policies to ACCEPT, but result is same. 

Here are iptable INPUT  logs: 
IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21871 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=12 
IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21959 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=13 
IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21984 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=14 

Here are iptable OUTPUT logs: 
IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62294 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=481 
IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62378 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=482 
IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62462 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=483

Here are commands which I am using: 

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
brctl stp br0 off 

ip addr flush dev eth1
ip addr flush dev eth0
ip link set dev br0 up
ip addr add 192.168.1.1 dev br0

echo 1 > /proc/sys/net/ipv4/ip_forward

# broute BROUTING (ACCEPT):
ebtables -t broute -A BROUTING -p IPv4 --logical-in br0 --ip-dst 192.168.1.1 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -p ARP --logical-in br0 --arp-ip-dst 192.168.1.1 -j redirect --redirect-target DROP

# nat PREROUTING (ACCEPT):
ebtables -t nat -s XX:XX:XX:XX:XX:XX -j DROP
ebtables -t nat -s XX:XX:XX:XX:XX:XX -j DROP
ebtables -t nat -s XX:XX:XX:XX:XX:XX -j DROP

iptables: 
# INPUT (ACCEPT-only for testing)
iptables -I INPUT -i br0 -d 192.168.1.1 -j ACCEPT

# FORWARD(ACCEPT):

# OUTPUT(ACCEPT):
iptables -I OUTPUT -o br0 -j ACCEPT

Any hint, I would really appreciate!

Best regards!

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

* Re: iptables not possible to respond on request which comes from ebtables
  2016-07-15 21:31 iptables not possible to respond on request which comes from ebtables marko.rakamaric
@ 2016-07-16  7:37 ` Pascal Hambourg
  0 siblings, 0 replies; 2+ messages in thread
From: Pascal Hambourg @ 2016-07-16  7:37 UTC (permalink / raw)
  To: marko.rakamaric; +Cc: netfilter

Le 15/07/2016 à 23:31, marko.rakamaric@gmail.com a écrit :
>
> Here are iptable INPUT  logs:
> IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21871 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=12
> IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21959 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=13
> IPTIN=eth1 OUT= MAC=14:ea:31:1e:00:e1:20:1c:8a:b2:ef:85:08:00 SRC=192.168.1.44 DST=192.168.1.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=21984 DF PROTO=ICMP TYPE=8 CODE=0 ID=4104 SEQ=14
>
> Here are iptable OUTPUT logs:
> IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62294 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=481
> IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62378 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=482
> IPTIN= OUT=br0 SRC=192.168.1.1 DST=192.168.1.44 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=62462 PROTO=ICMP TYPE=0 CODE=0 ID=29857 SEQ=483

These INPUT and OUTPUT logs don't match. The ICMP ID and sequence 
numbers are different. So I guess they were captured at different times.

> # broute BROUTING (ACCEPT):
> ebtables -t broute -A BROUTING -p IPv4 --logical-in br0 --ip-dst 192.168.1.1 -j redirect --redirect-target DROP
> ebtables -t broute -A BROUTING -p ARP --logical-in br0 --arp-ip-dst 192.168.1.1 -j redirect --redirect-target DROP

May I ask what is the purpose of this strange setup ?
If the original destination is the bridging box itself, then you don't 
need to do all this mangling.

> iptables:
> # INPUT (ACCEPT-only for testing)
> iptables -I INPUT -i br0 -d 192.168.1.1 -j ACCEPT

Note that the broute target causes the input interface to be the bridge 
port (eth1) instead of the bridge (br0), as can be seen in the INPUT log.
So you must accept packets on this interface too.
Also you may need to check that /proc/sys/ipv4/conf/eth1/rp_filter is 
set to 0 to disable source address validation which expects packets from 
192.168.1.44 to be received on br0, not eth1 (iptables does not know 
about bridging).

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

end of thread, other threads:[~2016-07-16  7:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-15 21:31 iptables not possible to respond on request which comes from ebtables marko.rakamaric
2016-07-16  7:37 ` Pascal Hambourg

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.