ebtables-user — Questions on the usage of ebtables.

[Ebtables-user] query on ebtables filter table error

[SIMON B. <sim...@gm...>]

Hi,
I am new to this team. I have a query on below error when I execute
ebtables on my linux embedded device.

root@wglng-2:/usr/lib32# ebtables-legacy -t filter -A FORWARD -i eth6 -p
802_1Q --vlan-encap 0x888e -j ACCEPT

*The kernel doesn't support the ebtables 'filter' table.*

Is there any patch or configuration settings available to fix this issue?

Regards
Simon

[Ebtables-user] ebtables - filter bpdutcn/bpdutcn-ack

[elektrokat <ele...@pr...>]

I'm not finding a lot of verbage for ebtables and have a super newb question on its use. i'm experimenting with the prevention of an stp attack. I really hope you don't mind....

I am running a debain VM in bridge mode and want to inspect the STP bpdu frames tcn/tcn ack and forward/ignore anything else.

I have this:
ebtables -p LENGTH -d BGA --stp-type 1,128 -j FORWARD

[Ebtables-user] ebtables rule to redirect MPLS tagged packets

[<ars...@sc...>]

Hi,I am using linux transparent bridge and ebtables rules to filter traffic.I did't find any rule to match MPLS tagged traffic.I just want to redirect MPLS tagged traffic to the kernel.please help me out,thnx 

[Ebtables-user] AP isolation

[Manjunath <man...@fi...>]

Hi All,

       Iam using ebtables ( ebtables v2.0.8-2 (May 2007) ) in my wifi
router. My wifi router is equipped with 2 radio ( 5 & 2.4 GHz ). Both radios
have multiple SSID's enabled. I would like to isolate the virtual AP's, that
is client connected to one SSID should not be able to see clients on another
SSID. With the current ebtables clients on one SSID can ping other clients
but not clients on same SSID.

     

Scenario as below: 

1)      WLAN0 - 5GHz

2)      WLAN1 - 2.4GHz 

                    Enabled 4 virtual AP's under WLAN1, so their interfaces
are

                 Wlan1-vap0    - SSID1

                 Wlan1-vap1    - SSID2

                 Wlan1-vap2    - SSID3

                 Wlan1-vap3    - SSID4

   Now with current ebtables clients connected to same SSID cannot ping each
other, but clients connected to different SSID can ping. ( Client isolation
)

I would like to have a setting where clients connected to same SSID should
ping, but clients connected to different SSID should not ping (AP isolation
)

    

  How to achieve AP isolation rather than client isolation.

 

 

Thanks & Best Regards,

Manjunath M N

[Ebtables-user] ebtables for traffic shaping over bridge

[Surabhi G. <sgo...@cd...>]

Hi,

I am using kernel version: 3.10.0 and ebtables v2.0.10-4, my laptop is connected to eth1
interface that is a part of the bridge and I wish to restrict traffic to my laptop,
can someone be so kind as to give me a set of commands to implement this as I am very
new to this field.
I have tried traffic shaping using TC by creating filter and then marking the packets
based on mac address, but this does not work in bridge mode.

Kindly tell me how to do this using ebtables with my interface eth1 in bridge mode.


Thanks in advance!

Re: [Ebtables-user] "Hiding" a "chatty" bridge link

[Cunningham, R. <RCu...@ns...>]

Do you know of an up-to-date "paint by numbers" complete example or tutorial for l2tp3?  My initial searches found recipes that are missing various parts (such as rules for MTU management), or use legacy tools instead of the "ip" command (I'd like to be 'future-proof' to simplify maintenance, if the "ip" command is up to it).  And the top-level documentation (http://man7.org/linux/man-pages/man8/ip-l2tp.8.html ) is somewhat opaque to me as a first-time user.

After the l2tpv3 tunnel is up, what is the best way to temporarily bring up ssh on the same physical eth0 interface?  Is it as simple as adding and removing the IP address on eth0 and restarting ssh?  (ssh should always be available on eth1.)  Can I be sure that all other traffic arriving at eth0 will still go through the tunnel?

The tunnel and proxy don't (yet) need any security (authentication or encryption), since the RF link itself is fully encrypted and the LAN segments are physically isolated (and would be DMZ'ed if connected to the corporate LAN/WAN).  Plus, the ARM chips and NICs don't appear to have onboard encryption engines (or they lack drivers) to offload the CPU (latency and throughput hit).  Access to the ARM board logins would be only over encrypted links (ssh).

I'm also thinking it could be convenient to occasionally use the ARM boards as part of my test environment, such as to run Wireshark or iperf.  Any issues I should be aware of?  Or would it be better not to?

Thanks!

-BobC


From: Fernando Rodriguez [mailto:fr...@ai...]
Sent: Wednesday, June 11, 2014 6:37 AM
To: Cunningham, Robert
Cc: ebt...@li...
Subject: Re: [Ebtables-user] "Hiding" a "chatty" bridge link

Hello,






1.- Layer 2 tunnel

You can do a Layer 2 tunnel to pass the traffic from one side to the other transparently read on l2tpv3 this will work as if you where directly connected to the other side of the network.


2.- A simple proxy.

You can use a ssh to create a proxy to the lan of the equipment you want to monitor so if the equipment is on lan B you can ssh -D and make a tunnel as if you where ARM B so you can read the traffic directly.



On Jun 10, 2014, at 10:30 AM, Cunningham, Robert <RCu...@ns...<mailto:RCu...@ns...>> wrote:


