Recommendation for a connection between Core Switch and Firewall

[mcgiga]

Hello,

I am asking myself what others recommend for the connection between core switch and Firewall.

The setup is the following:
Two Catalyst 9300 Core switches in stack. The stack is connected to two Secure Firewalls 3105.
The Core is doing L3 routing for four VFR‘s. Other VFR‘s are routed on the Firewall.

How would you configure the connection between Core and Firewall?

Currently we have a transit network (VLAN 100, 192.168.100.0/31). Routes on the Core for all VLANs point to the Firewall and vice versa.

Instead of a transit network we could terminate all VLANs on the Firewall on a trunk.

What do you think?

An additional question, how would you manage the Firewall from your internal management VLAN?

[Giuseppe Larosa]

Hello @mcgiga ,

from what you have written

>> Two Catalyst 9300 Core switches in stack. The stack is connected to two Secure Firewalls 3105.
The Core is doing L3 routing for four VFR‘s. Other VFR‘s are routed on the Firewall.

Each VRF routed on the core switch requires a logical transit  routed link to the firewalls that can be used as next-hop for a static default route again one for each VRF routed on the core switch.

If there are VLANs that belong to other VRFs that are L3 terminated i.e. routed on the firewall they need to be extended at layer 2 to the Firewall(s).

So you need to define 4 transit VLANs one for each VRF routed on the core switch like 1101, 1102,1103, 1104

The two physical ports connected to the two Firewalls should be configured as 802.1Q trunk allowing all the required VLANs

1101-1104 + (all L2 VLANs that are routed on the FW).

if the FWs are configured as an HA pair the two physical ports have to be indipendent.

You can use two port-channels one to FW01 and one to FW02 that are 802.1Q trunk as described above.

>> An additional question, how would you manage the Firewall from your internal management VLAN?

Here, it depends first of all on how the two FTD are deployed . Do you use FMC or locally managed by FDM ?

The second question is  do you use out of band management so you could connect the mgmt ports to a dedicated VLAN ?

Hope to help

Giuseppe

[Deepak Kumar]

Hello, 

If you want to filter all VLANs, there is nothing wrong with the purpose of your design. Before implementing this type of design, I always check two things: a) Is my firewall capable of handling inter-VLAN routing? b) What will be the management complications? I then compare all the factors against the benefits.

Regarding the configuration of the connection between the Core and the Firewall: VRFs will require logical transit, and you can use transit VLANs for it. It will be one transit VLAN for each VRF. If the firewalls are configured as an HA pair, the two physical ports have to be independent. You should use two port channels: one to FW01 and one to FW02, both as 802.1Q trunks if HA.annels: one to FW01 and one to FW02, both as 802.1Q trunks if HA. 

You can manage your firewalls via FMC using the OoB interface. 

Let me know if you need more details. 

[MHM Cisco World]

"" The Core is doing L3 routing for four VFR‘s.""  for this you need additional vlan use as next-hop for default route from core towards FW this new vlan must be in global and you need to use some route leaking in Core

"" Other VFR‘s are routed on the Firewall."" vlan for each vrf, in FW you can use vrf or put these vlan in global, remember the vrf is locally.

So using one trunk between Core and FW allow above VLAN is what you need only

MHM

[mcgiga]

I think my description was not precise enough or I described the project incorrectly.

L3 routing is active on the core switch. There is a transit network between the switch and the firewall. The VLANs 10, 20 and 30 are in the same VRF, are routed on the L3 and are allowed to reach each other. Internet access takes place via the transit network. VLANs 40, 50 and 60 are each located in their own VRF (VRF A, VRF B and VRF C). Their respective routes also point to the firewall (via the transit network). VRFs A, B and C may only have partial access to each other. This access is regulated on the firewall.

As an alternative to this currently configured variant, it would be possible to deactivate L3 routing on the switch and terminate all VLANs on the firewall. The transfer network would be omitted and instead there would be a trunk with the VLANs 10-60, which exists between the switch and the firewall.

In both variants, access between the VLANs would be permitted or prohibited on the firewall.

In your opinion, which variant is preferable? I am leaning towards the variant with a transfer network so that the VLANs are not on the firewall.

My second question was regarding the administration of the firewall. In the second variant with the trunk, the management VLAN could also be on the trunk and it would be possible to manage the firewall from the management VLAN.

