[strongSwan] Strongswan using VTI
Ryan Ruel
ryan at ryanruel.com
Wed Dec 17 14:42:26 CET 2014
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> 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 === 0.0.0.0/0 TUNNEL
> Routed Connections:
> VTI{1}: ROUTED, TUNNEL
> VTI{1}: 0.0.0.0/0 === 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 === 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: ICMP echo request, id 18052, seq
> 4366, length 64
> 13:09:37.669564 IP 10.0.0.2 > 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: ICMP echo request, id 18052, seq
> 4367, length 64
> 13:09:38.669691 IP 10.0.0.2 > 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
> Date: Wed, 17 Dec 2014 06:50:47 -0500
> CC: users at lists.strongswan.org
> To: 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 -d 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>
> 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 remote 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
> rightauth=psk
> right=10.1.1.254
> rightid=10.1.1.254
> rightsubnet=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 === 0.0.0.0/0 TUNNEL
> Routed Connections:
> VTI{1}: ROUTED, TUNNEL
> VTI{1}: 0.0.0.0/0 === 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 === 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: ESP(spi=0x37b2a5a2,seq=0x2bf),
> length 132
> 12:07:57.841405 IP 10.1.1.254 > 10.1.1.1: ESP(spi=0xc8031e20,seq=0x2bf),
> length 132
> 12:07:58.840971 IP 10.1.1.1 > 10.1.1.254: ESP(spi=0x37b2a5a2,seq=0x2c0),
> length 132
> 12:07:58.841336 IP 10.1.1.254 > 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
> https://lists.strongswan.org/mailman/listinfo/users
>
>
> _______________________________________________
> 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/20141217/9733b84d/attachment-0001.html>
More information about the Users
mailing list