Hi,

I have a test LAN that I needed to extend to another building, so I got a point-to-point RF link (non-WiFi) that does the job nicely.  Unfortunately, that link generates lots of miscellaneous traffic (STP, ARP, etc.) and also hosts a web-based management interface on each end that I can't disable (though I can set its address, but not the port).   I like my test LAN to be very, very clean: I mainly use it to Wireshark various instrumentation products (networked sensors and data relays) to check for correct data packet content, spurious traffic, and to gather traffic stats under various operational conditions.   Devices under test may use any valid IPv4 address, and the test LAN presently has no direct connection to a WAN or any other company LAN (but it may in the future).

I thought it would be a "simple" task to take a pair of ARM-Ubuntu boards I had available (similar to Beagle/Panda, running 12.04 LTS) and put one between each end of the RF link and the test LAN to hide the chatter.  But for the life of me I can't come up with a workable configuration.  I've fallen into ebtables and I can't get up!

Here's the hardware picture:
                  |- ARM-A -|    |- RF-A -|    |- RF-B -|    |- ARM-B -|
Local Test LAN -- eth0   eth1 -- wired   RF -- RF   wired -- eth1   eth0 -- Remote Test LAN

My goal is to make the two eth0 interfaces be transparent, like a cable or a 2-port switch: Packets arriving on one eth0 depart on the other, and vice-versa.  ARP requests (and all other non-IP traffic) are passed cleanly through.  All traffic originated by RF-A and RF-B is dropped before exiting either eth0.  Neither eth0 will have an IP address.  There should be no need for STP.  If possible, I'd even like the MAC addresses to be unchanged by the link (so I don't have to think too hard while using Wireshark).

But I would like the RF management interfaces to be visible within the ARM boards (e.g., if I add another interface via USB).  So I don't want to drop their packets on ingress to eth1, but certainly not let them egress eth0.  I'd also like to be able to be able temporarily expose an SSH interface for each ARM board on eth0 to make board configuration easier (and always have SSH on eth1, so I can configure over the RF link).

Here's my progress so far (though it may only show my ignorance).  The addressing can be anything it needs to be.

ARM-A:
  eth0 ---- br0 ------- dummy0 --------- gre0                      eth1
(no IP)   (no IP)  (192.168.1.254/24)   (to ARM-B: 192.168.2.254)  (172.10.10.10)

ARM-B:
  eth0 ---- br0 ------- dummy0 -------- gre0                       eth1
(no IP)   (no IP)  (192.168.2.254/24)   (to ARM-A: 192.168.1.245)  (172.10.10.11)

To provide temporary access to services on eth0, I'm thinking I could dynamically create eth0:0 with an IP address, then delete it when no longer needed.  But will it interfere with the passing of all other traffic over the tunnel?

I haven't yet been able to get a ping through the link, and I am way too ashamed to share the tangled mess of buggy ebtables rules I've been trying to write (I'm certain I'm putting bad rules into the wrong tables, etc.).

Any clues to get me going in the right direction?  I can't imagine that this kind of "device wrapping and tunneling" is all that rare, but many net searches have failed to turn up relevant examples (or examples I understood to be relevant), and endless reading of the ebtables/iptables documentation has left me bleary-eyed.  Perhaps it's a vocabulary thing?  I'm obviously not any kind of network engineer (I mainly work with TCP/UDP payloads).

I've tried asking on various StackExchange forums, but with no responses so far.  Help?

TIA,

-BobC

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems_______________________________________________
Ebtables-user mailing list
Ebt...@li...<mailto:Ebt...@li...>
https://lists.sourceforge.net/lists/listinfo/ebtables-user

Re: [Ebtables-user] "Hiding" a "chatty" bridge link

[Fernando R. <fr...@ai...>]

Hello,



1.- Layer 2 tunnel

You can do a Layer 2 tunnel to pass the traffic from one side to the other transparently read on l2tpv3 this will work as if you where directly connected to the other side of the network.


2.- A simple proxy.

You can use a ssh to create a proxy to the lan of the equipment you want to monitor so if the equipment is on lan B you can ssh -D and make a tunnel as if you where ARM B so you can read the traffic directly.

 

On Jun 10, 2014, at 10:30 AM, Cunningham, Robert <RCu...@ns...> wrote:

