Hello there folks, since the idea of using a bridging firewall is of importance to me, I would like to ask folks here particularly Mr. Kewpie to elaborate more on it.
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.
But if I try to ping 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.
I am keen to hear from you fellas !
Regards,
Aijaz Baig.