Routed IPSEC Question
-
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.
- Site A:
-
That's where I was wrong. Thank you very much.
-
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 youSystem-
/vpn_ipsec.php: The command '/sbin/ifconfig 'ipsec5000' create reqid '5000'' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Destination address required'IPSEC-
Oct 2 16:43:22 charon 12[KNL] <con5000|34> querying policy 10.6.1.1/32|/0 === 10.6.1.2/32|/0 in failed, not found
Oct 2 16:43:22 charon 12[KNL] <con5000|34> querying policy 10.6.1.1/32|/0 === 10.6.1.2/32|/0 in failed, not found -
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.
-
Here's a site that isn't working correctly-
Site A P2-
Local Remote
vti 10.6.1.1/30 10.6.1.2Site B P2-
vti 10.6.1.2/30 10.6.1.1I do have working traffic across using static routes but OSPF doesn't send/receive neighbor.
-
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
-
@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.
-
@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.
-
@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.
-
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.