Route-based VPN using VTI: Difference between revisions
Paul Wouters (talk | contribs) (VTI) |
Paul Wouters (talk | contribs) No edit summary |
||
| Line 4: | Line 4: | ||
An additional advantage of using libreswan with VTI is that you have a real interface (unlike the ''nflogXX'' interface) that supports firewalling with ''iptables'', running ''tcpdump'', etc. It even fixes tcpdump on the non-VTI device, so it really functions as the old KLIPS ipsec0 interface. | An additional advantage of using libreswan with VTI is that you have a real interface (unlike the ''nflogXX'' interface) that supports firewalling with ''iptables'', running ''tcpdump'', etc. It even fixes tcpdump on the non-VTI device, so it really functions as the old KLIPS ipsec0 interface. | ||
== Creating a virtual ethernet connection == | |||
An example configuration is shown below. It is a regular VPN connection with the additional options to turn it ito a route-based VPN. | An example configuration is shown below. It is a regular VPN connection with the additional options to turn it ito a route-based VPN. | ||
| Line 60: | Line 60: | ||
{{ ambox | nocat=true | type=important | text = You can give a VTI interface any name you want as long as it is a valid network interface name (eg less than 16 characters). You can also pick any MARK number that you want. However, in the future, libreswan will likely use mark=50/0xffffff and vti-interface=ipsec0 to create a global VTI device, so it is best if administrators avoid these values }} | {{ ambox | nocat=true | type=important | text = You can give a VTI interface any name you want as long as it is a valid network interface name (eg less than 16 characters). You can also pick any MARK number that you want. However, in the future, libreswan will likely use mark=50/0xffffff and vti-interface=ipsec0 to create a global VTI device, so it is best if administrators avoid these values }} | ||
== Create a single VTI device for all VPN clients == | |||
If you run a VPN server, it is difficult to monitor all VPN connections using tcpdump because it mixes up encrypted and unencrypted traffic, and doesn't show all packets due to the way XFRM/NETKEY steals the packet for encryption. However, if you use a VTI device, all pre-encrypt and post-decrypt traffic appears on the VTI interface. All post-encrypt and pre-decrypt traffic appears on the regular physical interface. | If you run a VPN server, it is difficult to monitor all VPN connections using tcpdump because it mixes up encrypted and unencrypted traffic, and doesn't show all packets due to the way XFRM/NETKEY steals the packet for encryption. However, if you use a VTI device, all pre-encrypt and post-decrypt traffic appears on the VTI interface. All post-encrypt and pre-decrypt traffic appears on the regular physical interface. | ||
Revision as of 00:27, 11 May 2016
VPN tunnels are normally set up based on an IPsec policy. This is called a policy-based VPN. In libreswan, these policies are specified with leftsubnet= and rightsubnet= and optionally also with leftprotoport= and rightprotport=. Some VPN devices - notably from Cisco - allow you to setup a route-based VPN. This is basically a policy-based VPN with leftsubnet=0.0.0.0/0 and rightsubnet=0.0.0.0/0. Then a special Virtual Tunnel Interface ("VTI") device is created that is attached to the IPsec policy. Now, whenever a packet is routed into this VTI device, it will be encrypted. If the packet's route misses the interface, the packet leaves in the clear. 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 this with KLIPS using the ipsec0 interface, when using XFRM/NETKEY this was not supported. As of libreswan-3.18, this is now supported using the Linux VTI interface and network MARKing.
An additional advantage of using libreswan with VTI is that you have a real interface (unlike the nflogXX interface) that supports firewalling with iptables, running tcpdump, etc. It even fixes tcpdump on the non-VTI device, so it really functions as the old KLIPS ipsec0 interface.
Creating a virtual ethernet connection
An example configuration is shown below. It is a regular VPN connection with the additional options to turn it ito 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
# route-based VPN requires marking and an interface
mark=5/0xffffffff
vti-interface=vti01
# do not setup routing because we don't want to send 0.0.0.0/0 over the tunnel
vti-routing=no
This will create the vti01 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 vti01
You can also use more complicated routing using "ip rule", shorewall or anything else.
If you want to see the pre-encrypt and post-decrypt traffic, run:
tcpdump -i vti01 -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 vti01
To see the post-encrypt and pre-decrypt (assuming your external interface is en0), run:
tcpdump -i en0 -n esp or udp port 4500
You can see information about vti tunnels using:
ip tunnel show ip -s tunnel show ifconfig vti01
 | You can give a VTI interface any name you want as long as it is a valid network interface name (eg less than 16 characters). You can also pick any MARK number that you want. However, in the future, libreswan will likely use mark=50/0xffffff and vti-interface=ipsec0 to create a global VTI device, so it is best if administrators avoid these values |
Create a single VTI device for all VPN clients
If you run a VPN server, it is difficult to monitor all VPN connections using tcpdump because it mixes up encrypted and unencrypted traffic, and doesn't show all packets due to the way XFRM/NETKEY steals the packet for encryption. However, if you use a VTI device, all pre-encrypt and post-decrypt traffic appears on the VTI interface. All post-encrypt and pre-decrypt traffic appears on the regular physical interface.
conn roadwarriors
# Regular certificate based VPN server
left=1.2.3.4
leftsubnet=0.0.0.0/0
right=%any
rightaddresspool=10.0.1.0/24
authby=rsasig
leftcert=mycert
leftid=%fromcert
auto=add
rekey=no
# Create route-based VPN using VTI
mark=12/0xffffff
vti-interface=vti02
vti-routing=yes
Now you can monitor all connected VPN clients traffic by running:
tcpdump -i vti02 -n
One minor issue is that the vti02 device will not be created until the first client connects. And so you cannot preload it with firewall rules. You can manually create the VTI device to ensure it exists before you start your firewall and libreswan by running:
# the local IP and key mark must match the above configuration ip tunnel add vti02 local 1.2.3.4 remote 0.0.0.0 key 12 ip link set ipsec0 up