However, if we stick with the transfer network variant, the question arises as to how access for managing the firewall should ideally be organized. Would you connect the management interface of the firewall to an internal switch via patch cable in order to link the management interface to the management VLAN?

There is also a switch in front of the firewall, i.e. between the firewall and the provider's router. How would you implement the management of this switch? Also establish a connection to the internal switch with a separate patch cable in order to establish a connection to the internal management VLAN?

[Giuseppe Larosa]

Hello @mcgiga ,

I'm litte lost ...

do you mean you are using a single logical transit network  for SVIs that are in GRT and those in VRF A, VRF B , VRF C ?

Have you configured any form of route leakage between GRT and the VRFs on the core switch ?

But then you say:

>> Their respective routes also point to the firewall (via the transit network). VRFs A, B and C may only have partial access to each other. This access is regulated on the firewall.

I don't understand AFAIK either you have an end end VRF lite or you to play with inter VRF or route leakage on the core switch side. ( ok you could use full MPLS L3 VPN but I don't think FTD support it)

VRF lite end to end requires a dedicated logical link for each VRF and one for the GRT = Global Routing Table

Second option can use a single transit network in GRT or other VRF but then the FW can be bypassed when inter VRF communications happen.

Can you clarify this point ?

The easy way for management is to connect the FTD mgmt port with dedicated cable to a switch where the management VLAN is deployed this is how FMC expects to reach the managed devices aka sensors.

For DMZ switch it depends on your security concerns you can have a dedicated per DMZ management subnet for it or it can be in the same management subnet if it is a L2 only switch.

Hope to help

Giuseppe

[mcgiga]

>> do you mean you are using a single logical transit network for SVIs that are in GRT and those in VRF A, VRF B , VRF C ?
Yes. But every VLAN is in it's own VRF except VLAN10, 20 and 30. These are in the same VRF.

Transitnetwork is VLAN100 (192.168.100.0/31). The IP address of the Core switch is 192.168.100.0, Firewall is 192.168.100.1.

Each VRF has a global route like this: 0.0.0.0 0.0.0.0 192.168.100.1 global

There is a route for each VRF on the firewall so that the traffic can be sent back. I.e., the gateway of VLAN50 on the core switch is 192.168.150.1 (/24). The route on the firewall is: 192.168.150.0 255.255.255.0 192.168.100.0.

On the core switch there is one route in the global routing table pointing back to each VRF, i.e. for VLAN50 it is: 192.168.150.0 255.255.255.0 VLAN50

We have not yet decided whether to keep the VRFs or not. The original idea was to leave VLANs 10, 20 and 30 on the core switch, as there are no restrictions between these VLANs and no filtering is necessary. The utilization was still unknown at this time. The traffic of VLANs 10, 20 and 30 could also pass through the firewall. Contrary to the original assumption, the utilization is low.

But then my question from my last answer remains: Is your recommendation to leave the routing on the L3 switch and route the traffic via the transit network to the firewall or to terminate all VLANs via a trunk on the firewall, i.e. to set up the gateway IP addresses of each VLAN on the firewall? Of course without VRFs and enabled L3 routing on the core switch we would have to set up ACLs to deny traffic between all VLANs.

>> The easy way for management is to connect the FTD mgmt port with dedicated cable to a switch where the management VLAN is deployed this is how FMC expects to reach the managed devices aka sensors.

Ok, that's what I assumed. The firewall is running ASA code, but that should not make any difference.

>> For DMZ switch it depends on your security concerns you can have a dedicated per DMZ management subnet for it or it can be in the same management subnet if it is a L2 only switch.

This is an L2 switch to establish connections between the firewall and two provider routers. Only one port can be used on each provider router. Due to the high availability of the firewall, both provider routers require a connection to the each firewall chassi. There is no dedicated DMZ management subnet. When I understand you correctly you would connect an access port to one of the internal switches where the management VLAN is present.
I thought about this kind of connection but wasn't sure if there is a preferable way.

I hope I have been able to clear up any ambiguities. Unfortunately, it is not so easy for me to explain the topic completely in English.

[Giuseppe Larosa · Accepted solution]

Hello @mcgiga ,

>> Each VRF has a global route like this: 0.0.0.0 0.0.0.0 192.168.100.1 global

Now I understand each VRF exits via the single uplink to the FW using this kind of static route with a global IP next-hop.

