Friday, 10 February 2012

OSPF lab - with Check Point and Vyatta

Just for fun, I thought it would be useful to build a simple OSPF lab in VMware with the help of Vyatta's open-source router software. On top of this, I've added in three Check Point R75.20 gateways to also run seperate OSPF instances over VPN VTIs to check out route-based VPN (because for all these years of working with Check Point I've been far too lazy to stray far from the simple domain based VPN setup).

So - the ingredients for this lab are...

  • VMware ESXi 4.1 (not essential - you can probably get it working in any other flavour hypervisor, maybe even VirtualBox if you like pain and suffering).
  • 3 Desktop Clients (Windows XP - any OS will be fine but you will need a Windows machine to be able to use Smart Dashboard for firewall policy).
  • 3 Virtual Router VMs (Linux/Other 32bit, 512MB RAM, 4GB HDD, 3 virtual NICS)
  • 3 Firewall VMs (Linux / Redhat5 32bit, 2 CPUs if possible, 512MB RAM, 10GB HDD, 2 virtual NICs).
  • 9 Virtual Networks named Net_CoreX (1-3), Net_EdgeX(1-3), Net_IntX(1-3). These should be attached to the VMs as per the topology below.

Suggested lab topology



1. The first thing to set up is the Vyatta virtual routers in your hypervisor. You will need to attach the virtual networks to your VM according to the diagram. Usually, the ordering of the virtual NICs in VMware matches up nicely with the guest OS. So NIC 1,2 and 3 will present in the OS as eth0, eth1, eth2. This helps when you need to match up the networks to the virtual NICs.

2. Next, you should configure the Vyatta software on each router. This is a lot easier than the documentation might have you believe. Don't misread this as the Vyatta docs being bad - instead read as the software is so easy to use with the Tab and '?' combo you don't really need to refer to the docs. 
Give each Vyatta VM a name to match the topology diagram - something cunning like 'VRx' depending on which router it is. Then, configure the NICs according to the network they are on.
If you're too lazy to tab your way through the config - try this for configuring interfaces on VR1 as an example...



configure

set interface ethernet eth0 address 3.0.0.1/29

set interface ethernet eth1 address 1.0.0.1/29

set interface ethernet eth2 address 172.16.1.1/24

commit


3. Once you have your IPs configured, test your connectivity between the external NICs of the routers. Once happy, you can either test the connectivity fully by adding static routes to each for the 'Edge' networks - or just dive straight in and setup OSPF which, with hindsight, is actually a bit easier than faffing with static routes. I won't delve into the depths of OSPF because I'll probably get it wrong - so some nice links to Wikipedia and Cisco are at the end of the post. Essentially though, you will break your network up into areas. Area 0.0.0.0 is reserved for the backbone area (note: although it's in dotted quad format - it certainly isn't an IP address you're using). Whether it's correct or not, I've setup some extra areas here to break things down further. So, there is a backbone area 0.0.0.0 and edge areas of 0.0.0.1, 0.0.0.2 and 0.0.0.3.
I've added the OSPF config for VR1 below - you can figure out the config for the other routes yourself (you did want to learn something, right?).

protocols {
    ospf {
        area 0.0.0.0 {
            network 1.0.0.0/29
            network 3.0.0.0/29
        }
        area 0.0.0.1 {
            network 172.16.1.0/24
        }
        redistribute {
            connected {
            }
        }
    }
}


4. Repeat this on the other VRs but replace the networks above with the relevant directly connected networks. Once it's setup - you should be able to verify that OSPF is sending and receiving OSPF LSA's with

show ip route

(if that shows up as an invalid command, you're probably within configure mode, just add 'run' to the start to break out temporarily). Now you should be able to ping other routers edge network addresses.

5. You're now ready to start messing with the Check Point side of things. I'm going to assume you have already built your three Check Point gateways. In my setup, I opted for standalone gateways to save on resources and to keep things nice and simple. If you haven't already done it - you will need to run 'pro enable' and reboot to activate the advanced networking components of Secure Platform (in production - these are licensable features).

6. Once setup as per the topology again, it's easiest to install a policy of 'any, any, accept'; we can worry about playing with policies once everything is configured. Make sure the topologies are correct on each gateway object.

7. Create two objects to represent the peer gateways (We'll create this from the context of FW1). I chose to create these with Interoperable Devices but if they're externally managed Check Point gateways that should be fine too. Make sure to set the external interface correctly to the 172.16.x.2 address.

8. Create an empty group for each peer gateway to use as the encryption domain (we're setting up route-based VPNs here so no encryption domain as such). Then, select this group under peer object > topology > VPN Domain > Manually defined.


9. Create a new VPN community and add in your local gateway object plus the two peers. Give it a fitting name, such as OSPF-vpn then go to through the configurations for the community. The default encryption settings will be fine - just so long as you keep them consistent. The only changes to make are to add the shared secrets in for the peer gateways and to disable NAT within the community.

10. Next, before installing this we will need to configure the VTIs from the VLI using 'vpn shell'. This is a little odd in how it works and stacks command levels in a linux-ish structure ('/show/interface/all' for example) but thankfully there isn't much config to be had here.
We need to add a VTI, which is a point-to-point link used to tunnel VPN traffic between peers. In this instance, we need to add two VTI interfaces, one for FW2 and one for FW3. We'll call them vtiFW2 and vtiFW3. The syntax for this is '/interface/add/numbered <LocalIP> <RemoteIP> <Peer name as per policy> <meaningful interface name>'.
Local IP is the local address of the tunnel interface (this should be internal, unused and definitely not the external or other IP address. The RemoteIP is the remote VTI address, not the remote external address!

Adding a VTI through the VPN Shell

11. Once you've added these - you can get a summary with '/show/interface/summary/all' or '/show/interface/detailed/all' and then the interfaces will also show up with your chosen names when using ifconfig. Something else worth knowing - you have to be in the root of the vpn shell to quit - or use '/quit' from any other level.

12. Now, go back to the dashboard and find your local gateway (extFW1 in case you forgot) and update the interfaces with Topology > Get... > Interfaces with topology.

Topology showing new VTI interfaces

13. Accept these changes and install the policy. Fingers crossed, you'll get the green tick.

14. Back to the CLI and this time we'll be going into the routing shell to setup OSPF. To enter this mode, run 'cligated'. You'll be whisked to a Cisco'ish type shell. After 'enable' and 'configure terminal' you'll be ready to go.
15. Some more sample config here for the routing setup - again you can find your way through with Tab and '?'


router ospf 1
    advertise-subnet
    network 192.168.102.1 0.0.0.0 area 0.0.0.0
    network 192.168.103.1 0.0.0.0 area 0.0.0.0
    redistribute direct
    redistribute ospf
    enable
    exit
interface vtiFW2
    ip ospf 1 area 0.0.0.0
    enable
    exit
interface vtiFW3
    ip ospf 1 area 0.0.0.0
    enable
    exit
exit

16. Once this is in place, exit configuration mode and issue a 'show running-configuration' to see what you've setup and check it roughly matches the above. Now - repeat steps 5 to 16 for the other gateways, remembering to configure the relevant gateways as the peers. Then, after some more finger crossing, you should have a VPN mesh with OSPF running over VTI's! So test it out by disabling VTI links and seeing if the firewalls are clever enough to route around the fault :)

No comments:

Post a Comment