> Hi,
>  
> I have a test LAN that I needed to extend to another building, so I got a point-to-point RF link (non-WiFi) that does the job nicely.  Unfortunately, that link generates lots of miscellaneous traffic (STP, ARP, etc.) and also hosts a web-based management interface on each end that I can’t disable (though I can set its address, but not the port).   I like my test LAN to be very, very clean: I mainly use it to Wireshark various instrumentation products (networked sensors and data relays) to check for correct data packet content, spurious traffic, and to gather traffic stats under various operational conditions.   Devices under test may use any valid IPv4 address, and the test LAN presently has no direct connection to a WAN or any other company LAN (but it may in the future).
>  
> I thought it would be a “simple” task to take a pair of ARM-Ubuntu boards I had available (similar to Beagle/Panda, running 12.04 LTS) and put one between each end of the RF link and the test LAN to hide the chatter.  But for the life of me I can’t come up with a workable configuration.  I’ve fallen into ebtables and I can’t get up!
>  
> Here’s the hardware picture:
>                   |- ARM-A -|    |- RF-A -|    |- RF-B -|    |- ARM-B -|
> Local Test LAN -- eth0   eth1 -- wired   RF -- RF   wired -- eth1   eth0 -– Remote Test LAN
>  
> My goal is to make the two eth0 interfaces be transparent, like a cable or a 2-port switch: Packets arriving on one eth0 depart on the other, and vice-versa.  ARP requests (and all other non-IP traffic) are passed cleanly through.  All traffic originated by RF-A and RF-B is dropped before exiting either eth0.  Neither eth0 will have an IP address.  There should be no need for STP.  If possible, I’d even like the MAC addresses to be unchanged by the link (so I don’t have to think too hard while using Wireshark).
>  
> But I would like the RF management interfaces to be visible within the ARM boards (e.g., if I add another interface via USB).  So I don’t want to drop their packets on ingress to eth1, but certainly not let them egress eth0.  I’d also like to be able to be able temporarily expose an SSH interface for each ARM board on eth0 to make board configuration easier (and always have SSH on eth1, so I can configure over the RF link).
>  
> Here’s my progress so far (though it may only show my ignorance).  The addressing can be anything it needs to be.
>  
> ARM-A:
>   eth0 ---- br0 ------- dummy0 --------- gre0                      eth1
> (no IP)   (no IP)  (192.168.1.254/24)   (to ARM-B: 192.168.2.254)  (172.10.10.10)
>  
> ARM-B:
>   eth0 ---- br0 ------- dummy0 -------- gre0                       eth1
> (no IP)   (no IP)  (192.168.2.254/24)   (to ARM-A: 192.168.1.245)  (172.10.10.11)
>  
> To provide temporary access to services on eth0, I’m thinking I could dynamically create eth0:0 with an IP address, then delete it when no longer needed.  But will it interfere with the passing of all other traffic over the tunnel?
>  
> I haven’t yet been able to get a ping through the link, and I am way too ashamed to share the tangled mess of buggy ebtables rules I’ve been trying to write (I’m certain I’m putting bad rules into the wrong tables, etc.).
>  
> Any clues to get me going in the right direction?  I can’t imagine that this kind of “device wrapping and tunneling” is all that rare, but many net searches have failed to turn up relevant examples (or examples I understood to be relevant), and endless reading of the ebtables/iptables documentation has left me bleary-eyed.  Perhaps it’s a vocabulary thing?  I’m obviously not any kind of network engineer (I mainly work with TCP/UDP payloads).
>  
> I’ve tried asking on various StackExchange forums, but with no responses so far.  Help?
>  
> TIA,
>  
> -BobC
>  
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems_______________________________________________
> Ebtables-user mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-user

[Ebtables-user] "Hiding" a "chatty" bridge link

[Cunningham, R. <RCu...@ns...>]

Hi,

I have a test LAN that I needed to extend to another building, so I got a point-to-point RF link (non-WiFi) that does the job nicely.  Unfortunately, that link generates lots of miscellaneous traffic (STP, ARP, etc.) and also hosts a web-based management interface on each end that I can't disable (though I can set its address, but not the port).   I like my test LAN to be very, very clean: I mainly use it to Wireshark various instrumentation products (networked sensors and data relays) to check for correct data packet content, spurious traffic, and to gather traffic stats under various operational conditions.   Devices under test may use any valid IPv4 address, and the test LAN presently has no direct connection to a WAN or any other company LAN (but it may in the future).

I thought it would be a "simple" task to take a pair of ARM-Ubuntu boards I had available (similar to Beagle/Panda, running 12.04 LTS) and put one between each end of the RF link and the test LAN to hide the chatter.  But for the life of me I can't come up with a workable configuration.  I've fallen into ebtables and I can't get up!

Here's the hardware picture:
                  |- ARM-A -|    |- RF-A -|    |- RF-B -|    |- ARM-B -|
Local Test LAN -- eth0   eth1 -- wired   RF -- RF   wired -- eth1   eth0 -- Remote Test LAN

My goal is to make the two eth0 interfaces be transparent, like a cable or a 2-port switch: Packets arriving on one eth0 depart on the other, and vice-versa.  ARP requests (and all other non-IP traffic) are passed cleanly through.  All traffic originated by RF-A and RF-B is dropped before exiting either eth0.  Neither eth0 will have an IP address.  There should be no need for STP.  If possible, I'd even like the MAC addresses to be unchanged by the link (so I don't have to think too hard while using Wireshark).

But I would like the RF management interfaces to be visible within the ARM boards (e.g., if I add another interface via USB).  So I don't want to drop their packets on ingress to eth1, but certainly not let them egress eth0.  I'd also like to be able to be able temporarily expose an SSH interface for each ARM board on eth0 to make board configuration easier (and always have SSH on eth1, so I can configure over the RF link).

Here's my progress so far (though it may only show my ignorance).  The addressing can be anything it needs to be.

ARM-A:
  eth0 ---- br0 ------- dummy0 --------- gre0                      eth1
(no IP)   (no IP)  (192.168.1.254/24)   (to ARM-B: 192.168.2.254)  (172.10.10.10)

ARM-B:
  eth0 ---- br0 ------- dummy0 -------- gre0                       eth1
(no IP)   (no IP)  (192.168.2.254/24)   (to ARM-A: 192.168.1.245)  (172.10.10.11)

To provide temporary access to services on eth0, I'm thinking I could dynamically create eth0:0 with an IP address, then delete it when no longer needed.  But will it interfere with the passing of all other traffic over the tunnel?

