More IPSEC routes for OSPF

[Iain]

Hi Eliezer,

“ip addr” gives just the local addresses (it doesn’t include anything OpenSWAN related) - e.g.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
    link/ether 46:36:d3:05:b9:9a brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
	…

“ip route” gives just the default route, plus one per interface (again, nothing OpenSWAN related):

Yes, they can go up/down - although the OpenSWAN tunnel should stay up all the time.  I’m dealing with three sites where I’d like to have them connected in a loop via IPSEC, using a routing protocol over GRE tunnels to remove the loop during normal operation and correctly route traffic after any link failure.

OpenSWAN under netkey doesn’t create any interfaces at all - if you tcpdump you just see both the unencrypted and encrypted packets appearing on the same interface.  This is all done via rules that can be seen with “ip xfrm policy”.  Unfortunately the only way I can find of getting the network information on the other side of the links is via the OpenSWAN tools - “ipsec auto status”.

Iain


On 10 Nov 2013, at 22:04, Eliezer Croitoru <eliezer at ngtech.co.il> wrote:

> Hey Iain,
> 
> Since I havn't seen the other thread I was wondering to myself what is the relevant output of these steps that you gave example to?
> like
> (remove any confidential info)
> "ip addr"
> "ip route"
> 
> This OpenSWAN\IPsec tunnels goes down and up??
> I do remember from the far past that when setting\adding a route the protocol used to add these routes can be identified and if OpenSWAN do that it can be set in a way that could be identified.
> When you have for example OpenSSL tunnel it can use one of two ways handle routing:
> 1: define the interface with a mask that the tap interface will handle on the lower level stuff,
> 2: push routes on connection to the clients as "static" ones (with probably metrics or other values)
> 
> And eventually there should be a route on the machine in order to get into the other side of the tunnel or else no traffic will make it there..
> I assume it's not that complex since most of the basic route questions can be answered very fast.
> 
> Eliezer
> 
> On 11/10/2013 05:35 PM, Iain Buchanan wrote:
>> 
>> (1) parse output from “ip route” to determine the default route
>> (2) parse output from “ip address” to determine the set of local IP
>> addresses
>> (3) parse output from “ipsec auto status” looking for any of the
>> “network diagram” lines that show the connectivity where one end or the
>> other goes through a local IP address
>> (4) update the routing table with calls to "ip route"
>> (5) somehow prod Bird so that it reads the table
>> 
>> I hope I’ve horribly over-complicated things and there’s an easier way
>> to do this…  does this sound like the way to go?
>> 
>> Iain
>> 
>