More IPSEC routes for OSPF

[Eliezer Croitoru]

Hey Iain,

Well it seems like you are pointing at the problem.
The linux kernel routes doesn't exist.
Also any related IP level on the kernel level is not being presented by 
the OpenSWAN.
I am almost sure that there is a reason for that since it's suppose to 
be encrypted from end to end by not having an option to "tap" but it's 
weird to me for one of the ENDs to not have any IP level of the connection.
If it uses a kernel module it's one thing but without it its another..

I am not sure I understand whether there is a route present in any of 
the kernel levels in this setup.
It should have something in order to route these packets over the 
network interface.
What did you planned to do using the ip route script again?
run "ip route|grep default"
also "ip addr|grep -A1 ????"(???? means what?)
at this point I stop and ask if there is a way for a route what so ever 
to be existed in the linux kernel in a state which is not bound to any 
of the kernel routing tables?
Is it even real?(I am merely asking to understand if there is a whole 
different OS under the kernel).

If you can give an example of the situation forging any networking 
related data but leaving it in a sane form so we would might understand 
more about what and how in place.

Thanks,
Eliezer


On 11/11/2013 03:27 PM, Iain wrote:
> 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
>>>
>>
>