TO ADMIN: KINDLY REMOVE THE THREAD WITH THE SAME TITLE FROM THE WIRELESS NETWORKING FORUM. THAT WAS POSTED WRONGLY THERE. THANKS!
Hello there folks, since the idea of using a bridging firewall is of importance to me, I would like to ask folks here to elaborate more on the techniques used for bridged (transparent firewalling) using vlans on linux bridges.
Well..we could even discuss about my interface that I have here:
I have a bridge firewall with two interfaces, PortA and PortB.
PortA connects to the
LAN and
PortB connects to the
WAN.
Now since I want to have a invisible firewalling bridge to separate the 'bad' and the 'good' traffic I create a vlan interface on PortA with an ID of 3 so there is a virtual interface PortA.3. I have only given an IP addr to the bridge itself br0 for managing it. The details:
br0 - 192.168.5.104/20
PortA - 0.0.0.0
PortB - 0.0.0.0
PortA.3 - 0.0.0.0
PortB - 0.0.0.0
My local machine's interface eth0 connects via a LAN cable to PortA. I create a vlan interface here with the same ID as that of the bridge for the 'bad' traffic. Thus the details for my local machine are:
eth0 - 192.168.4.237/20
eth0.3 - 14.11.11.11/24
The router is at 192.168.13.25 and the DNS server is at 203.88.135.194 both of which are accessible via the bridge (are located at the WAN end of the bridge).
1. Now I have flushed all rules for ebtables and iptables on my bridge (which is rather a brouter). The only rule that I have is:
Code:
ebtables -t broute -A BROUTING -p 0x8100 -j redirect --redirect-target DROP
this causes the bridge to route all packets that are vlan tagged. Additionally I have added a default route on my bridge so that it is able to bridge packets to 'unknown IP destinations' based on their MAC address. Without this I cannot ping the brouter from eth0.3 to br0.
To get some feel of what happens when I ping my brouter from eth0.3 heres the output of
Code:
'tcpdump -nep -i any host 14.11.11.11'
on the bridge:
Code:
17:36:49.238115 PortA, IN: In 00:25:11:8f:c6:21 ethertype 802.1Q (0x8100), length 104: vlan 3, p 0, ethertype IPv4, 14.11.11.11 > 192.168.5.104: ICMP echo request, id 35341, seq 1, length 64
17:36:49.238149 PortA.3, IN: In 00:25:11:8f:c6:21 ethertype IPv4 (0x0800), length 100: 14.11.11.11 > 192.168.5.104: ICMP echo request, id 35341, seq 1, length 64
17:36:49.238411 br0, IN: In 00:25:11:8f:c6:21 ethertype IPv4 (0x0800), length 100: 14.11.11.11 > 192.168.5.104: ICMP echo request, id 35341, seq 1, length 64
17:36:49.238698 br0, OUT: Out 00:0d:48:36:59:88 ethertype IPv4 (0x0800), length 100: 192.168.5.104 > 14.11.11.11: ICMP echo reply, id 35341, seq 1, length 64
17:36:49.238722 PortA.3, OUT: Out 00:0d:48:36:59:88 ethertype IPv4 (0x0800), length 100: 192.168.5.104 > 14.11.11.11: ICMP echo reply, id 35341, seq 1, length 64
17:36:49.238743 PortA, OUT: Out 00:0d:48:36:59:88 ethertype 802.1Q (0x8100), length 100: vlan 1280, p 2, LLC, dsap Unknown (0xbe) Individual, ssap ISO8208 (0x7e) Response, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length 80
Thus as can be seen from the above output, the last response (in blue) is the faulty one here since the vlan id has changed from 3 to 1280 plus it doesn't look like an ICMP reply anymore. This means that as it is about to be routed from PortA.3 to PortA (is it routing here or is it bridging??) something goes haywire with the packet it seems.This error shows up at the ping's output as I cannot see the reply in the ping. I can however see the packets and (although surprisingly) see the requests and replies, as can be seen below
Heres a sample of tcpdump on eth0:
Code:
17:59:04.913957 00:25:11:8f:c6:21 > 00:0d:48:36:59:88, ethertype 802.1Q (0x8100), length 102: ethertype IPv4, 14.11.11.11 > 192.168.5.104: ICMP echo request, id 56333, seq 3, length 64
17:59:04.915406 00:0d:48:36:59:88 > 00:25:11:8f:c6:21, ethertype 802.1Q (0x8100), length 102: ethertype IPv4, 192.168.5.104 > 14.11.11.11: ICMP echo reply, id 56333, seq 3, length 64
Heres a sample of tcpdump on eth0.3:
Code:
17:59:04.913947 00:25:11:8f:c6:21 > 00:0d:48:36:59:88, ethertype IPv4 (0x0800), length 98: 14.11.11.11 > 192.168.5.104: ICMP echo request, id 56333, seq 3, length 64
17:59:04.915406 00:0d:48:36:59:88 > 00:25:11:8f:c6:21, ethertype IPv4 (0x0800), length 98: 192.168.5.104 > 14.11.11.11: ICMP echo reply, id 56333, seq 3, length 64
Could someone shed some light on this?
2. Secondly when I try to ping to the DNS server from an untagged interface (eth0), i can see the ARP request coming in from PortA and leavin out from PortB without being bridged, since the bridging code realizes it is to be routed and not bridged since the dest IP address is not that of the brouter itself but is yet unknown. Being the bridge that it is, it floods all the remaining port (which in our case is PortB) with this request.
A tcpdump on the bridge for the above case i.e. ping 192.168.13.25 from eth0 reveals:
Code:
12:58:43.478363 PortA, IN: B 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 192.168.4.237, length 46
12:58:43.478529 br0, IN: B 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 192.168.4.237, length 46
12:58:43.478612 PortB, OUT: Out 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 192.168.4.237, length 46
12:58:43.480030 PortB, IN: P 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
12:58:43.480130 PortA, OUT: Out 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
12:58:44.479288 PortA, IN: P 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (00:90:fb:13:d5:73) tell 192.168.4.237, length 46
12:58:44.479473 PortB, OUT: Out 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (00:90:fb:13:d5:73) tell 192.168.4.237, length 46
12:58:44.479631 PortB, IN: P 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
12:58:44.479705 PortA, OUT: Out 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
12:58:45.478866 PortA, IN: P 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (00:90:fb:13:d5:73) tell 192.168.4.237, length 46
12:58:45.479043 PortB, OUT: Out 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (00:90:fb:13:d5:73) tell 192.168.4.237, length 46
12:58:45.479197 PortB, IN: P 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
12:58:45.479269 PortA, OUT: Out 00:90:fb:13:d5:73 ethertype ARP (0x0806), length 62: Reply 192.168.13.25 is-at 00:90:fb:13:d5:73, length 46
Now why is it that only the very first request is bridged to br0 (from PortA)and all subsequent packets arriving on PortA are directly bridged to PortB and vice versa? even the reply for the very first request goes directly from PortB to PortA.
Is it because the very first packet is actually routed to the above layers (L3) since the destination address is a broadcast address and hence is eligible to be processed by the bridge?
Now if I try pinging the server from eth0.3, the packet hits the only rule in the BROUTING chain and hence is routed to PortA.3 from PortA, from there it is later bridged to br0. Now why doesn't the bridge behave like it did in the case described in the above paragraph? From here nothing seems to happen. I cannot even see the bridge forwarding it to any port. It is as if the packet seems to have been consumed.
A tcpdump on the bridge reveals the following :
Code:
12:28:38.659857 PortA, IN: B 00:25:11:8f:c6:21 ethertype 802.1Q (0x8100), length 66: vlan 3, p 0, ethertype ARP, Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 14.11.11.11, length 46
12:28:38.659885 PortA.3, IN: In 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 14.11.11.11, length 46
12:28:38.659906 br0, IN: In 00:25:11:8f:c6:21 ethertype ARP (0x0806), length 62: Request who-has 192.168.13.25 (ff:ff:ff:ff:ff:ff) tell 14.11.11.11, length 46
And this pattern repeats as many times as the number of ICMP requests being sent. Why doesn't br0 forward it to all the remaining ports as it did in the case above?
I am keen to hear from you fellas !
Regards,
Aijaz Baig.