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 <[email protected]> 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
