Route-based XFRMi: Difference between revisions

From Libreswan
Jump to navigation Jump to search
(Created page with "Libreswan has new(2019) support for route based vpn using Linux XFRM interface. There will ipsec1 device where you add routes or "routing policy".")
 
No edit summary
Line 1: Line 1:
Libreswan has new(2019) support for route based vpn using Linux XFRM interface. There will ipsec1 device where you add routes or "routing policy".
Libreswan has, new in 2019, support for route based vpn using Linux XFRM interface. There will be an ipsec1 device where you can add routes or "routing policies".
 
== Route-based VPNs using libreswan XFRM interface  ==
 
{{ ambox | nocat=true | type=speedy | text = XFRMi support is EXPERIMENTAL and the API and keywords are subject to change }}
 
By default  Libreswan set up IPseec/VPN tunnels using IPsec policy alone, without "ip routing". On Linux systems this is called a policy-based VPN or IPsec. In libreswan, these policies are specified with ''leftsubnet='' and ''rightsubnet='' and optionally also with ''leftprotoport='' and ''rightprotport=''. Libreswan now, Kernel 4.19+ Libreswan 3.30+, allow you to setup a route-based VPN. A route based VPN need both policy and route. Libreswan will add the polices and basic routing in simple cases. In more advanced cases you can add addition destination based routes or routing policies. 
A ypical use case is policy covers everything 0/0 and add specific routes to send traffic via the tunnels. This is basically a policy-based VPN with leftsubnet=0.0.0.0/0 and rightsubnet=0.0.0.0/0.
 
The routes or routing policy (ip rule) go via XFRM device. Which is created  by librewan and attached to the IPsec policy. Now, whenever a packet is routed into this XFRM device/interface, it will be encrypted. Everything that goes via this interface will either encrypted or droped based on associated IPsec policy. The encrypted EPS packet is routed using main routing table. ''While this type of setup is much less secure, it is easier to manage because you just need to update the routing table instead of adding or modifying IPsec policies''. While libreswan supported route based VPN with KLIPS using the ipsec0 interface. As of libreswan-3.30, this is now supported using the Linux XFRM interface.
 
{{ ambox | nocat=true | type=warning | text = XFRMi support requires libreswan-3.30-rc or later and a recent linux-4.19.x kernel.}}
 
An additional advantage of using libreswan with XFRM is that you have a real interface (unlike the ''nflogXX'' interface) that supports firewalling with ''iptables'', running ''tcpdump'', etc. It is really functions as the old KLIPS ipsec0 interface.
 
== New ipsec.conf keywords for XFRM support ==
 
The following new keywords have been added to support VTI:
 
{| border=1
! option !! description
|-
| '''ipsec-interface=''' || The interface id device to use. no|yes|<n> this may change to just number
|}
== Creating a XFRM interface ==
 
An example configuration is shown below. It is a regular VPN connection with the additional options to turn it into a route-based VPN.
 
<pre>
conn routed-vpn
    left=192.1.2.23
    right=192.1.2.45
    authby=rsasigkey
    leftsubnet=0.0.0.0/0
    rightsubnet=0.0.0.0/0
    auto=start
    ipsec-interface=yes
 
</pre>
 
This will create the ipsec1 interface. If you want to encrypt all traffic to 10.0.0.0/8 using this VPN, simply run:
 
<pre>
ip route add 10.0.0.0/8 dev ipsec table 50
</pre>
 
To see or monitor the traffic sent before encryption or received after decrypion traffic, run:
 
<pre>
tcpdump -i ipsec1 -n
</pre>
 
And you can add firewall rules if you want:
 
<pre>
# do not allow IRC traffic on port 6666
iptables -I INPUT -j DROP -p tcp --dport 6666 -i ipsec1
</pre>
 
To see the post-encrypt and pre-decrypt (assuming your external interface is eth0), run:
 
<pre>
tcpdump -i eth0 -n esp or udp port 4500
</pre>
 
You can see information about vti tunnels using:
 
<pre>
ip -d link show dev ipsec1
ip -s link show dev ipsec1
</pre>
 
== Setting up a route-based VPN with Amazon ==
 
[ to be filled in ]
 
== XFRM related advanced use cases ==
 
=== updown script ===
 
The standard updown script (_updown.netkey) tries to autodetect what scenario is being deployed and will reconfigure the XFRM interface and network options accordingly. As this feature is still new, we expect it to not be perfect yet. If your scenario is not covered, please contact the developers and explain your use case.
 
=== interface options ===
 
