Other posts related to is_archive

Palo Alto OSPF route filtering

 | 11 Apr 2023 14:41

To reduce the impact of lab testing bits and pieces, I decided to refresh my home network. The requirement I set myself is to reduce some of my family’s frustration when things go sideways, as it inevitably happens when trying out something new. Thus the point of the exercise is not just to refresh my memory or learn something new, but to create a clear separation between the home and the ‘lab’ networks.

The core of the domestic network will still be the same core switch and servers. But, any failures on the lab side should not affect the home network’s connection to the internet. Or as my kids would put it, the ‘WiFi’ must not go down. To my shame, and despite my many admonitions, our spawn persists in calling an internet connection “WiFi”.

In summary, my home network consists of a Ruckus ICX 7250 layer-3 capable switch. Not as polished as a Cisco but it’s an affordable second-hand switch with 48 POE ports and 8x 10GE SFP+ ports. The bulk of the compute and storage element is provided by two HPE DL380 servers, one gen8 (LFF with raid SAS storage) and the other gen9. I later added vSAN using Intel NVMe and 8TB SAS disks. It’s an organically grown mess, but it works and runs the latest version of vSphere 7 very well. Both servers are connected with 2x10GE (LACP LAG) for vSAN and VMs and 2x2GE for management.

Our FTTP terminates on a Palo Alto VM-50, and this is where vSAN and vMotion shine as this virtual firewall can move between the two ESXi hosts without missing a beat.

Initial setup and problem

At first, each VLAN was individually connected to the firewall, which worked great until the firewall went down (only for a software upgrade of course) and I could no longer connect to vCenter from my home network.

My solution was to introduce a Layer-3 link between the switch and the firewall. This made the switch the default gateway for the home network and I could then bring up a vlan interface on the switch to restore access to the management subnet if the firewall was unavailable. Routing between the switch and the firewall was static, which worked well enough, issues were only sporadic after all.

But then a DNS server on my network died and I figured I could do better, by removing lab/dev elements from the home network and giving myself direct access to that rather than traversing the firewall.

Current redesign

I had already used VRF-lite to configure the p2p routed link between the switch and the firewall for the home network. Doubling this for a work VRF was a simple progression while also ensuring that local traffic between work (access, server and management) subnets could flow freely without traversing the firewall. This should avoid management reachability issues for me the next time I upgrade the firewall. Additionally, I’ll be the only user connecting this way and there will be no direct wireless exposure of this VRF, limiting exposure of vSphere via potentially compromised clients on the home network.

I’m still undecided about which is harder to teach regarding cyber security, clients or family members…

Static or dynamic routing?

Moving subnets around becomes easier with dynamic routing protocols. This is what I needed to do and I figured it would be a good Palo Alto routing refresher. While the Ruckus switch supports RIP and OSPF, I went with OSPF as I figured it to be more relevant. Does anyone still use RIP these days? Please don’t answer that; there are too many things in tech that just won’t die…

OSPF

As I set out to add a second VRF to the switch and configure OSPF on it I found a couple of things that one should be aware of:

vSphere

  • When adding a new Distributed Port Group (DPG) on a vSwitch with a LAG uplink, ensure the advanced settings are changed to reflect this. This is obvious when initially configuring vSphere, but is easy to forget. So if you find that the switch doesn’t see an OSPF neighbor and the firewall does (stuck in init mode), check the settings of the DPG…

Ruckus

  • Simple straightforward configuration from the CLI, but there is no way to see or configure anything OSPF from the web interface.
  • With no need to filter advertised prefixes I didn’t check or test for prefix filtering. In fact I used area 0 (0.0.0.0) for all three routing instances.
    • Switch: Enabled OSPF on vrf LAN
    • Switch: Enabled OSPF on vrf WORK
    • Firewall: Enabled OSPF on the default virtual router
    • Set vlan ports to ospf-passive to include them in OSPF rather than redistribute connected.
      • This reduces network chatter, as no neighbor advertisements take place on passive ports.

