[strongSwan] Strongswan using VTI
Ryan Ruel
ryan at ryanruel.com
Thu Dec 18 15:19:22 CET 2014
Not sure if this is an option for your application, but another choice
which functions very similarly to VTI's is to use an IPsec+GRE tunnel.
Security policy configuration is very simple (you just need any "any any"
transform for the tunnel endpoint addresses), and you can tunnel anything
you want through the GRE using routes and such, just like with a VTI.
The only downside is an additional 4 (8 if you use a tunnel key) bytes of
per-packet overhead.
But it's well supported on Cisco and works fine with Strongswan.... create
a GRE tunnel interface in Linux, set up the SA, and install routes for
whatever you want over the GRE interface.
/Ry
On Thu, Dec 18, 2014 at 8:15 AM, Noel Kuntze <noel at familie-kuntze.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
>
> This [1] is the commit that was referenced from your email
> Currently, strongswan does not support VTIs. The reason is, that
> VTIs use XFRM policies with marks. If you set strongSwan up to create
> a connection with marks associated with it, it will insert policies and
> states
> that all have marks associated with them. That means, that incoming
> esp/ah/espinudp
> packets will have to have the correct mark set to it before they reach
> XFRM LOOKUP [1].
> However, the standard way VTIs get set up is with a wildcard policy for
> esp packets.
> That means, that you need to manually mark esp traffic in *mangle INPUT. I
> wrote an email [2] about that.
> If you use VTIs, you do not need to set the mark rules in *mangle
> POSTROUTINg and *mangle OUTPUT.
> The VTI does that for you implicitly.
> Furthermore, you probably need to set up routing yourself, instead of
> having strongSwan
> do it (Because of the RP filter. Look into table 220 to see what routes
> strongSwan adds.).
> Logging martians [3] will probably help you figure out what happens and
> The return value descriptio of recvmsg [4] from its manpage says, that
> EAGAIN is nothing to worry about
> by itself. There is simply no data to be read from the buffer. I do not
> think that from this point of progress on,
> the problem is not the VTI itself anymore.
>
> [1]
> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commit;h=44bdc4a2f8d3a25c81f768c7b92d5165e42dfd2d
> [2] http://inai.de/images/nf-packet-flow.png
> [3] https://lists.strongswan.org/pipermail/users/2014-November/006942.html
> [4] net.ipv4.conf.all.log_martians = 0
> net.ipv4.conf.default.log_martians = 0
> net.ipv4.conf.<interface>.log_martians = 0
> [5] EAGAIN or EWOULDBLOCK
> The socket's file descriptor is marked O_NONBLOCK and no
> data is
> waiting to be received; or MSG_OOB is set and no
> out-of-band
> data is available and either the socket's file
> descriptor is
> marked O_NONBLOCK or the socket does not support
> blocking to
> await out-of-band data.
>
>
>
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
>
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 18.12.2014 um 13:06 schrieb Olivier PELERIN:
> > Tried to follow this kernel commit - it does not work
> >
> > https://lists.ubuntu.com/archives/kernel-team/2013-November/034116.html
> >
> > It seems utterly broken
> >
> >
> >
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > From: olivier_pelerin at hotmail.com
> > To: avalentin at marcant.net; users at lists.strongswan.org
> > Date: Thu, 18 Dec 2014 10:11:23 +0100
> > Subject: Re: [strongSwan] Strongswan using VTI
> >
> > Will try it out
> >
> > When I strace my ping I'm getting (Resource temporarily unavailable)
> when we receive the echo-reply
> >
> > sendmsg(3, {msg_name(16)={sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("10.0.0.2")},
> msg_iov(1)=[{"\10\0\312\350Y\362\00096\231\222T\0\0\0\0K+\0\0\0\0\0\0\20\21\22\23\24\25\26\27"...,
> 64}], msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=, ...},
> msg_flags=0}, 0) = 64
> > recvmsg(3, 0x7fff93401680, 0) = -1 EAGAIN (Resource
> temporarily unavailable)
> > gettimeofday({1418893623, 10985}, NULL) = 0
> > gettimeofday({1418893623, 11029}, NULL) = 0
> >
> >
> >
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > Date: Thu, 18 Dec 2014 09:20:26 +0100
> > From: avalentin at marcant.net
> > To: users at lists.strongswan.org
> > Subject: Re: [strongSwan] Strongswan using VTI
> >
> > Hi !
> >
> > I hate this vti stuff. Only trouble and much to complex.
> > Try disable the policies on the vti0 interface. It's under
> proc/sys/class/net/..vti0/*{policies|xfrm}*
> >
> > Kind regards,
> >
> > André
> >
> > Am 18.12.2014 um 09:04 schrieb Olivier PELERIN:
> >
> >
> > Unfortunately that does not help.
> >
> > Stats are not showing any drops!
> >
> > manowar python # cat /sys/class/net/vti0/statistics/rx_bytes
> > 199752
> > manowar python # ping 10.0.0.2 -I vti0
> > PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of data.
> > ^C
> > --- 10.0.0.2 ping statistics ---
> > 2 packets transmitted, 0 received, 100% packet loss, time 999ms
> >
> > manowar python # cat /sys/class/net/vti0/statistics/rx_bytes
> > 199920
> >
> > All errors counters under vti0 are remaining to zero.
> >
> >
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > Date: Wed, 17 Dec 2014 08:42:26 -0500
> > Subject: Re: [strongSwan] Strongswan using VTI
> > From: ryan at ryanruel.com <mailto:ryan at ryanruel.com>
> > To: olivier_pelerin at hotmail.com <mailto:olivier_pelerin at hotmail.com>
> > CC: users at lists.strongswan.org <mailto:users at lists.strongswan.org>
> >
> > When I've seen this happen before (interface sees the traffic, ping
> or some other process does not), it usually means it's getting dropped by
> the Kernel.
> >
> > It's usually RP-filtering... you can try to turn it off:
> >
> > # echo 0 > /proc/sys/net/ipv4/conf/vti/rp_filter
> > # echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
> >
> > I wouldn't leave if off permanently, but it might help you get
> further with testing where the packets are going.
> >
> > /Ryan
> >
> > On Wed, Dec 17, 2014 at 7:15 AM, Olivier PELERIN <
> olivier_pelerin at hotmail.com <mailto:olivier_pelerin at hotmail.com>> wrote:
> >
> > Kernel wise I'm on 3.18.1. I saw few links on the internet about
> this prerouting mangling rules but it's very unclear if it's needed or
> not. I would assume the ikey in the ip tunnel command is enough.
> >
> > I've modified the config by specifying the local address [
> instead of using %any] now I've added left=10.1.1.1
> >
> > ipsec statusall
> > Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux
> 3.18.1-gentoo, x86_64):
> > uptime: 2 minutes, since Dec 17 13:07:54 2014
> > malloc: sbrk 2416640, mmap 0, used 377184, free 2039456
> > worker threads: 11 of 16 idle, 5/0/0/0 working, job queue:
> 0/0/0/0, scheduled: 2
> > loaded plugins: charon ldap aes des rc2 sha1 sha2 md5 random
> nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp
> dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink
> resolve socket-default stroke updown xauth-generic
> > Listening IP addresses:
> > 192.168.255.134
> > 10.1.1.1
> > 10.0.0.1
> > Connections:
> > VTI: 10.1.1.1...10.1.1.254 IKEv2
> > VTI: local: [10.1.1.1] uses pre-shared key
> authentication
> > VTI: remote: [10.1.1.254] uses pre-shared key
> authentication
> > VTI: child: 0.0.0.0/0 <http://0.0.0.0/0> ===
> 0.0.0.0/0 <http://0.0.0.0/0> TUNNEL
> > Routed Connections:
> > VTI{1}: ROUTED, TUNNEL
> > VTI{1}: 0.0.0.0/0 <http://0.0.0.0/0> === 0.0.0.0/0 <
> http://0.0.0.0/0>
> > Security Associations (1 up, 0 connecting):
> > VTI[1]: ESTABLISHED 2 minutes ago,
> 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]
> > VTI[1]: IKEv2 SPIs: 2be274863074302d_i*
> 720fa6a0e8c28b09_r, pre-shared key reauthentication in 2 hours
> > VTI[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
> > VTI{1}: INSTALLED, TUNNEL, ESP SPIs: c8da39c8_i
> 938ec319_o
> > VTI{1}: AES_CBC_256/HMAC_SHA1_96, 12848 bytes_i (152
> pkts, 23s ago), 12348 bytes_o (147 pkts, 23s ago), rekeying in 39 minutes
> > VTI{1}: 0.0.0.0/0 <http://0.0.0.0/0> === 0.0.0.0/0 <
> http://0.0.0.0/0>
> >
> >
> > Now I'm one step further. I see bytes_i and bytes_o increasing.
> >
> > running tcpdump directly on the VTI interface I see the
> echo-reply arriving
> >
> > manowar python # tcpdump -nNi vti0
> > error : ret -1
> > tcpdump: verbose output suppressed, use -v or -vv for full
> protocol decode
> > listening on vti0, link-type RAW (Raw IP), capture size 262144
> bytes
> > 13:09:37.669100 IP 10.0.0.1 > 10.0.0.2 <http://10.0.0.2>: ICMP
> echo request, id 18052, seq 4366, length 64
> > 13:09:37.669564 IP 10.0.0.2 > 10.0.0.1 <http://10.0.0.1>: ICMP
> echo reply, id 18052, seq 4366, length 64
> > 13:09:38.669208 IP 10.0.0.1 > 10.0.0.2 <http://10.0.0.2>: ICMP
> echo request, id 18052, seq 4367, length 64
> > 13:09:38.669691 IP 10.0.0.2 > 10.0.0.1 <http://10.0.0.1>: ICMP
> echo reply, id 18052, seq 4367, length 64
> >
> > Still traffic seems not to reach the ping process
> >
> > ping 10.0.0.2 -I vti0
> > PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of
> data.
> >
> > vti0 sees the traffic but not the ping process??
> >
> >
> >
> >
> >
> >
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> -
> > Subject: Re: [strongSwan] Strongswan using VTI
> > From: ryan0751 at gmail.com <mailto:ryan0751 at gmail.com>
> > Date: Wed, 17 Dec 2014 06:50:47 -0500
> > CC: users at lists.strongswan.org <mailto:
> users at lists.strongswan.org>
> > To: olivier_pelerin at hotmail.com <mailto:
> olivier_pelerin at hotmail.com>
> >
> > I was just trying to get this to work the other day myself and
> also had problems with the routing.
> >
> > It wasn’t clear to me if you still need to create the PREROUTING
> mangle rules. such as:
> >
> > # mangle PREROUTING rules:
> > iptables -t mangle -A PREROUTING -s 192.168.10.0/24 <
> http://192.168.10.0/24> -d 192.168.11.0/24 <http://192.168.11.0/24>
> > -j MARK --set-mark 32
> > iptables -t mangle -A PREROUTING -p esp -s 10.1.3.2 -d 10.1.1.2
> -j MARK
> > --set-mark 32
> >
> > From what I had read the Kernel might have been patched to no
> longer require this?
> >
> > Have you checked the SA stats on the Linux box (setkey -D or
> using the ip xfrm command) to see if the packets are matching the SA and
> are being decrypted?
> >
> > /Ryan
> >
> > On Dec 17, 2014, at 6:08 AM, Olivier PELERIN <
> olivier_pelerin at hotmail.com <mailto:olivier_pelerin at hotmail.com>> wrote:
> >
> > Dear Strongswan alias,
> >
> > I'm trying a VTI config between a linux box and a cisco
> router.
> >
> > I've created a VTI interface on my linux
> >
> > ip tunnel add vti0 mode vti local 10.1.1.1 remote 10.1.1.254
> okey 32 ikey 32
> > ip link set vti0 up
> > ip addr add 10.0.0.1/30 <http://10.0.0.1/30> remote
> 10.0.0.2/30 <http://10.0.0.2/30> dev vti0
> >
> > conn VTI
> > keyexchange=ikev2
> > ike=aes256-sha1-modp1024
> > esp=aes256-sha1!
> > leftid=10.1.1.1
> > leftauth=psk
> > leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>
> > rightauth=psk
> > right=10.1.1.254
> > rightid=10.1.1.254
> > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0>
> > mark=32
> > auto=route
> >
> >
> >
> >
> > manowar python # ipsec statusall
> > Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux
> 3.18.1-gentoo, x86_64):
> > uptime: 114 seconds, since Dec 17 11:53:47 2014
> > malloc: sbrk 2416640, mmap 0, used 373840, free 2042800
> > worker threads: 11 of 16 idle, 5/0/0/0 working, job queue:
> 0/0/0/0, scheduled: 2
> > loaded plugins: charon ldap aes des rc2 sha1 sha2 md5
> random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12
> pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr
> kernel-netlink resolve socket-default stroke updown xauth-generic
> > Listening IP addresses:
> > 192.168.255.134
> > 10.1.1.1
> > 10.0.0.1
> > Connections:
> > VTI: %any...10.1.1.254 IKEv2
> > VTI: local: [10.1.1.1] uses pre-shared key
> authentication
> > VTI: remote: [10.1.1.254] uses pre-shared key
> authentication
> > VTI: child: 0.0.0.0/0 <http://0.0.0.0/0> ===
> 0.0.0.0/0 <http://0.0.0.0/0> TUNNEL
> > Routed Connections:
> > VTI{1}: ROUTED, TUNNEL
> > VTI{1}: 0.0.0.0/0 <http://0.0.0.0/0> ===
> 0.0.0.0/0 <http://0.0.0.0/0>
> > Security Associations (1 up, 0 connecting):
> > VTI[1]: ESTABLISHED 109 seconds ago,
> 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]
> > VTI[1]: IKEv2 SPIs: e1e9a005055323ab_i*
> 78c7cc9d34a5886f_r, pre-shared key reauthentication in 2 hours
> > VTI[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
> > VTI{1}: INSTALLED, TUNNEL, ESP SPIs: c8031e20_i
> 37b2a5a2_o
> > VTI{1}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 1848
> bytes_o (22 pkts, 8s ago), rekeying in 44 minutes
> > VTI{1}: 0.0.0.0/0 <http://0.0.0.0/0> ===
> 0.0.0.0/0 <http://0.0.0.0/0>
> >
> >
> > I do have ESP in
> >
> > manowar python # tcpdump -nNi netio0
> > error : ret -1
> > tcpdump: verbose output suppressed, use -v or -vv for full
> protocol decode
> > listening on netio0, link-type EN10MB (Ethernet), capture
> size 262144 bytes
> > 12:07:57.840726 IP 10.1.1.1 > 10.1.1.254 <http://10.1.1.254>:
> ESP(spi=0x37b2a5a2,seq=0x2bf), length 132
> > 12:07:57.841405 IP 10.1.1.254 > 10.1.1.1 <http://10.1.1.1>:
> ESP(spi=0xc8031e20,seq=0x2bf), length 132
> > 12:07:58.840971 IP 10.1.1.1 > 10.1.1.254 <http://10.1.1.254>:
> ESP(spi=0x37b2a5a2,seq=0x2c0), length 132
> > 12:07:58.841336 IP 10.1.1.254 > 10.1.1.1 <http://10.1.1.1>:
> ESP(spi=0xc8031e20,seq=0x2c0), length 132
> >
> >
> > But it seems not be decapsulated by the kernel.
> >
> > Any ideas why?
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org <mailto:
> Users at lists.strongswan.org>
> > https://lists.strongswan.org/mailman/listinfo/users
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> > https://lists.strongswan.org/mailman/listinfo/users
> >
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> > https://lists.strongswan.org/mailman/listinfo/users
> >
> >
> > Mit freundlichen Grüßen
> > André Valentin
> >
> > Systemadministration / Projektkoordination
> > --
> > MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
> > Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
> > URL: http://www.marcant.net | http://www.global-m2m.com
> >
> > Internet * Netzwerk * Mobile Daten
> > Citrix Silver Solution Advisor
> >
> > Geschäftsführer: Thorsten Hojas
> > Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
> > _____________________________________________________________________
> > Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr
> > bis 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir
> > Ihnen gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
> > mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
> > Sie können natürlich auch gerne jederzeit unter support at marcant.net
> <mailto:support at marcant.net>
> > ein Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
> >
> >
> >
> > Mit freundlichen Grüßen
> > André Valentin
> > Systemadministrator
> > --
> > MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
> > Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
> > URL: http://www.marcant.net | http://www.global-m2m.com
> >
> > Internet * Netzwerk * Mobile Daten
> > Citrix Silver Solution Advisor
> >
> > Geschäftsführer: Thorsten Hojas
> > Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
> > ___________________________________________________________
> > Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
> > 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
> > gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
> > mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
> > Sie können natürlich auch gerne jederzeit unter support at marcant.net ein
> > Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
> >
> > _______________________________________________ Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> >
> > _______________________________________________ Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.strongswan.org
> > https://lists.strongswan.org/mailman/listinfo/users
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJUktN3AAoJEDg5KY9j7GZYN1gP/AktHBKFVcK1ZtvuSUTwXolX
> SNGvPNB5NBGn2OEicmaB8GVz+++bJKaAcPCantZ31KpmteSIAekDoL8WWgFVeQlO
> VLyv4d0acnP7htQU9q5njRrNVcs0xG+9N+dRCcuuRis7oBsrWNiEKbWXq4c7IABL
> 3jnmRhOYYGOw+nP9MheusaktN/StrbIBXWv9msluZmVaZSIdfqDw1kRZ2mQmzTRu
> i7EIxPK7AyXJT4AmBw9mn3g6p6zn177Pf2lOyioMnE3bPNkcCMBXxm+ZquDB7aIZ
> UWkJnEzGGdtYz5mtjKAlUgqRxN1rCIikCJ+j+YEb6qNJafdIXBB5ucZn1+jeO2Zi
> LsovoZb9BqvMV9BrIMvZ4X7ci9FXshS/U0AygwrWIibtYo3dPBFe5simz0MMFDfL
> oD7nXINnd3o1PkKttztd5MJ4OZVIlp1vy6w7bOdCvFDTAD2x06r3Yu8Bq8VL97St
> cLElWFLGu00bydTP/qRCyG6+WvRFagYvq33AADfouWDPh4MziJM6LP8SYjZEvozx
> 3D8JoFL+xSeWduIzADI2ZdVKjPOWGGFsijrMmIwrzNO3Q2EhuQuF+iUuIqbcFThs
> eEc9wvTS/yJJwz/LvqMqXQYNoMEvmDLCpJKUGFSBPdoXxRaHlB8TNd0Wa/IlRIEn
> NApkhY/ZEA7tDYpyGRIF
> =9tsQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141218/bc1479fe/attachment-0001.html>
More information about the Users
mailing list