OSPF6 over IPv6 VTI Tunnel Interfaces

pete35

Hi David,

some months ago i run into a similar problem. It looks like, that all the tunnels (openvpn, ipsec) doesnt provide the Link Local adresses of IPv6. OSPF needs them to work. I think, assigning the RFC4193 Address to the tunnels doesnt help in this case.

See my findings:
https://forum.netgate.com/topic/131073/frr-multiple-issues-and-problems

If anyone can help in this case or has some more knowledge, feel free to post here …

JKnott

@pete35 said in OSPF6 over IPv6 VTI Tunnel Interfaces:

some months ago i run into a similar problem. It looks like, that all the tunnels (openvpn, ipsec) doesnt provide the Link Local adresses of IPv6. OSPF needs them to work. I think, assigning the RFC4193 Address to the tunnels doesnt help in this case.

Fire up Wireshark or Packet Capture and see what's actually happening. IIRC, OSPF announces itself via mulitcast. There should also be Neighbour Advertisements advising of the address in general. Do you see those? Also, the tunnels don't provide the link local addresses, the end devices do. However, link local addresses will not be routed. Are there any routers in between? It must be a direct connection between OSPF routers, which could include a tunnel.

Davidkmessenger

@pete35 Thanks Pete, it seems that the IPv6 implementation of FRR is flaky at best on pfSense. I've done more testing since with FRR and OSPF6 and I've found that neighbour relationships are never actually formed. This is taking tunnels out of the equation completely. I have three different devices. pfSense, Sophos UTM and VyOS. All in area 0 and all on a single LAN segment. I get full neighbour relationships in OSPF but with OSPF6 the pfSense box is forever stuck in init state. An extract from the VyOS router:

dave@dooku:~$ show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.47.33.1 100 Full/Backup 34.614s 10.47.33.1 eth3:10.47.33.2 0 0 0
10.47.33.3 1 Full/DROther 38.046s 10.47.33.3 eth3:10.47.33.2 0 0 0

dave@dooku:~$ sh ipv6 ospfv3 neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
10.47.33.1 100 00:00:31 Init/DR 17:58:16 eth3[DR]
10.47.33.3 1 00:00:34 Full/BDR 00:33:37 eth3[DR]

I generally understand why people haven't bothered to implement IPv6 when so many issues arise with various vendors. Palo Alto and Cisco at least seem to have all their ducks in a row.

JKnott

@Davidkmessenger said in OSPF6 over IPv6 VTI Tunnel Interfaces:

This is taking tunnels out of the equation completely

????

All a tunnel does is produce a path for IP packets. It should make no difference to OSPF whether the next hop is via tunnel, Ethernet, Frame Relay or wet string. You set up the connection and OSPF should see the interface. Is that not what's happening? As for Unique local address, might those be blocked by firewall rules. They're the same sort of deal as RFC1918 addresses on IPv4 and not allowed on the Internet.

Davidkmessenger

I'm aware of what a tunnel is thanks. What exactly don't you understand? Using OSPF6 as part of the FRR package on pfSense 2.4.4-RELEASE-p3 on an ethernet segment doesn't form neighbour relationships. Have you actually tried this kind of setup yourself and had success?
@pete35 Has demonstrated extensive testing and found various issues.

JKnott

@Davidkmessenger

pete35 mentions pfSense doesn't provide the link local address for OSPF. OSPF needs an address, could be link local, ULA or GUA.

Regardless, what does Packet Capture or Wireshark show? Do you see the Hello packets go out?

I just took a look at my OpenVPN addresses. Here's what I see:

ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::216:17ff:fea7:f2d3%ovpns1 prefixlen 64 scopeid 0x9

The link local address for the other end has to come from the other end, as normally there is no other way to get it. For example, if this were an Ethernet connection, you would not know the link local address of another device, until it sent some traffic using it. Why should a VPN be any different?

As I mentioned above, ULAs might be blocked. On the OpenVPN page there is this setting:

Block private networks and loopback addresses
Blocks traffic from IP addresses that are reserved for private networks per RFC 1918 (10/8, 172.16/12, 192.168/16) and unique local addresses per RFC 4193 (fc00::/7) as well as loopback addresses (127/8). This option should generally be turned on, unless this network interface resides in such a private address space, too.

Is that setting selected? If so, that could be your problem.