Each interface has a standard set of options associated with it. These can be found in /proc/sys/net/ipv4/conf/ipsec/*. The default updown script sets some of these (rp_filter, forwarding, policy_disable) but specific use cases might require different settings. Setting disable_xfrm will cause the interface to completely fail, so do not do that.
 
=== MTU ===
 
use libreswa MTU option
 
=== XFRM interface and device ===
The xfrm device is internally attached to another network device such as eth0. Note "ipsec1@eth0" in the following output.
 
<pre>
ip -d link show dev  ipsec1
2: ipsec1@eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none 06:c7:58:c4:b2:c6 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500
    xfrm if_id 0x1 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
root@road:/#
</pre>

Revision as of 10:39, 1 November 2019

Libreswan has, new in 2019, support for route based vpn using Linux XFRM interface. There will be an ipsec1 device where you can add routes or "routing policies".

Route-based VPNs using libreswan XFRM interface

XFRMi support is EXPERIMENTAL and the API and keywords are subject to change

By default Libreswan set up IPseec/VPN tunnels using IPsec policy alone, without "ip routing". On Linux systems this is called a policy-based VPN or IPsec. In libreswan, these policies are specified with leftsubnet= and rightsubnet= and optionally also with leftprotoport= and rightprotport=. Libreswan now, Kernel 4.19+ Libreswan 3.30+, allow you to setup a route-based VPN. A route based VPN need both policy and route. Libreswan will add the polices and basic routing in simple cases. In more advanced cases you can add addition destination based routes or routing policies. A ypical use case is policy covers everything 0/0 and add specific routes to send traffic via the tunnels. This is basically a policy-based VPN with leftsubnet=0.0.0.0/0 and rightsubnet=0.0.0.0/0.

The routes or routing policy (ip rule) go via XFRM device. Which is created by librewan and attached to the IPsec policy. Now, whenever a packet is routed into this XFRM device/interface, it will be encrypted. Everything that goes via this interface will either encrypted or droped based on associated IPsec policy. The encrypted EPS packet is routed using main routing table. While this type of setup is much less secure, it is easier to manage because you just need to update the routing table instead of adding or modifying IPsec policies. While libreswan supported route based VPN with KLIPS using the ipsec0 interface. As of libreswan-3.30, this is now supported using the Linux XFRM interface.

XFRMi support requires libreswan-3.30-rc or later and a recent linux-4.19.x kernel.

An additional advantage of using libreswan with XFRM is that you have a real interface (unlike the nflogXX interface) that supports firewalling with iptables, running tcpdump, etc. It is really functions as the old KLIPS ipsec0 interface.

New ipsec.conf keywords for XFRM support

The following new keywords have been added to support VTI:

option description
ipsec-interface= yes|<n> this may change to just number

Creating a XFRM interface

An example configuration is shown below. It is a regular VPN connection with the additional options to turn it into a route-based VPN. 

conn routed-vpn
    left=192.1.2.23
    right=192.1.2.45
    authby=rsasigkey
    leftsubnet=0.0.0.0/0
    rightsubnet=0.0.0.0/0
    auto=start
    ipsec-interface=yes

This will create the ipsec1 interface. If you want to encrypt all traffic to 10.0.0.0/8 using this VPN, simply run: 

ip route add 10.0.0.0/8 dev ipsec table 50

To see or monitor the traffic sent before encryption or received after decrypion traffic, run: 

tcpdump -i ipsec1 -n

And you can add firewall rules if you want: 

# do not allow IRC traffic on port 6666
iptables -I INPUT -j DROP -p tcp --dport 6666 -i ipsec1

To see the post-encrypt and pre-decrypt (assuming your external interface is eth0), run: 

tcpdump -i eth0 -n esp or udp port 4500

You can see information about vti tunnels using: 

ip -d link show dev ipsec1
ip -s link show dev ipsec1

Setting up a route-based VPN with Amazon

[ to be filled in ]

XFRM related advanced use cases

updown script

The standard updown script (_updown.netkey) tries to autodetect what scenario is being deployed and will reconfigure the XFRM interface and network options accordingly. As this feature is still new, we expect it to not be perfect yet. If your scenario is not covered, please contact the developers and explain your use case.

interface options

Each interface has a standard set of options associated with it. These can be found in /proc/sys/net/ipv4/conf/ipsec/*. The default updown script sets some of these (rp_filter, forwarding, policy_disable) but specific use cases might require different settings. Setting disable_xfrm will cause the interface to completely fail, so do not do that.

MTU

use libreswa MTU option

XFRM interface and device

The xfrm device is internally attached to another network device such as eth0. Note "ipsec1@eth0" in the following output. 

ip -d link show dev  ipsec1
2: ipsec1@eth0: <NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none 06:c7:58:c4:b2:c6 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500
    xfrm if_id 0x1 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
root@road:/#
Retrieved from "https://libreswan.org/wiki/index.php?title=Route-based_XFRMi&oldid=21751"