cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2439
Views
3
Helpful
45
Replies

Trunking an ip addressed inside interface on Firepower 2130

jreynolds4
Level 1
Level 1

My network endpoints use the IP addressed vlans on my core cisco layer three core switch as their gateway addresses. i.e.- vlan 11 endpoint address 192.168.11.3/24 with gateway 192.168.11.1/24 (vlan ip on core) and vlan 12 endpoint address 192.168.12.3/24 with gateway 192.168.12.1/24 (vlan ip on core). These vlans are then interconnected. I am attempting to create a path to the internet using the gateway of last resort out of the switch 0.0.0.0 0.0.0.0 10.2.2.1. 10.2.2.1, security zone "InsideTrunk," is the address of a physical inside interface on my Firepower 2130. I have created Access control policies to allow 192.168.11.0/24 and 192.168.12.0/24 from "InsideTrunk" to Outside on the Firepower. Also, the proper auto NATs for both subnets have been created. The endpoints are unable to reach the internet. All I am trying to do is create a transport network. Does anyone have an idea of what I am missing? I have attached the trunk config from the core switch.

 

45 Replies 45

done worry I dont forget you but I am busy so tomorrow or later tonight I will share some detail with you.
MHM

Thank you, MHM. I look forward to seeing your ideas.

Hopefully I'm not missing anything here. You are trying to create a transit subnet between the switch and the FTD, this means the switch port Gi1/0/21 needs to be configured in access mode, not trunk, and it should be placed into VLAN 13 which is the transit subnet between the switch and the FTD. Otherwise I'm not sure how what you are tyring to do would work, because if the FTD does not have any sub-interface configured with the VLAN ID 11 and 12 it won't be able to read and process the tagged traffic coming from VLANs 11 and 12.

Let's say an endpoint in VLAN 11 that is using the switch SVI as its default gateway is trying to reach the FTD IP 10.2.2.1, the switch will route the traffic from VLAN 11 to VLAN 13 and will send the packets over the trunk link, the FTD will receive the packet over the trunk link, and because this packet is tagged with VLAN 11 the FTD wouldn't be able to process it.

However, if you configure the switch port Gi1/0/21 in access mode in VLAN 13, traffic will be routed from the switch to the FTD untagged and in this case the FTD will process it just fine. Obviously the FTD would need to have a couple of static routes pointing to the switch IP 10.2.2.2 for any traffic destined to VLAN 11 and 12.

Alternatively, another design solution in this case would be to move the SVIs from the switch to the FTD, essentially making the FTD to become the security enforcement point, as well as the routing engine. However, some caution measures should be taken before any design change, mainly to evaluate if the amount of the inter-VLAN traffic that the switch is able to handle could be handled fine by the FTD, otherwise this option can be discarded straightaway.

Thank you so much, Aref. I began this process by pointing the endpoints to sub-interfaces which allowed the internet access but not inter-vlan connnectivity. I then moved to the vlan tagged trunk idea out of the switch which as you have explained cannot work. I will change to access on vlan 13. The routes are already configured on the from the inside interface to the internet for both vlans 11 and 12. Thank you again. I will do this in the next few minutes and update.

"Obviously the FTD would need to have a couple of static routes pointing to the switch IP 10.2.2.2 for any traffic destined to VLAN 11 and 12."

I have made the change to access on the switch port, but as I reread you instruction, I see the above and realize I do not have this configured. What I have configured is an access control policy on the FTD to allow traffice from the transit port for vlan 11 and 12 traffic to the internet and an auto NAT using the outside interface for each vlan. I do not know how to configure the static routes pointing to the switch IP 10.2.2.2. I will do further research on how to accomplish this using Firepower Management Center, unless you can advise.

We wee typing about the same exact thing at the same time : - D. If you go to device page in "FMC > Routing" from there you can set the static routes of the device. Then obviously you need to deploy the changes. I will see if I can find an image showing where that page is exactly located.

Without draw which I hope to do it 

Anyway 

SW-interface l3-FW

Now 

SW Have two vlan svi use for intervlan 

SW use defualt route toward next-hop FW

FW have two static route toward next-hop of SW (l3 interface) for both vlan subnet 

FW have ACL allow traffic from these two subnet into internet 

FW have two NAT to NATing two subnet to access internet 

That it

MHM

 

jreynolds4_0-1714066514465.png

 

That's the one. You define the VLAN 11 & 12 subnets in the first column, then you select the interface connected to the switch port Gi1/0/21, and you set the gateway as 10.2.2.2 please.

Friend you can add two subnet under same object 

Or you can do some superneting to merge both subnet intwo one

MHM

You're very welcome. Just to make sure we are on the same page regarding the FTD routing, the FTD needs static routes back via the switch (10.2.2.1) for the traffic destined to VLAN 11 and 12, if that is what you meant by saying "The routes are already configured on the from the inside interface to the internet for both VLANs 11 and 12." then please discard this message : - D.

 

I am not sure what values such as gateway should be entered. Or am I in the wrong place?

I think there is some lagging when we post here : - D. The switch IP 10.2.2.2 would be the gateway for VLAN 11 and 12.

Dont use vlan SVI IP in FW never'

Use l3 interface IP in SW for static route.

Retrun to above my comment' you need to use L3 interface not need to run vlan between FW abd SW.

Hope this clear 

MHM

I beg to differ, I can't see why the switch SVI shouldn't be used as the gateway for those static routes in this case, it is actually the common way to do it in this case. I don't believe creating a routed interface on the switch would be required in this case.

Review Cisco Networking for a $25 gift card