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: [email protected]
To: [email protected]
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: [email protected]
To:
[email protected]
CC:
[email protected]
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
<[email protected]> 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:
[email protected]
Date: Wed, 17 Dec 2014 06:50:47 -0500
CC:
[email protected]
To:
[email protected]
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 <[email protected]>
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
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
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 [email protected]
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 [email protected] ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