Palo Alto

  • Only advertise a default route. As I’m using the backbone area (0.0.0.0) I can’t use a stub area for the switch, which would make it easier to advertise only a default route.
    • The solution is to use Redistribution Profiles. But, as there’s no comprehensive prefix-list with prefix length matching, one can’t match a default-route as follows:
      • 0.0.0.0/0 le 0
    • Instead, the 0.0.0.0/0 redist needs to be preceded (by priority) by a ‘no-redist’ object containing:
    128.0.0.0/1
    64.0.0.0/2
    32.0.0.0/3
    16.0.0.0/4
    8.0.0.0/5
    4.0.0.0/6
    2.0.0.0/7
    1.0.0.0/8
    Palo Alto – Virtual Router – Redistribution Profile – Redist Default

    The second requirement for filtering redistributed prefixes on Palo Alto is to add both Export Rules under the virtual router OSPF configuration. It took me some time to figure out that creating the Redistribution Profiles does nothing; applying them to the routing process does. It makes absolute sense once you notice.

    OSPF Ruckus configuration

    The following is the OSPF configuration of the Ruckus, including floating statics for the default routes (belts and braces):

    vrf LAN
     rd 65000:100
     ip router-id 192.168.100.1
     address-family ipv4
     ip route 0.0.0.0/0 192.168.199.0 15 distance 254 name fw01
     exit-address-family
    exit-vrf
    !
    vrf WORK
     rd 65000:101
     ip router-id 192.168.101.1
     address-family ipv4
     ip route 0.0.0.0/0 192.168.199.2 15 distance 254 name fw01
     exit-address-family
    exit-vrf
    !
    router ospf vrf WORK
    area 0.0.0.0
    !
    router ospf vrf LAN
    area 0.0.0.0
    !
    interface loopback 1
     vrf forwarding WORK
     ip address 192.168.199.253 255.255.255.255 ospf-passive
     ip ospf area 0.0.0.0
     ip ospf active
    !
    interface ve 100
     port-name LAN
     vrf forwarding LAN
     ip address 192.168.100.1 255.255.255.0
     ip ospf area 0.0.0.0
     ip ospf passive
    !
    interface ve 101
     port-name WORK-user-VLAN
     vrf forwarding WORK
     ip address 192.168.101.1 255.255.255.0 ospf-passive
     ip ospf area 0.0.0.0
     ip ospf passive
    !
    interface ve 198
     port-name WORK-Uplink-to-FW
     vrf forwarding WORK
     ip address 192.168.199.3 255.255.255.254
     ip ospf area 0.0.0.0
     ip ospf active
     ip ospf network point-to-point
    !
    interface ve 199
     port-name Uplink-to-FW
     vrf forwarding LAN
     ip address 192.168.199.1 255.255.255.254
     ip ospf area 0.0.0.0
     ip ospf active
     ip ospf network point-to-point
    !
    interface ve 400
     port-name Servers
     vrf forwarding WORK
     ip address 192.168.104.1 255.255.255.0 ospf-passive
     ip ospf area 0.0.0.0
     ip ospf passive
    !
    interface ve 700
     port-name Management
     vrf forwarding WORK
     ip address 192.168.107.1 255.255.255.0 ospf-passive
     ip ospf area 0.0.0.0
     ip ospf passive

    Checking OSPF

    Once the Palo Alto and both VRFs on the switch were configured and the vSphere Distributed Port Group issue was resolved both neighborships came up:

    Palo Alto – Virtual Router – Runtime Stats – OSPF Neighbors

    I left a couple of floating statics in place on the firewall, they’re shown below with metric 255.

    Palo Alto – Virtual Router – Runtime Stats – Route Table

    But as can be seen from the forwarding table, the OSPF learned prefixes are preferred:

    Palo Alto – Virtual Router – Runtime Stats – Forwarding Table

    And this is what things look like on the Ruckus:

    SSH@sw01#sh ip ospf vrf LAN neighbor
    Number of Neighbors is 1, in FULL state 1
    
    Port Address Pri State Neigh Address Neigh ID Ev Opt Cnt
    v199 192.168.199.1 1 FULL/OTHER 192.168.199.0 192.168.199.0 5 66 0
    
    SSH@sw01#sh ip ospf vrf WORK neighbor
    Number of Neighbors is 1, in FULL state 1
    
    Port Address Pri State Neigh Address Neigh ID Ev Opt Cnt
    v198 192.168.199.3 1 FULL/OTHER 192.168.199.2 192.168.199.0 5 66 0
    
    SSH@sw01#sh ip route vrf LAN
    Total number of IP routes: 9
    Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric
    BGP Codes - i:iBGP e:eBGP
    OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
    Destination Gateway Port Cost Type Uptime
    1 0.0.0.0/0 192.168.199.0 ve 199 110/2 O2 5d4h
    2 192.168.100.0/24 DIRECT ve 100 0/0 D 13d4h
    3 192.168.101.0/24 192.168.199.0 ve 199 110/12 O 2m40s
    4 192.168.104.0/24 192.168.199.0 ve 199 110/12 O 2m40s
    5 192.168.107.0/24 192.168.199.0 ve 199 110/12 O 2m40s
    6 192.168.199.0/31 DIRECT ve 199 0/0 D 13d4h
    7 192.168.199.2/31 192.168.199.0 ve 199 110/11 O 5d4h
    8 192.168.199.253/32 192.168.199.0 ve 199 110/12 O 2m40s
    9 192.168.199.254/32 192.168.199.0 ve 199 110/11 O 5d4h
    
    SSH@sw01#sh ip route vrf WORK
    Total number of IP routes: 9
    Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric
    BGP Codes - i:iBGP e:eBGP
    OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
    Destination Gateway Port Cost Type Uptime
    1 0.0.0.0/0 192.168.199.2 ve 198 110/2 O2 2m50s
    2 192.168.100.0/24 192.168.199.2 ve 198 110/12 O 2m50s
    3 192.168.101.0/24 DIRECT ve 101 0/0 D 4d21h
    4 192.168.104.0/24 DIRECT ve 400 0/0 D 5d4h
    5 192.168.107.0/24 DIRECT ve 700 0/0 D 5d3h
    6 192.168.199.0/31 192.168.199.2 ve 198 110/11 O 2m50s
    7 192.168.199.2/31 DIRECT ve 198 0/0 D 6d22h
    8 192.168.199.253/32 DIRECT loopback 1 0/0 D 5d21h
    9 192.168.199.254/32 192.168.199.2 ve 198 110/11 O 2m50s

    Summary

    Though I am now violating a stated requirement by advertising connected prefixes between the two VRFs, I’m not that bothered by this. The firewall filters traffic between the VRFs and matching my requirement would have meant creating two stub area networks, adding complexity. While possible, for my home network the current setup will do just fine.

    Equally, any prefixes which do not need internet connectivity are simply not added to the OSPF process and thus remain unknown outside the VRF. And prefixes which need more security like the DMZ, guest WiFi and IoT remain directly connected to the firewall.

    Conclusion

    All in all, deploying OSPF between Palo Alto and a Ruckus ICX 7250 proved to be an easy and successful exercise and no licenses were required on either device to support dynamic layer-3 routing. Both devices were at their latest available firmware.

    • Palo Alto: 11.0.0
    • Ruckus ICX 7250: 8.0.90j
    SSH@sw01>sh ver
      Copyright (c) Ruckus Networks, Inc. All rights reserved.
        UNIT 1: compiled on Jan  5 2021 at 21:08:45 labeled as SPR08090j
          (33554432 bytes) from Primary SPR08090j.bin (UFI)
            SW: Version 08.0.90jT213
          Compressed Primary Boot Code size = 786944, Version:10.1.18T215 (spz10118)
           Compiled on Mon Jul 13 09:53:15 2020
    
      HW: Stackable ICX7250-48-HPOE
    ==========================================================================
    UNIT 1: SL 1: ICX7250-48P POE 48-port Management Module
          Serial  #:DUK3849N0JS
          Software Package: ICX7250_L3_SOFT_PACKAGE   (LID: fwmINJOpFlu)
          Current License: l3-prem-8X10G
          P-ASIC  0: type B344, rev 01  Chip BCM56344_A0
    ==========================================================================
    UNIT 1: SL 2: ICX7250-SFP-Plus 8-port 80G Module
    ==========================================================================
     1000 MHz ARM processor ARMv7 88 MHz bus
     8192 KB boot flash memory
     2048 MB code flash memory
     2048 MB DRAM
    STACKID 1  system uptime is 13 day(s) 7 hour(s) 45 minute(s) 46 second(s)