More IPSEC routes for OSPF
Hi, I've a question about getting OpenSWAN and Bird routing working together. Hopefully someone here can point me in the right direction! There was an email from Michael Ludvig on the 8th July 2013 about exporting IPSEC routes for OSPF usage. The conclusion seemed to be that Bird can’t read the routes set up by OpenSWAN, and the only solution is to have a script running that exports the routes for Bird’s use into a separate table. I’m in pretty much the same position. I’ve tried Ondrej Zajicek’s suggestion of using transport mode IPSEC links, but this doesn’t seem to create visible routes (I’m using the netkey stack, which may be the issue). At the moment I’ve got GRE tunnels working on top of the IPSEC links, and if I enable debugging mode I can see instances of Bird communicating with one another over them (but not sending any of the OpenSWAN link information). I’d like to try and create routes that Bird can read, but I’m not certain how to extract the routing information nicely. (Part of the problem may be that the IPSEC links go through VPNs.) If I do an “ip xfrm policy” the output only refers to the gateways (i.e. where the NAT takes place), not the machines that I want to gain access to. I think what I need is a route saying “for remote_network/mask use the default route on this machine”. This could be written to a dedicated routing table which bird would read and send on. I’m guessing packets would then turn up and be processed by the xfrm rules and head on through the tunnel. It looks like the way to do this is to have a little service running that will regularly: (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
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
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@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
Hi Iain, On 13:27 Mon 11 Nov , 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):
I don't know about OpenSWAN, but StrongSWAN places the VPN routes in a different routing table (220 by default). You can guess this is happening by having a look at the relevant rules (`ip rule list'). If this is the case with OpenSWAN as well, you can just create an additional kernel protocol in BIRD and learn the routes from that special routing table. Apollon
I had a check, but OpenSWAN doesn't seem to do this (at least with netkey) - I don't see any additional routing tables. Given the time I've spent so far with OpenSWAN I'll give the script route a go, then investigate StrongSWAN later. From looking at the website it looks much better documented - I had to buy the OpenSWAN book before I could work out what was going on. Iain On 11 November 2013 15:45, Apollon Oikonomopoulos <apollon@skroutz.gr>wrote:
Hi Iain,
On 13:27 Mon 11 Nov , 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):
I don't know about OpenSWAN, but StrongSWAN places the VPN routes in a different routing table (220 by default). You can guess this is happening by having a look at the relevant rules (`ip rule list'). If this is the case with OpenSWAN as well, you can just create an additional kernel protocol in BIRD and learn the routes from that special routing table.
Apollon
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@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
Sorry, yes - I should have made that clearer. I’m using the netkey stack with OpenSWAN, which does the transforms in the kernel. The routes become visible on an “ip xfrm show”. I’m doing an “ip addr” to list all the local addresses, then an “ipsec auto —status” looking for connections that are up (STATE_QUICK_R2). I can then pull out the networks on the other side of all the connections. I’ve discovered how to get OpenSWAN to allow multiple networks on the other end of the route, but it is difficult to work out what the internal routes look like. I’ll try switching to the klips stack and see if this makes the routes visible. Adding what I thought were the right routes manually didn’t work - this is not really a bird-related problem yet, but more a lack of understanding on my part of how the OpenSWAN routing is working! Iain On 14 Nov 2013, at 23:50, Eliezer Croitoru <eliezer@ngtech.co.il> wrote:
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@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
Hey Iain, Nice to know these little details. I would say that it is good to ask instead of wondering in the "unknown" place of thinking by yourself. I have seen that some afraid to ask and they are left by them-selfs for weeks trying to figure out something so tiny which somebody already "just know". With hope you would be able to find a reasonable solution that fits you. Best Regards, Eliezer On 17/11/13 22:14, Iain wrote:
Sorry, yes - I should have made that clearer. I’m using the netkey stack with OpenSWAN, which does the transforms in the kernel. The routes become visible on an “ip xfrm show”.
I’m doing an “ip addr” to list all the local addresses, then an “ipsec auto —status” looking for connections that are up (STATE_QUICK_R2). I can then pull out the networks on the other side of all the connections.
I’ve discovered how to get OpenSWAN to allow multiple networks on the other end of the route, but it is difficult to work out what the internal routes look like.
I’ll try switching to the klips stack and see if this makes the routes visible. Adding what I thought were the right routes manually didn’t work - this is not really a bird-related problem yet, but more a lack of understanding on my part of how the OpenSWAN routing is working!
Iain
Hi, On 10-11-2013 16:35, Iain Buchanan wrote:
I’m in pretty much the same position. I’ve tried Ondrej Zajicek’s suggestion of using transport mode IPSEC links, but this doesn’t seem to create visible routes (I’m using the netkey stack, which may be the issue). At the moment I’ve got GRE tunnels working on top of the IPSEC links, and if I enable debugging mode I can see instances of Bird communicating with one another over them (but not sending any of the OpenSWAN link information).
The idea here is to have IPsec protected GRE tunnels over which one can talk OSPF. There wouldn't be any IPsec routes to (re)distribute in that case (as there's only transport ones). If you have other IPsec "routes" (policies in fact) that you want to insert into OSPF, then you'll need one of two alternatives indeed: * Have a script parse the IPsec policies, or * Use the KLIPS stack instead of NETKEY, which gives you routes you can insert into OSPF nicely (this is what I do). Regards, Ruben
Thanks Ruben, I'll give the script option a go. Iain On 11 November 2013 14:19, Ruben Laban <r.laban+lists@ism.nl> wrote:
Hi,
On 10-11-2013 16:35, Iain Buchanan wrote:
I’m in pretty much the same position. I’ve tried Ondrej Zajicek’s suggestion of using transport mode IPSEC links, but this doesn’t seem to create visible routes (I’m using the netkey stack, which may be the issue). At the moment I’ve got GRE tunnels working on top of the IPSEC links, and if I enable debugging mode I can see instances of Bird communicating with one another over them (but not sending any of the OpenSWAN link information).
The idea here is to have IPsec protected GRE tunnels over which one can talk OSPF. There wouldn't be any IPsec routes to (re)distribute in that case (as there's only transport ones). If you have other IPsec "routes" (policies in fact) that you want to insert into OSPF, then you'll need one of two alternatives indeed:
* Have a script parse the IPsec policies, or * Use the KLIPS stack instead of NETKEY, which gives you routes you can insert into OSPF nicely (this is what I do).
Regards, Ruben
I've got my script going, but I can't get the resulting routes into Bird. I add the routes to a new kernel table which I point a "protocol kernel" block at (see below). The routes I'm adding don't go via a particular interface as OpenSWAN doesn't create any interfaces - I'm just putting them in as "target network" via "local ip address" (this might be one problem - I've tried both the internal IP and the GRE tunnel endpoint). When I start Bird up I receive warnings about my new route with a strange next-hop address. It then seems to completely ignore the route as "birdc" produces no output when I do a "show route". Do I need to specify my local IPSEC policies in a different format, or am I missing something in the configuration? log syslog all; debug protocols all; protocol kernel { learn; persist; scan time 10; import all; export none; kernel table 1; # This is my new table populated with IPSEC policies } protocol device { scan time 10; } protocol ospf myOSPF { import all; export all; area 0 { interface "tunOtherRouter" { # This is the GRE tunnel cost 5; type ptp; hello 5; retransmit 2; wait 10; dead 20; }; }; } On 12 November 2013 21:41, Iain Buchanan <iainbuc@gmail.com> wrote:
Thanks Ruben, I'll give the script option a go.
Iain
On 11 November 2013 14:19, Ruben Laban <r.laban+lists@ism.nl> wrote:
Hi,
On 10-11-2013 16:35, Iain Buchanan wrote:
I’m in pretty much the same position. I’ve tried Ondrej Zajicek’s suggestion of using transport mode IPSEC links, but this doesn’t seem to create visible routes (I’m using the netkey stack, which may be the issue). At the moment I’ve got GRE tunnels working on top of the IPSEC links, and if I enable debugging mode I can see instances of Bird communicating with one another over them (but not sending any of the OpenSWAN link information).
The idea here is to have IPsec protected GRE tunnels over which one can talk OSPF. There wouldn't be any IPsec routes to (re)distribute in that case (as there's only transport ones). If you have other IPsec "routes" (policies in fact) that you want to insert into OSPF, then you'll need one of two alternatives indeed:
* Have a script parse the IPsec policies, or * Use the KLIPS stack instead of NETKEY, which gives you routes you can insert into OSPF nicely (this is what I do).
Regards, Ruben
On Thu, Nov 14, 2013 at 11:04:21AM +0000, Iain Buchanan wrote:
I've got my script going, but I can't get the resulting routes into Bird. I add the routes to a new kernel table which I point a "protocol kernel" block at (see below). The routes I'm adding don't go via a particular interface as OpenSWAN doesn't create any interfaces - I'm just putting them in as "target network" via "local ip address" (this might be one problem - I've tried both the internal IP and the GRE tunnel endpoint).
If you need to create some routes just for the purpose of exporting them to BIRD, you could create them as unreachable routes: ip route add unreachable 192.168.1.0/24 So you don't have to specify a next hop or an iface. When such route is exported to OSPF, only the prefix matters. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (6)
-
Apollon Oikonomopoulos -
Eliezer Croitoru -
Iain -
Iain Buchanan
-
Ondrej Zajicek -
Ruben Laban