Bridge Group in Transparent Mode

[David Ettinger]

I have a Firepower 2100 firewall managed by FMC 7.x.   It is set up in transparent mode with a bridge group (BG) between ports 1/1 and port 1/2.   In my test bed I have an outside computer 192.168.1.1 and an inside computer 192.168.1.2.   Access rules are accept everything.   When I set the BG IP address to 192.168.0.1/16 I can ping through the firewall.   When I set the BG IP to 192.168.10.1/16 I get a No route to host -- which is what I expected.   When I open up the BG IP to 192.168.1.1/8, again ping works fine.   However, when I deploy this firewall to my end user's site, I need to be able to pass 205.x addresses as well as 224.x multicast addresses.   So, to test this, I set the BG IP to 192.168.1.1/2 -- which, in my mind should pass 192.x.x.x through 255.255.x.x IP addresses.   When I do this I cannot ping through the firewall.   So I'm a bit confused on why this isn't working and, ultimately, how to I get 205 and 224 addresses through my firewall in transparent mode.

Thanks in advance for your help.

David

[tvotna]

For unicast traffic set same subnet mask that is used by 192.168.1.1 and .2 hosts (probably /24?) and configure static routes on ASA, e.g. 0.0.0.0/0. The firewall will use static route(s) to send ICMP requests from its bvi interface to non-connected destinations to learn next-hop MAC address and populate MAC table.

[David Ettinger]

I don't think I can set up static routes in transparent mode.    Not even sure how to get down to the ASA level.

[MHM Cisco World]

Can you share interface config and bridge config'

There is one step wrong I think.

[David Ettinger]

There is not much to configure for the interfaces since there is no IPs in transparent mode.   For both outside and inside interfaces, they are named Outside and Inside, respectively, mode=None, Security Zone is Outside_Zone and Inside_Zone, MTU is 1500.   Nothing outside of the defaults are set on the IPv6, Advanced or H/W configuration tabs.   The Bridge Group ID=1, selected interfaces are Ethernet 1/1 and 1/2.   On the IPv4 tab, we have a static IP (right now) of 1.1.1.1/2.   Nothing is beyond the defaults are on the IPv6 tab.    BTW, the deployment fails with a bridge IP of 0.0.0.0/0 (which I thought would allow all IP addresses).   Again, all this seems to work until I open up the netmask to allow more IP addresses.   BTW, I'm not even sure why we need an IP and a netmask.    Logically (to me anyway) it seems like the virtual bridge in transparent mode should simply connect two interfaces (in my case) and then you'd limit IPs via the access rules.  

[tvotna]

IP address and static routes are needed for the firewall to understand which destinations are local and can be probed by ARP requests (in order to populate MAC address table and egress interface information) and which destinations are remote (and hence ICMP probe needs to be used for the same). Note that bridge group can have more than two interfaces, so it's important for the firewall to know which interface leads to the destination.

ASA/FTD in transparent mode is indeed a bridge with one important difference: it doesn't use MAC address learning like bridges do. It needs to send probes in order to populate MAC table. When you set mask to /8 or so you essentially disable ICMP probing end enable ARP probing for all/most destinations, which means that next-hops need to do proxy ARP to respond back.

Use FMC or FDM on FTD to configure routes.

[MHM Cisco World]

No need route' I will check your config and update you tonight.

[MHM Cisco World]

On the IPv4 tab, we have a static IP (right now) of 1.1.1.1/24

Pc connect to Outside and Inside must be in same 1.1.1.0/24 subnet'

Then add acl to allow inside to outaide zone and from outside to inside zone(optional).

That it.

[David Ettinger]

I think I have solved the problem.  I set the bridge IP address to a 192.168.1.1/16 which will allow the unicast addresses I need.   Then I was able to set up a simple multicast test by setting up tcpdump on the listener end and a ping of a 224.x IP address on the sender end and the IGMP packets magically made it through the firewall.   Not sure how.   If you see any issues with this test case let me know.  And, as always, thanks for your help.   It is much appreciated!!