I haven't yet been able to get a ping through the link, and I am way too ashamed to share the tangled mess of buggy ebtables rules I've been trying to write (I'm certain I'm putting bad rules into the wrong tables, etc.).

Any clues to get me going in the right direction?  I can't imagine that this kind of "device wrapping and tunneling" is all that rare, but many net searches have failed to turn up relevant examples (or examples I understood to be relevant), and endless reading of the ebtables/iptables documentation has left me bleary-eyed.  Perhaps it's a vocabulary thing?  I'm obviously not any kind of network engineer (I mainly work with TCP/UDP payloads).

I've tried asking on various StackExchange forums, but with no responses so far.  Help?

TIA,

-BobC

[Ebtables-user] ppp filtering

[george N. <mad...@ho...>]

Hello. What a great piece of software ebtables is!
I want to do some pppoe filtering and i run through some emails where a
new module was introduced ebt_ppp; Though i dont know the status of it.
Cant find it in any distro. Is it available ? Are there any examples how
to filter ppp trafic(Allow only LCP and IP to pass through bridge when
proto is ppp session)?

[Ebtables-user] libvirtd error

[abhishek j. <ash...@gm...>]

Hi all

I'm trying too boot Vm from my controller node onto compute node and
getting following error in nova-compute service using devstack ...

2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp     if
ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed',
dom=self)
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
libvirtError: Error while building firewall: Some rules could not be
created for interface tap74d2ff08-7f: Failure to execute command '$EBT -t
nat -A libvirt-J-tap74d2ff08-7f  -j J-tap74d2ff08-7f-mac' : 'Unable to
update the kernel. Two possible causes:
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp 1.
Multiple ebtables programs were executing simultaneously. The ebtables
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
userspace tool doesn't by default support multiple ebtables programs
running
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
concurrently. The ebtables option --concurrent or a tool like flock can be
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp    used
to support concurrent scripts that update the ebtables kernel tables.
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp 2. The
kernel doesn't support a certain ebtables extension, consider
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
recompiling your kernel or insmod the extension.
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp .'.
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
2014-04-30 05:10:22.452 17049 TRACE nova.openstack.common.rpc.amqp
2014-04-30 05:10:29.066 17049 DEBUG nova.openstack.common.rpc.amqp [-]
Making synchronous call on conductor ... multicall /opt/stack/nova/nova/o

However I'm able to boot the VM on controller node i.e the nova-compute on
cotroller node is no issue.
Following is the output of the commands related to ebtables on comppute
node..

lsmod
Module                  Size  Used by
ebtable_filter          3194  0
ebtable_nat             3173  0
ebtables               32629  2 ebtable_nat,ebtable_filter
openvswitch            62005  0

sudo service ebtables status
 * Ebtables support available, number of installed
rules
[ OK ]

 sudo ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

 ps -ef | grep libvirtd
root      5090     1  0 03:57 ?        00:00:03 /usr/local/sbin/libvirtd -d
root     14083 13755  0 04:15 pts/6    00:00:00 sg libvirtd
/usr/local/bin/nova-compute --config-file /etc/nova/nova.conf
ubuntu   20807  4428  0 04:49 pts/2    00:00:00 grep --color=auto libvirtd





Please help regarding this.

Thanks..

[Ebtables-user] using ebtables for dnat mac address

[Aleksey K. <ale...@gm...>]

Hello,

I need to handle mirrored traffic. For this I need to change
destination mac address of mirrored traffic to mac on network
interface on which I accept mirrored traffic.

Here is example mirrored traffic
15:59:29.114520 00:25:ba:5b:c9:11 (oui Unknown) > 34:40:b5:81:6c:ac
(oui Unknown), ethertype IPv4 (0x0800), length 84: 1.1.1.1.2052 >
2.2.2.2.domain: 43161+ A? dnl-01.geo.kaspersky.com. (42)

Here is network interface on which I want handle mirrored traffic
eth1      Link encap:Ethernet  HWaddr fe:f9:b4:d5:08:c3
          inet addr:X.X.X.X  Bcast:0.0.0.0  Mask:255.255.255.248
          inet6 addr: fe80::fcf9:b4ff:fed5:8c3/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:6424655 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1088214395 (1.0 GiB)  TX bytes:468 (468.0 B)
          Interrupt:30

Here is rules for ebtables

root@ns4:~# ebtables -t nat -L --Lc
Bridge table: nat

Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-d 34:40:b5:81:6c:ac -i eth1 -j dnat --to-dst fe:f9:b4:d5:8:c3
--dnat-target ACCEPT, pcnt = 0 -- bcnt = 0

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Bridge chain: POSTROUTING, entries: 0, policy: ACCEPT

root@ns4:~# ebtables  -L --Lc
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

But no one frame doesn't satisfy this rule. Where I'm wrong?

OS and package version:
root@ns4:~# uname -r
3.2.0-4-amd64
root@ns4:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.4 (wheezy)
Release:	7.4
Codename:	wheezy
root@ns4:~# dpkg -l | grep ebtables
ii  ebtables                           2.0.10.4-1
amd64        Ethernet bridge frame table administration


Thank you.

Re: [Ebtables-user] Can ebtables filter traffic between interfaces on the same bridge?

[Carl-Daniel H. <c-d...@gm...>]

