Announce OSPF inside IPSec

[SubaruSama]

Hello everyone, how are you going?

I need some guidening and mentoring. Cisco beginner here. The class has changed professor, the old one was using the CORE Emulator. Now we are using the Eve-NG. I am kinda liking the Cisco world because there is material and tutorial online and is fun too. With CORE Emulator was more hardcore, but it was fun too.

I'am doing a class that we need to do the following under this context:

We have four offices, one office is the Main office and the three others are Branch Offices. And in between we have the ISP.

I'am configuring the ISP to use the RIP v2 for simplicity. For the offices we will use OSPF and OSPFv3.

But, the ISP don't need to/don't have to know our OSPF routes. The Main Office is the Backbone Area 0, and the other three offices are Area 10, 20 and 30.

So I was planning to announce the OSPF routes inside IPSec. But i am struggling so hard to understand and implement.

So, how I implement to make the OSPF announce inside IPSec Tunnels? Do I have to create a Tunnel Interface and do what? I've created some labs to try to implement, but in terms of theory, I am not understanding.

Thanks in advance!

[Seb Rupik]

Hi there,

On the outside interface of all your offices (branch and main) configure an IPSec crypto map such that each branch site is connected back to the main office via an IPSec tunnel.

Then you will need to create a tunnel interface on each branch router and have it peer back to the main office (itself will have a tunnel interface for each branch office). This will give you a hub and spoke topology with the GRE tunnel being encapsulated inside the IPsec tunnel.

You then configure OSPF to peer using the GRE tunnel interfaces. I suggest configuring the branch sites as OSPF stubs so that they just receive a default route from the main office.

Alternatively you could create IPsec/ GRE tunnels between all the routers, this would be considered a full-mesh design, which for learning purposes is OK, but ultimately does not scale very well.

https://www.cisco.com/c/en/us/td/docs/ios/12_4/interface/configuration/guide/inb_tun.html#wp1049738

cheers,

Seb.

[SubaruSama]

Thanks. Your answer helped me a lot!

[Joseph W. Doherty]

Once you have a tunnel interface (IPSec or not), you pretty much treat it, for OSPF purposes, as just another interface.

What's important, though, is the tunnel passes traffic between both end-points. Some tunnels, like GRE, can show the tunnel interface as "UP" even though you don't have end-to-end tunnel connectivity.

Also keep in mind, tunnels need to "know" how to "route" the tunnel packets separate from the traffic being routed encapsulated within the tunnel.

Good quick tests are that you can ping one tunnel's external IP from the other's external IP, and also ping one tunnel's IP from the other's tunnel IP.

Again, if both those ping tests work, you should be able to configure OSPF on the tunnel interfaces.

In the above, I've been assuming you've defined p2p tunnels between the hub and the spokes (easiest for that, using IPSec, is to use VTI tunnels). However, it's also possible to define a DMVPN (mutl-point IPSec) tunnel too. The latter takes a bit more work to configure, but once you've configured it, adding spokes becomes much, much easier. Also, depending on the configuration (and DMVPN version), DMVPN can support dynamic spoke-to-spoke traffic flows.

[SubaruSama]

Thanks. Your answer helped me a lot!

[Richard Burts · Accepted solution]

There are several things I would like to comment on for this post:

- if the objective is to send OSPF advertisements from HQ to Branch Office without the ISP being aware of the OSPF routing then the simple solution would be to configure a GRE tunnel from HQ to each branch. There is not any need of IPSEC for this.

- the original post describes HQ as being Backbone area 0 and the Branches as being area 10, 20, and 30. This is a typical way to describe them but it is not really an accurate way to think of them. A router does not belong to an area, but the router interface is what belongs to an area. Certainly HQ will have some LAN(s) that belong to area 0. And Branch 10 will have some LAN(s) that belong to area 10. Which of the routers will act as the Area Border Router? This is determined by which area does the tunnel connecting them belong to? If the tunnel belongs to area 0 then Branch 10 is the ABR and it will have interfaces in area 10 and an interface in area 0 while HQ has interfaces only in area 0. If the tunnel belongs to area 10 then HQ is the ABR and it will have interfaces in area 0 and area 10, while Branch 10 has interfaces only in area 10.

- If there is a need for encrypting the traffic between HQ and Branches then we need to consider configuring IPSEC to run between HQ and Branches. Traditional IPSEC is configured using a crypto map assigned to the interfaces used between HQ and the Branches. The crypto map uses an ACL to identify the traffic to be encrypted. Traditional IPSEC was for unicast IP traffic and as such can not run OSPF between HQ and Branches.

- to support OSPF between HQ and Branches with encryption we must combine IPSEC with a tunnel interface. The traditional approach was to configure a GRE tunnel and to use IPSEC to encrypt that traffic. A more recent approach was to configure a VTI tunnel. The advantage of the VTI tunnel is that while the GRE tunnel with encryption does require the crypto map, the VTI tunnel does not require a crypto map and so is easier to configure.