The decision on using IP routing and VRF routing in the core switch is a design choice that can provide performance advantages on inter VLAN routing within each VRF and the GRT.

Moving all the VLANs to the firewall with the FW performing inter VLAN routing also within a single VRF or GRT makes the perfomance upper limit much lower on the FW.

There are some advantages from security point of view that the FW can detect MAC address of each connected host in the ARP table.

Most of the times the decision is taken based on organizational structure, if the FWs are managed by another team they  can put pressure on terminating VLANs on the FW so that they have the most observability.

If both switches and FWs are under a single working team keeping the Inter VLAN routing within each VRF / GRT on the core switches provide far better performance on the long term.

FTD 3100 with ASA code -> no FMC so you can use inband management if you want.

>> Unfortunately, it is not so easy for me to explain the topic completely in English.

Don't worry english is not my mother tongue too.

Hope to help

Giuseppe

[mcgiga]

Thank you for your response and sorry for my delayed response. Was a bit busy with private things.

I have a last question in this case regarding ACLs. We have dropped VRF. So each VLAN can reach all other VLANs.
Let's assume we have: VLAN 1, 2, 3, 4 up to 25. VLAN 100 is the mentioned transit vlan to the firewall.

When I want to block all traffic between VLAN 1 (192.168.130.0/24), VLAN 2 (192.168.169.0/26), VLAN 3, VLAN 4 up to VLAN 25 but every VLAN should be able to access transit VLAN 100 (192.168.100.1/31) to reach 0.0.0.0 (Internet), what would be the best way? I tried it this way.

ip access-list extended ACL-VLAN1
deny ip 192.168.130.0 0.0.0.255 192.168.169.0 0.0.0.63
deny ip 192.168.130.0 0.0.0.255 VLAN3
deny ip 192.168.130.0 0.0.0.255 VLAN4 and so on...
permit ip any any

int vlan1
ip access-group ACL-VLAN1 in

This way works but I would have to include every VLAN (in reality there are around 25 VLANs) into every ACL, which is then assigned to the corresponding VLAN interface. So every ACL is getting huge.

The other way I thought of was to permit traffic to VLAN 100 and deny any:

permit ip 192.168.130.0 0.0.0.255 0.0.0.0 255.255.255.255
deny ip any any

But unfortunately that allows communication between VLAN 1 and all other VLANs.

Do I really have to create an ACL for every VLAN interface and explicitly deny traffic between each VLAN and then permit any?

[Giuseppe Larosa]

Hello @mcgiga ,

>> This way works but I would have to include every VLAN (in reality there are around 25 VLANs) into every ACL, which is then assigned to the corresponding VLAN interface. So every ACL is getting huge.

The use of VRF lite was giving you isolation without the need to use these extended ACLs and it is one of the reasons for using multiple VRFs.

Depending on how is your address plan you may be able to write shorter ACLs but you still need a per SVI ACL.

if for example your VLANs use the following subnets

VLAN 2 : 192.168.169.0/26

VLAN 3: 192.168.160.0/24

VLAN 4: 192.168.161.0/24

and so on

you can create an ACL that denies towards 192.168.160.0 0.0.15.255.

This works only if your subnets can be aggregated it is the same issue of route aggregation /  summarization.

And what is more important if there are not subnets that you reach via the transit link that fall inside the ACL statements.

Hope to help

Giuseppe

[mcgiga]

Subnets are differently, so smaller ACLs don‘t work.

Do you prefer bigger ACLs so any communication can be blocked or VRF lite?

[Giuseppe Larosa · Accepted solution]

Hello @mcgiga ,

>> Do you prefer bigger ACLs so any communication can be blocked or VRF lite?

I would go with VRF lite to make the Firewall to decide who can speak with who.

on the long ran you can add new VRFs or new subnets to existing VRFs and you have to configure only the FW.

Hope to help

Giuseppe

[paul driver]

Hello

---

@mcgiga wrote:

This way works but I would have to include every VLAN
I  really have to create an ACL for every VLAN interface and explicitly deny traffic between each VLAN and then permit any?

---

If you want to isolate intervlan communication on the L3 core without segregating them into different vrfs then yes a routed acl would be applicable and yes the acl will need be applied to each L3 SVI. you wish to isolate.

Alternatively if applicable you could relocate the core L3 subnets onto the Fws which usually deny intra/inter communication by default.