Am 14.10.2013 16:44 schrieb Phil Schlegel:
> Cab EBTables filter traffic between interfaces on the same bridge? 
> Specifically I have a requirement to disallow traffice between
> interfaces on the same bridge.  Can this be on with EBTables?

That feature worked just fine 6 years ago, and there is no reason to
assume the feature has disappeared since then.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

[Ebtables-user] Can ebtables filter traffic between interfaces on the same bridge?

[Phil S. <phi...@su...>]

Cab EBTables filter traffic between interfaces on the same bridge?  
Specifically I have a requirement to disallow traffice between 
interfaces on the same bridge.  Can this be on with EBTables?

Thank You

[Ebtables-user] --arpop question

[Karolis B. <kba...@gm...>]

Hello,
I want to disable ARP requests on usb0 interface. Reading man page seems
like "--arpop Request" would do what I want, but when get an error when
using it:

$sudo arptables -A OUTPUT -o usb0 --arpop Request -j DROP
Bad argument `Request'

[Ebtables-user] Packet forwarding question

[Safuat H. <saf...@se...>]

Hello all,

I am performing a security audit for a customer.  They have client
machines (mainly desktop PCs) that need to authenticate regularly (every
few minutes) via 802.1x, which is not accessible for iptables (802.1x is
eap/eapol in wireshark with ethertype 0x888e).  In order to perform a
security scan under the presumption, that the autit machine is not given
access at the gateway, one idea was to write a small program using
libpcap that shovels the frames as necessary to the "other" interface.
But then I came recently across ebtables, which seems to be a suitable
tool.  I read the docs and played with ebtables.  However, so far I had
no success with with what I wanted.  And that's what I need:

Suppose a setup like this

	Gateway - Switch - Pentest Machine - Client PC

The gateway sends regularly 802.1x requests to the client pc, where the
gateway expects the pc to have a known MAC-address and IP-address.  Thus
the pentest machine must appear as client pc (either via address
spoofing or NATing) and just to relay the 802.1x packets forth and back
as necessary (and maybe a few other things such as ARP and DHCP).

The pentest machine has two ethernet interfaces (eth0 and eth1),
ebtables support is enabled (BackTrack 5R3).  I have bridged the two
interfaces together.  Indeed, traffic coming from outside (say through
eth0) is seen on the other side as well (say eth1), but the responses
from the client seems to be absorbed somewhere.

I tried first to spoof the MAC and IP address on the pentest machine,
but then the machine seems to believe that packets with the said MAC
address are destined to itself and doesn't forward them.  So then I
tried MAC-NATing, in which case the pentest machine seems to lose
interest in the packets on the wire at all (i.e. ping an the like
doesn't work) - of course, since the replies have the "wrong" MAC-address.

The ebtables broute table policy for the BROUTING chain was set in both
cases to ACCEPT (i.e. bridge all traffic); the filter table had some
filer rules but the policy for FORWARD was set (for playing) to ACCEPT
as well.  For MAC source NAT I used a rule in the POSTROUTING chain.
However, no matter what I did, I didn't get it to fly as I hoped.

The first question is whether ebtables is the right tool to look at, and
if so, the second question is how to wield it.  Has anyone reading here
some hints in that direction?


Sincerely
S. Hamdy

Re: [Ebtables-user] Missing functions/arptc_first_chain in arptables source code

[Roy Y. <ro...@ci...>]

Roy Yang <royyang@...> writes:

> 
> Hi, 
>   I am trying to use arptables on one embedded platform. After downloading the
> source code and cross-compiled it, execute, it generates the following error:
> 
> # ./arptables
> modprobe: cannot parse modules.dep
> arptables v0.0.3-3: can't initialize arptables table `filter': arptables who?
> (do you need to insmod?)
> Perhaps arptables or your kernel needs to be upgraded.
> 
> Checked source code, a lot of functions are missing, for example,
> arptc_first_chain. Is there any other packages I need to download?
> 
> Thanks, 
> 
> Roy
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> 



Have figured out it by myself finally.

The function arptc_first_chain is defined as Macro.

To make this thread useful, just listed
the steps I did to use arptables.

1.) Compile kernel by enabling the following options
+CONFIG_IP_NF_ARPTABLES=y
+CONFIG_IP_NF_ARPFILTER=y
+CONFIG_IP_NF_ARP_MANGLE=y
2.) Compile use space arptables 
3.) Apply rules using arptables

Thanks, Roy

[Ebtables-user] Missing functions/arptc_first_chain in arptables source code

[Roy Y. <ro...@ci...>]

Hi, 
  I am trying to use arptables on one embedded platform. After downloading the
source code and cross-compiled it, execute, it generates the following error:

# ./arptables
modprobe: cannot parse modules.dep
arptables v0.0.3-3: can't initialize arptables table `filter': arptables who?
(do you need to insmod?)
Perhaps arptables or your kernel needs to be upgraded.

Checked source code, a lot of functions are missing, for example,
arptc_first_chain. Is there any other packages I need to download?

Thanks, 

Roy

[Ebtables-user] Multicast Filtering

