Routed IPSEC Question

jimp

The transit network is a /30 between one site and another. That's the only P2 you need for a tunnel, nothing else.

To connect 15 sites you still need 15 P1s but with only one VTI P2 each for a unique tunnel network to each location.

nc_tech

@jimp So does the transit network need to be identical on both ends of the tunnel?

jimp

The addresses need to be in the same network, or example:

Site A:
- Local: x.x.x.1/30
- Remote: x.x.x.2
Site B:
- Local: x.x.x.2/30
- Remote: x.x.x.1

The next site could be .5<->.6, and so on.

nc_tech

That's where I was wrong. Thank you very much.

nc_tech

Are there any issues setting up OSPF over this connection?

Setup seems fairly forward and I was able to get it working on a few sites. Even with identical settings (different transport subnets of course) some sites will not get neighbor information. I listed some errors below that appear in some of the systems that aren't working.
Creating static routes on the tunnels does work and I am using that in the meantime until I can figure out what is wrong with OSPF (or my settings). I did try both FFR and Quagga, i got a few up with quagga last night but nothing since then.
Thank you

System-
/vpn_ipsec.php: The command '/sbin/ifconfig 'ipsec5000' create reqid '5000'' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Destination address required'

jimp

Sounds like maybe something isn't quite right in the VTI local/remote addresses. I've used OSPF and BGP and didn't have any problems with either one.

Make sure it's set to x.x.x.Y/30 for local and x.x.x.Z for remote in the VTI P2.

I haven't had a bunch of these all going at once though, I think the most I had in my lab was 2 or 3.

nc_tech

@jimp

Here's a site that isn't working correctly-

Site A P2-
Local Remote
vti 10.6.1.1/30 10.6.1.2

Site B P2-
vti 10.6.1.2/30 10.6.1.1

I do have working traffic across using static routes but OSPF doesn't send/receive neighbor.

djamp42

I have FRR OSPF running on top of IPSEC VTI.. The only issue i see is FRR OSPF is seeing the ipsec vti interface as un-numbered, so none of the /30s of the tunnels get re-distributed.

ipsec1000 is up
  ifindex 14, MTU 1500 bytes, BW 0 Mbit 
  This interface is UNNUMBERED, Area 0.0.0.0
  MTU mismatch detection: enabled
  Router ID 10.X.0.1, Network Type POINTOPOINT, Cost: 10
  Transmit Delay is 1 sec, State Point-To-Point, Priority 1
  No backup designated router on this network
  Multicast group memberships: OSPFAllRouters
  Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5
    Hello due in 4.417s
  Neighbor Count is 1, Adjacent neighbor count is 1

-----------------------------------------------------------------------
Under status and interfaces

IPSEC Interface (opt7, ipsec1000)
Status: up
IPv4 Address: 10.X.X.130
Subnet mask IPv4: 255.255.255.252
Gateway IPv4: 10.X.X.129
IPv6 Link Local: fe80::21b:21ff:fea8:d628%ipsec1000
MTU: 1500
In/out packets: 0/190925 (0 B/19.64 MiB)
In/out packets (pass): 0/190925 (0 B/19.64 MiB)
In/out packets (block): 0/7 (0 B/724 B)
In/out errors: 0/0
Collisions 0

jimp

@djamp42 said in Routed IPSEC Question:

I have FRR OSPF running on top of IPSEC VTI.. The only issue i see is FRR OSPF is seeing the ipsec vti interface as un-numbered, so none of the /30s of the tunnels get re-distributed.

FRR does the same with point-to-point OpenVPN interfaces.

In a way it's better than quagga because that means you don't have to worry about learning a route for your own /30 address via some other OSPF path, but at the same time it means traffic between the endpoints won't route more than one hop away easily.

djamp42

@jimp said in Routed IPSEC Question:

In a way it's better than quagga because that means you don't have to worry about learning a route for your own /30 address via some other OSPF path, but at the same time it means traffic between the endpoints won't route more than one hop away easily.

Yeah i could see that, but it would be shocking if a connected route got removed for a OSPF route. The only reason i even notice this is because without the /30 being re-distributed traceroute is broken. Regardless works pretty well for my limited testing.

jimp

@djamp42 said in Routed IPSEC Question:

Yeah i could see that, but it would be shocking if a connected route got removed for a OSPF route. The only reason i even notice this is because without the /30 being re-distributed traceroute is broken. Regardless works pretty well for my limited testing.

It happened all the time with multi-WAN OpenVPN configs in the past. The route would get stuck in the table if an OpenVPN instance went down and then you'd have to manually remove the route to bring it back. We worked around it a few different ways, but it was always annoying.

nc_tech

My issues were related to the transport network. It seems regardless of the transport network's mask (we tested with /30) it treated it like a /24. Once we moved to using a separate full 24 for each IPSEC tunnel OSPF came right up.

Thank you for all of the help, this made my life a lot easier.