Again, a VPN simply provides an IP connection. How that connection is made is irrelevant.

JKnott

One other thing, does IPv4 OSPF work?

Davidkmessenger

@JKnott Thanks for your reply. Just to ensure I am being clear, this is taking tunnel mechanisms completely out of the equation. The pfSense box has it's LAN interface in an ethernet segment containing two other machines. I have configured OSPF and OSPFv3 in area 0 on all machines. OSPF for IPv4 works without issue on the box. OPSF6 / OSPFv3 does not. The two other machines on the segment form a neighbour relationship but the pfSense box is stuck in init state. I've performed packet captures, hello messages are sent and received which is confirmed as the neighbour sees when I change the router priority of the pfSense box. This pfSense is a SG-1100 but I also threw a VMware virtual machine in to the LAN and the same applies. Neigbour relationship never forms. OSPF for IPv4 however is working well.

JKnott

@Davidkmessenger said in OSPF6 over IPv6 VTI Tunnel Interfaces:

Thanks for your reply. Just to ensure I am being clear, this is taking tunnel mechanisms completely out of the equation. The pfSense box has it's LAN interface in an ethernet segment containing two other machines.

This is a bit different from your original question, where you were talking about tunnels and IPSec. "It looks like, that all the tunnels (openvpn, ipsec) doesnt provide the Link Local adresses of IPv6. OSPF needs them to work. " This is why it is essential to break down problems into smaller bites. By demonstrating the same problem on Ethernet, you have proven that it has nothing to do with tunnels.

Now you can investigate an OSPF problem, rather than an OSPF via tunnel problem.

jimp

OSPF6 works fine on its own. I haven't tried it on VTI in a while, but there are some known issues with IPv6 on VTI anyhow, so that may not be an OSPF6 issue, but a VTI issue.

I have a basic OSPF6 setup going and it didn't take anything special:

"WAN" has active OSPF6 with a cost of 10 (it's a lab setup, easier than connecting a DMZ or something else)
LAN is passive
Main OSPF6 tab just has enable, area 0.0.0.0 (the only one supported for OSPF6 in upstream FRR currently), and redistribute connected checked.

It sees a similarly-configured neighbor without issue and exchanges routes:

O>* 2001:db8:1:dea0::/64 [110/110] via fe80::20d:b9ff:fe33:f71, vmx0, 21:18:09
O>* 2001:db8:1:df20::/64 [110/10010] via fe80::208:a2ff:fe0c:c7fe, vmx0, 21:18:09

Make sure you are on the most recent version of the FRR package, or at least 0.5.2, since I worked on OSPF6 fairly recently (Early June).

Davidkmessenger

@jimp Well that is interesting as I have a similar setup on the LAN interface (Used as a transit network rather than for hosts) and an adjacency never forms with those neighbours.
As mentioned earlier the neighbour relationship forms between the Sophos UTM and VyOS devices without issue.
Package version is 0.6.3 on an SG-1100.
Similarly I have only the interface added, enable OSPF6 routing, router ID, area 0.0.0.0 and redistribute kernel routes. I have however tried multiple different versions of settings.

jimp

I'd check your rules then to make sure you are not accidentally blocking IPv6 OSPF (its own protocol, not TCP/UDP), or somehow blocking the multicast traffic it needs to form neighbor adjacencies.

Check with packet captures that the hellos are leaving and arriving where expected.

Davidkmessenger

I've triple checked my setup here to ensure I've not missed something. OSPFv3 neighbours never form. Also performed packet captures and can see the neighbours sending OSPF packets inbound. Stuck in init status indicates that the neighbours are never forming. Unless of course there is some strange reason that the multicast traffic required is being blocked at layer 2...

Davidkmessenger

The reason for my IPv6 OSPFv3 neighbours not coming up was because I had configured gateway. I was staring right at the answer yet I had overlooked it numerous times...

"If this interface has a gateway, rules on this interface will have reply-to by default. This will interfere with the operation of OSPFv3 on the interface. Add a rule at the top of the ruleset for this interface to pass IPv6 OSPF traffic with Disable reply-to checked in Advanced Options."

Also works well with the gateway removed. (Was using the gateway for failover static routes)

Not strictly the topic of why this thread was opened in the first place but nevertheless thought best to come back and update on my experience.