[Luigi D'A. <lda...@el...>]

Hi All,

I'm new to ebtables, 

Can I use it to filter all Multicast address but some favourites?

 

Could the following rules works?

 

ebtables  -A FORWARD -p IPv4 -i eth0 -o eth1 -ip-dst <my favourite
multicast 1>  -j ACCEPT

ebtables  -A FORWARD -p IPv4 -i eth0 -o eth1 -ip-dst <my favourite
multicast 2>  -j ACCEPT

 

ebtables -A FORWARD -o eth1 -d Multicast -j DROP

 

Thank you in advance for your help,

And sorry for my English.

 

Luigi

 

 

 

 

 

 

Re: [Ebtables-user] Log VLANs without interfaces.

[Asher A. <ash...@gm...>]

Grant, I'd be very interested in knowing if it is possible, even if it was only one way.
Any idea of a way forward?


On 15 Nov 2010, at 17:22, ebt...@li... wrote:

> Send Ebtables-user mailing list submissions to
> 	ebt...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/ebtables-user
> or, via email, send a message with subject or body 'help' to
> 	ebt...@li...
> 
> You can reach the person managing the list at
> 	ebt...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ebtables-user digest..."
> 
> 
> Today's Topics:
> 
>   1. ebtables + ipset (sadas sadas)
>   2. brouter basic question . (ratheesh k)
>   3. Re: brouter basic question . (Grant Taylor)
>   4. Adding ebtables entry from kernel module (Parthiv Shah)
>   5. mailing-list password (laugello)
>   6. Log VLANs without interfaces. (Asher Awelan)
>   7. Re: Log VLANs without interfaces. (Oscar N)
>   8. Re: Log VLANs without interfaces. (Grant Taylor)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 10 Dec 2009 13:54:58 +0200 (EET)
> From: sadas sadas <ma...@ab...>
> Subject: [Ebtables-user] ebtables + ipset
> To: ebt...@li...
> Message-ID:
> 	<146...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> 
> 
> I'm having a problem with ebtables. When I try to configure ebtables rules to work with ipset the following error occurs.
> I enter
> ebtables -A FORWARD --ip-dst
> ipset
> -j ACCEPT
> And the following error occur "Problem with the IP address 'ipset'."
> It seems that ebtables checks the input string for for numbers.
> Are you planning to support ipset in next release?
> 
> 
> 
> -----------------------------------------------------------------
> ????? ???????? ?????? ?? Vesti.bg!
> http://www.vesti.bg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 30 Mar 2010 17:38:12 +0530
> From: ratheesh k <rat...@gm...>
> Subject: [Ebtables-user] brouter basic question .
> To: ebt...@li...
> Message-ID:
> 	<cfe...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi ,
> 
>  i have a rule
> 
>            ebtables -t broute -A BROUTING -j ACCEPT .
> 
> So packet wont traverse any other chain ?  ( Prerouting , Input ,
> Forward , Postrouting ) ???
> 
> 
> Thanks,
> Ratheesh.
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 30 Mar 2010 12:31:33 -0500
> From: Grant Taylor <gt...@ri...>
> Subject: Re: [Ebtables-user] brouter basic question .
> To: Mail List - EBTables <ebt...@li...>
> Message-ID: <4BB...@ri...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 03/30/10 07:08, ratheesh k wrote:
>> So packet wont traverse any other chain ?  ( Prerouting , Input , 
>> Forward , Postrouting ) ???
> 
> Are you referring to other EBTables chains or IPTables chains?
> 
> If memory serves, "ACCEPTing" in the BROUTING chain causes frames to be 
> (layer 2) bridged.  Conversely "REJECTing" causes frames to be (layer 3) 
> routed.
> 
> 
> 
> Grant. . . .
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 16 Apr 2010 18:11:03 +0530
> From: "Parthiv Shah" <par...@si...>
> Subject: [Ebtables-user] Adding ebtables entry from kernel module
> To: <ebt...@li...>
> Message-ID: <8D53A0FEE4D94D71AB2A526E92A8C5D5@PARTHIVLAPTOP>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> I am new to using ebtables and my requirements is to do L2 NATing of clients
> connected on the bridge, through WiFi interface.
> 
> As a proof of concept, I am able to add following rules in ebtables and have
> the functionality that I want. (this is for one client connected on bridge)
> 
> 1. ebtables -t nat -A POSTROUTING -o ath0 -j snat --to-src
> 00:03:7F:12:06:90 --snat-arp --snat-target ACCEPT
> 
> 2. ebtables -t nat -A PREROUTING -p 0x0800 -i ath0 --ip-dst 192.168.40.239
> -j dnat --to-dst 08:00:46:6A:A4:AC --dnat-target ACCEPT
> 3. ebtables -t nat -A PREROUTING -p 0x0806 -i ath0 --arp-ip-dst
> 192.168.40.239 -j dnat --to-dst 08:00:46:6A:A4:AC --dnat-target ACCEPT
> 
> With above rules, client PC (192.168.40.239) is able to ping gateway
> (through WiFi - WAN interface) and it's packets are properly NATed. Now
> practically, there will be many clients connected on the bridge and run time
> they will join and leave the bridge port. So now I need to add/delete these
> rules (specifically 2 and 3) for each client as and when they join / leave.
> I was thinking of modifying the ebtables rules from the kernel itself (at
> the time of dhcp / arp / ip packet flow for any new client).
> 
> How can I add / delete the above rules (2 and 3), from the kernel module?
> Basically I don't want to use ebtables user space tool to add/delete rules
> in ebtables, neither I want to extend ebtables. I just want to be able to
> create / delete ebtables rule entries from kernel space.
> 
> Any help on this will be appreciated.
> 
> Thanks,
> Parthiv
> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> Message: 5
> Date: Fri, 22 Oct 2010 11:01:26 +0200
> From: laugello <lui...@un...>
> Subject: [Ebtables-user] mailing-list password
> To: ebt...@li...
> Message-ID: <4CC...@un...>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
> 
> Hello
> Sorry of the o-topic
> I forgot password of the mailing-list How I can recover it
> tanks
> Luigi
> 
> -- 
> Augello Luigi
> Amministratore di Sistema Poli didattici di Agrigento, Caltanissetta e 
> Trapani
> Universit? degli Studi di Palermo
> tel 093420928
> VoIP 09123865802
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 15 Nov 2010 10:47:31 +0000
> From: Asher Awelan <ash...@gm...>
> Subject: [Ebtables-user] Log VLANs without interfaces.
> To: ebt...@li...
> Message-ID: <7B0...@gm...>
> Content-Type: text/plain; charset=us-ascii
> 
> SCENARIO:
> I have inherited a hospitality solution which uses 802.11q tagging on it's switched network for the purpose of room identification, i.e. one port per room.
> My current handling of this is working but not stable and is memory heavy.
> Currently I have the 250 (I know!) VLANs on eth1.x as interfaces and have bridged them on br0.
> I am using ebtables to log which mac addresses are using which vlan tag and then doing some cron processing to charge data use to the rooms.
> However, this is pretty intensive on the network/ifconfig management.
> 
> QUESTION:
> Is there a way to broute the vlans to the eth1 interface and not have to create every interface and register every vlan... or perhaps strip the vlan id (after logging of course)...
> 
> Further clarification can be given of course.
> I know this is a ridiculous scenario, however these are my parameters within which to work.
> 
> Thank you kindly,
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 15 Nov 2010 14:11:28 +0100
> From: Oscar N <os...@ki...>
> Subject: Re: [Ebtables-user] Log VLANs without interfaces.
> To: <ebt...@li...>
> Message-ID: <848662e82c3ef7fb0184429ba8843cd5@localhost>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi!
> 
> We did this a couple of years ago due to shitty switches that didn't even
> had the possibility to filter out packets from rouge DHCP servers.
> What we did was using a central database and scripts on the linux boxes
> instead that handled all the hard work of setting up/removing interfaces.
> Worked very well and we also incorporated multiple routing tables and per
> user packet shaping. Maybe that would be another approach to solve the
> problem.
> 
> /Regards Oscar
> 
> On Mon, 15 Nov 2010 10:47:31 +0000, Asher Awelan <ash...@gm...>
> wrote:
>> SCENARIO:
>> I have inherited a hospitality solution which uses 802.11q tagging on
> it's
>> switched network for the purpose of room identification, i.e. one port
> per
>> room.
>> My current handling of this is working but not stable and is memory
> heavy.
>> Currently I have the 250 (I know!) VLANs on eth1.x as interfaces and
> have
>> bridged them on br0.
>> I am using ebtables to log which mac addresses are using which vlan tag
>> and then doing some cron processing to charge data use to the rooms.
>> However, this is pretty intensive on the network/ifconfig management.
>> 
>> QUESTION:
>> Is there a way to broute the vlans to the eth1 interface and not have to
>> create every interface and register every vlan... or perhaps strip the
> vlan
>> id (after logging of course)...
>> 
>> Further clarification can be given of course.
>> I know this is a ridiculous scenario, however these are my parameters
>> within which to work.
>> 
>> Thank you kindly,
>> 
> ------------------------------------------------------------------------------
>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>> Simplifying enterprise desktop deployment and management using
>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>> client virtualization framework. Read more!
>> http://p.sf.net/sfu/dell-eql-dev2dev
>> _______________________________________________
>> Ebtables-user mailing list
>> Ebt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ebtables-user
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Mon, 15 Nov 2010 10:41:11 -0600
> From: Grant Taylor <gt...@ri...>
> Subject: Re: [Ebtables-user] Log VLANs without interfaces.
> To: Mail List - EBTables <ebt...@li...>
> Message-ID: <4CE...@ri...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 11/15/10 04:47, Asher Awelan wrote:
>> QUESTION:
>> Is there a way to broute the vlans to the eth1 interface and not have 
>> to create every interface and register every vlan... or perhaps strip 
>> the vlan id (after logging of course)...
> 
> It /might/ be possible to strip the VLAN tags and send the traffic on 
> it's way with out the need for all the vlan interfaces.  But, I don't 
> know that it will be possible (at least as easily) to re-tag the 
> returning traffic.
> 
> Something you might consider doing is moving the (un)tagging / trunking 
> in to a user space application that can dynamically add and remove the 
> VLAN tags with out needing kernel support or vlan interfaces.  -  I'm 
> just typing raw theories out my (you know what) and would have to give 
> this quite a bit more thought.
> 
> 
> 
> Grant. . . .
> 
> 
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> 
> ------------------------------
> 
> _______________________________________________
> Ebtables-user mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-user
> 
> 
> End of Ebtables-user Digest, Vol 24, Issue 1
> ********************************************

Re: [Ebtables-user] Log VLANs without interfaces.

[Grant T. <gt...@ri...>]

On 11/15/10 04:47, Asher Awelan wrote:
> QUESTION:
> Is there a way to broute the vlans to the eth1 interface and not have 
> to create every interface and register every vlan... or perhaps strip 
> the vlan id (after logging of course)...

It /might/ be possible to strip the VLAN tags and send the traffic on 
it's way with out the need for all the vlan interfaces.  But, I don't 
know that it will be possible (at least as easily) to re-tag the 
returning traffic.

Something you might consider doing is moving the (un)tagging / trunking 
in to a user space application that can dynamically add and remove the 
VLAN tags with out needing kernel support or vlan interfaces.  -  I'm 
just typing raw theories out my (you know what) and would have to give 
this quite a bit more thought.



Grant. . . .

Re: [Ebtables-user] Log VLANs without interfaces.

[Oscar N <os...@ki...>]

Hi!

We did this a couple of years ago due to shitty switches that didn't even
had the possibility to filter out packets from rouge DHCP servers.
What we did was using a central database and scripts on the linux boxes
instead that handled all the hard work of setting up/removing interfaces.
Worked very well and we also incorporated multiple routing tables and per
user packet shaping. Maybe that would be another approach to solve the
problem.

/Regards Oscar

On Mon, 15 Nov 2010 10:47:31 +0000, Asher Awelan <ash...@gm...>
wrote:
> SCENARIO:
> I have inherited a hospitality solution which uses 802.11q tagging on
it's
> switched network for the purpose of room identification, i.e. one port
per
> room.
> My current handling of this is working but not stable and is memory
heavy.
> Currently I have the 250 (I know!) VLANs on eth1.x as interfaces and
have
> bridged them on br0.
> I am using ebtables to log which mac addresses are using which vlan tag
> and then doing some cron processing to charge data use to the rooms.
> However, this is pretty intensive on the network/ifconfig management.
> 
> QUESTION:
> Is there a way to broute the vlans to the eth1 interface and not have to
> create every interface and register every vlan... or perhaps strip the
vlan
> id (after logging of course)...
> 
> Further clarification can be given of course.
> I know this is a ridiculous scenario, however these are my parameters
> within which to work.
> 
> Thank you kindly,
>
------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Ebtables-user mailing list
> Ebt...@li...
> https://lists.sourceforge.net/lists/listinfo/ebtables-user

[Ebtables-user] Log VLANs without interfaces.

[Asher A. <ash...@gm...>]

SCENARIO:
I have inherited a hospitality solution which uses 802.11q tagging on it's switched network for the purpose of room identification, i.e. one port per room.
My current handling of this is working but not stable and is memory heavy.
Currently I have the 250 (I know!) VLANs on eth1.x as interfaces and have bridged them on br0.
I am using ebtables to log which mac addresses are using which vlan tag and then doing some cron processing to charge data use to the rooms.
However, this is pretty intensive on the network/ifconfig management.

QUESTION:
Is there a way to broute the vlans to the eth1 interface and not have to create every interface and register every vlan... or perhaps strip the vlan id (after logging of course)...

Further clarification can be given of course.
I know this is a ridiculous scenario, however these are my parameters within which to work.

Thank you kindly,

[Ebtables-user] mailing-list password

[laugello <lui...@un...>]

Hello
Sorry of the o-topic
I forgot password of the mailing-list How I can recover it
tanks
Luigi

-- 
Augello Luigi
Amministratore di Sistema Poli didattici di Agrigento, Caltanissetta e 
Trapani
Università degli Studi di Palermo
tel 093420928
VoIP 09123865802

[Ebtables-user] Adding ebtables entry from kernel module

[Parthiv S. <par...@si...>]

Hi,
 
I am new to using ebtables and my requirements is to do L2 NATing of clients
connected on the bridge, through WiFi interface.
 
As a proof of concept, I am able to add following rules in ebtables and have
the functionality that I want. (this is for one client connected on bridge)
 
 1. ebtables -t nat -A POSTROUTING -o ath0 -j snat --to-src
00:03:7F:12:06:90 --snat-arp --snat-target ACCEPT
 
 2. ebtables -t nat -A PREROUTING -p 0x0800 -i ath0 --ip-dst 192.168.40.239
-j dnat --to-dst 08:00:46:6A:A4:AC --dnat-target ACCEPT
 3. ebtables -t nat -A PREROUTING -p 0x0806 -i ath0 --arp-ip-dst
192.168.40.239 -j dnat --to-dst 08:00:46:6A:A4:AC --dnat-target ACCEPT

With above rules, client PC (192.168.40.239) is able to ping gateway
(through WiFi - WAN interface) and it's packets are properly NATed. Now
practically, there will be many clients connected on the bridge and run time
they will join and leave the bridge port. So now I need to add/delete these
rules (specifically 2 and 3) for each client as and when they join / leave.
I was thinking of modifying the ebtables rules from the kernel itself (at
the time of dhcp / arp / ip packet flow for any new client).
 
How can I add / delete the above rules (2 and 3), from the kernel module?
Basically I don't want to use ebtables user space tool to add/delete rules
in ebtables, neither I want to extend ebtables. I just want to be able to
create / delete ebtables rule entries from kernel space.
 
Any help on this will be appreciated.
 
Thanks,
Parthiv
 
 
 

Re: [Ebtables-user] brouter basic question .

[Grant T. <gt...@ri...>]

On 03/30/10 07:08, ratheesh k wrote:
> So packet wont traverse any other chain ?  ( Prerouting , Input , 
> Forward , Postrouting ) ???

Are you referring to other EBTables chains or IPTables chains?

If memory serves, "ACCEPTing" in the BROUTING chain causes frames to be 
(layer 2) bridged.  Conversely "REJECTing" causes frames to be (layer 3) 
routed.



Grant. . . .