HTH

Rick

[SubaruSama]

Thanks. Your answer helped me a lot!

[Richard Burts]

You are welcome. I am glad that our suggestions and responses have been helpful. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

[SubaruSama]

Hello again!

I am using the option, that creates the VTI tunnel. But i am struggling to make the OSPF run. And as said in the second answer, I am struggling to make the areas work.

Do I have to create two tunnels on each router: one for the area that the interface belongs to and one area to connect to the backbone?

Thanks!

[Joseph W. Doherty]

Can from one tunnel end-point interface, can you ping the other tunnel's end-point interface?

Do both tunnel end-point interfaces belong to the same area?

[SubaruSama]

Yes i can ping end point interface of each router.
So, as I have 4 areas to manage and one interface belong to one area, I am really confused about that subject DD:

[Richard Burts]

Thanks for the update telling us that you are using the option to configure VTI tunnels. That should wok well. I do not understand the issue that you are currently experiencing.  One thing is clear: you should not need 2 tunnels. A single VTI tunnel should be good enough. If your OSPF areas are not working then you need to tell us more about how you have configured them. We need to see your current configs and would be helpful if you provide explanation about your topology.

HTH

Rick

[SubaruSama]

I will upload one image of the topology and the configurations of the ISP Routers and from the Main and Branch Offices. I can only upload 5 files, so: the configuration of ISP 1, 2, 3 are basically the same, only IP addresses change. And I am not uploading the SMA router config because if it works in one Office, it will work on every Office following the same configurations.

Disclaimer: Operadora means ISP.

So, in the configuration of the Main and Branch office, i've had to put the tunnels in IP addresses that RIPv2 would not to advertise. I dindnt know that the interfaces belong to areas in OSPF, thanks for explaining that.

In current configuration, every router of Main and Branch can reach each other by OSPF inside IPSec, but, everyone is in the Area 0 - Backbone, that i think this is not OK in some ways. It works and i think i can move on the project for this class, but it have some gambiarras (which in english is "McGyverism", "Alternative Engineering") in this routing configuration that it makes me feel kinda worried and sad.

So my struggle is:

How do I make the areas in OSPF in this configuration? To form a area we need at least two interfaces, if i am not wrong? But in this design, i only have one interface by area. I've tried to make this:

Put the interface of Router_PAE (Backbone) inside Area 0 and announce the IP Address 172.16.100.0 /30 and the interface of Router_CSL (Branch Office) inside Area 10 and announce the IP Address 172.16.110.4 /30. But it was a fail.

I hope that my explanation is not that confuse, english is not my primary language. If something is confuse please let me know!

Thank you guys for the effort!

[SubaruSama]

I've missed one thing: The Router_PAE and Router_CSL BELONG to Area 0, the Router_PEL belongs to Area 10. I want to make:
Router_PAE interface belongs to Area 0
Router_CSL interface belongs to Area 10 stub
Router_PEL interface belongs to Area 20 stub
Router_SMA interface belongs to Area 30 stub.

Sorry for the missing explanation.

[Joseph W. Doherty]

BTW, you don't need "ip ospf ttl-security" on your tunnel interfaces for additional security. The IPSec tunnel protects those interfaces from "outside" OSPF injection. I'm also wondering if somehow this command is causing your OSPF issues. I recommend it be removed until you have working OSPF adjacency. (Again, you don't need it with the IPSec tunnel.)

Speaking of your OSPF issues, there's no OSPF adjacency between routers? Reason I ask, if you're unable to see/reach IPs further in at a site, you need to make more than the tunnel interfaces known to OSPF.

Also BTW, on your PAE router, you can share a policy with more than one remote site. I.e. you could simplify your IPSec configuration, but for now, if you can ping across all the tunnels, you should leave it as is.

Why aren't the tunnel interfaces defined within a p2p address block (/30 or /31)? You can also define them to be p2p to OSPF, which will setup adjacency a tad faster.

BTW, I see you're mixing the two "styles" of making an interface known to OSPF (i.e. OSPF network statement and/or interface OSPF statement). I would suggest you use one or the other style. Also BTW, with OSPF, the network statement's IP and mask are used like an ACL to match interface IPs. The mask isn't needed to conform with the interface's network (like some other router protocol network statements). I would recommend, if you want to match/include specific interfaces, you use the interface's IP with a host mask in the OSPF network statement.

For better OSPF stability, you'll want to have a "static" OSPF router ID. There's a couple of ways to do that. You might use a loopback interface on the router or use a router ID declared in the OSPF process. The former, might be setup as a routable IP, and so the router's management doesn't depend on one interface being up or not.