<div dir="ltr">Thomas, the vpn paused and I ran the IP spi command in looks like the replay-window keeps increasing. Any ideas what that means?<div><br></div><div><div> proto esp spi 0xc6ff382c(3338614828) reqid 2(0x00000002) mode tunnel</div><div> replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)</div><div> auth-trunc hmac(sha1) 0xc609a31c3e5b7d6fa5267737c759fed017d2d6ea (160 bits) 96</div><div> enc cbc(aes) 0x4fba8977e230c1155780f03a19b90111 (128 bits)</div><div> lifetime config:</div><div> limit: soft (INF)(bytes), hard (INF)(bytes)</div><div> limit: soft (INF)(packets), hard (INF)(packets)</div><div> expire add: soft 3600(sec), hard 3600(sec)</div><div> expire use: soft 0(sec), hard 0(sec)</div><div> lifetime current:</div><div> 676746342(bytes), 703241(packets)</div><div> add 2015-12-13 20:39:21 use 2015-12-13 20:39:21</div><div> stats:</div><div><b> replay-window 533 replay 0 failed 0</b></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 3:50 PM, Mahesh Neelakanta <span dir="ltr"><<a href="mailto:neelakanta@gmail.com" target="_blank">neelakanta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Thomas. I was able to run the "ip" command but it does look like (as you mentioned) that <span style="font-size:12.8px">CONFIG_XFRM_STATISTICS is disabled (this is the amazon ubuntu 12.04 AMI). I'll try a newer release of amazon's own linux to see if it has it installed before trying a kernel recompile. Right now the ip command shows no errors (but i've restarted vpn) so i'll await it to hang again.</span><div><br></div><div>ip -s x s s spi 0xc6ff382c<br></div><div><br></div><div><div> proto esp spi 0xc6ff382c(3338614828) reqid 2(0x00000002) mode tunnel</div><div> replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)</div><div> auth-trunc hmac(sha1) 0xc609a31c3e5b7d6fa5267737c759fed017d2d6ea (160 bits) 96</div><div> enc cbc(aes) 0x4fba8977e230c1155780f03a19b90111 (128 bits)</div><div> lifetime config:</div><div> limit: soft (INF)(bytes), hard (INF)(bytes)</div><div> limit: soft (INF)(packets), hard (INF)(packets)</div><div> expire add: soft 3600(sec), hard 3600(sec)</div><div> expire use: soft 0(sec), hard 0(sec)</div><div> lifetime current:</div><div> 183887577(bytes), 191174(packets)</div><div> add 2015-12-13 20:39:21 use 2015-12-13 20:39:21</div><span class=""><div><b> stats:</b></div><div><b> replay-window 0 replay 0 failed 0</b></div></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 13, 2015 at 3:23 PM, Thomas Egerer <span dir="ltr"><<a href="mailto:hakke_007@gmx.de" target="_blank">hakke_007@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mahesh,<br>
<br>
run 'ip -s x s s spi <your_broken_inbound_spi' (as root) on your<br>
Linux-Box and check if your error statistics increase for the particular :<br>
<snip><br>
stats:<br>
replay-window 0 replay 0 failed 0<br>
<snap><br>
Also: 'grep -vw 0 /proc/net/xfrm_stat' and check for increasing<br>
counters. You will probably have to rebuild your Linux-kernel for this,<br>
unless it has the CONFIG_XFRM_STATISTICS option enabled. If the file<br>
does exist you're lucky, if not -- like on current Debian systems -- you<br>
will have to recompile.<br>
The rationale behind this is that your inbound traffic gets dropped<br>
during inbound transformation. Reasons for this may vary: failed<br>
integrity checks, replay problems, failed inbound policy check etc.<br>
<br>
Cheers,<br>
Thomas<br>
<div><div><br>
<br>
On 12/13/2015 05:06 PM, Mahesh Neelakanta wrote:<br>
> Hi,<br>
> I have a Strongswan VPN server that is being used to terminate VPN<br>
> connections with multiple endpoints. Most of the existing endpoints are<br>
> cisco, sophos, etc. Recently I have a Juniper ISG 1000 endpoint that is<br>
> posing some intermittent traffic problems.<br>
><br>
> The exact issue is that traffic over the VPN pauses after some (random)<br>
> time. The tunnel itself is up and at the next rekey traffic starts flowing<br>
> again. If I reduce the re-key time from 3600s down to 600s, the problem is<br>
> reduced significantly. I did verify with the remote side that their keylife<br>
> is 3600s. We do not have DPD enabled. There is constant traffic so there<br>
> are no periods of inactivity.<br>
><br>
> During the periods where traffic pauses, ipsec statusall report shows no<br>
> more packets in bytes_i (whereas bytes_o is still increasing).<br>
><br>
> Here is the config on our end (IPs and subnets have been changed for<br>
> security):<br>
><br>
> config setup<br>
> uniqueids = no<br>
> charondebug = ike 2<br>
><br>
> conn %default<br>
> keyingtries=%forever<br>
> dpdaction=none<br>
><br>
> conn vpn-juniper-prd<br>
> left=%defaultroute<br>
> leftid=42.75.5.14 # Our actual local IP is 10.20.1.18, we are<br>
> NATed going out<br>
> leftsubnet=<a href="http://5.22.11.21/32" rel="noreferrer" target="_blank">5.22.11.21/32</a><br>
> right=168.42.68.5<br>
> rightid=168.42.68.5<br>
> rightsubnet=<a href="http://12.23.0.0/16" rel="noreferrer" target="_blank">12.23.0.0/16</a><br>
> keyexchange=ikev1<br>
> ikelifetime=28800s<br>
> ike=aes128-sha1-modp1024<br>
> esp=aes128-sha1-modp1024<br>
> keylife=3600m<br>
> type=tunnel<br>
> compress=no<br>
> authby=secret<br>
> auto=start<br>
><br>
> Notice that the last "bytes_i" shows 145s ago (ipsec statusall output):<br>
><br>
> vpn-juniper-prd: %any...168.42.68.5 IKEv1<br>
> vpn-juniper-prd: local: [42.75.5.14] uses pre-shared key authentication<br>
> vpn-juniper-prd: remote: [168.42.68.5] uses pre-shared key authentication<br>
> vpn-juniper-prd: child: <a href="http://5.22.11.21/32" rel="noreferrer" target="_blank">5.22.11.21/32</a> === <a href="http://12.23.0.0/16" rel="noreferrer" target="_blank">12.23.0.0/16</a> TUNNEL<br>
> vpn-juniper-prd[1]: ESTABLISHED 110 minutes ago,<br>
> 10.20.1.18[42.75.5.14]...168.42.68.5[168.42.68.5]<br>
> vpn-juniper-prd[1]: IKEv1 SPIs: a8ed9dd3b567a578_i* 97dbd6dbb3683aa4_r,<br>
> pre-shared key reauthentication in 5 hours<br>
> vpn-juniper-prd[1]: IKE proposal:<br>
> AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br>
> vpn-juniper-prd{44}: REKEYED, TUNNEL, reqid 4, expires in 10 minutes<br>
> vpn-juniper-prd{44}: <a href="http://5.22.11.21/32" rel="noreferrer" target="_blank">5.22.11.21/32</a> === <a href="http://12.23.0.0/16" rel="noreferrer" target="_blank">12.23.0.0/16</a><br>
> vpn-juniper-prd{52}: INSTALLED, TUNNEL, reqid 4, ESP SPIs: c3fdc693_i<br>
> 9d90fe7f_o<br>
</div></div>> vpn-juniper-prd{52}: AES_CBC_128/HMAC_SHA1_96, 24197112 bytes_i *(26366<br>
> pkts, 145s ago*), 8889197 bytes_o (31780 pkts, 0s ago), rekeying in 10<br>
<div><div>> minutes<br>
> vpn-juniper-prd{52}: <a href="http://5.22.11.21/32" rel="noreferrer" target="_blank">5.22.11.21/32</a> === <a href="http://12.23.0.0/16" rel="noreferrer" target="_blank">12.23.0.0/16</a><br>
><br>
> During that time, we still see packets going in/out via the eth0 interface :<br>
><br>
> 03:38:52.349565 IP 10.20.1.18 > <a href="http://168.42.68.5" rel="noreferrer" target="_blank">168.42.68.5</a>:<br>
> ESP(spi=0x9d90fe7f,seq=0x7c0f), length 132<br>
> 03:38:52.363916 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd3), length 132<br>
> 03:38:52.548261 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd4), length 100<br>
> 03:38:52.564198 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd5), length 100<br>
> 03:38:53.357693 IP 10.20.1.18 > <a href="http://168.42.68.5" rel="noreferrer" target="_blank">168.42.68.5</a>:<br>
> ESP(spi=0x9d90fe7f,seq=0x7c10), length 132<br>
> 03:38:53.371666 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd6), length 132<br>
> 03:38:54.365616 IP 10.20.1.18 > <a href="http://168.42.68.5" rel="noreferrer" target="_blank">168.42.68.5</a>:<br>
> ESP(spi=0x9d90fe7f,seq=0x7c11), length 132<br>
> 03:38:54.379533 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd7), length 132<br>
> 03:38:55.250707 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd8), length 100<br>
> 03:38:55.373593 IP 10.20.1.18 > <a href="http://168.42.68.5" rel="noreferrer" target="_blank">168.42.68.5</a>:<br>
> ESP(spi=0x9d90fe7f,seq=0x7c12), length 132<br>
> 03:38:55.387695 IP 168.42.68.5 > <a href="http://10.20.1.18" rel="noreferrer" target="_blank">10.20.1.18</a>:<br>
> ESP(spi=0xc3fdc693,seq=0x5cd9), length 132<br>
><br>
><br>
> thanks,<br>
> mahesh<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.strongswan.org" target="_blank">Users@lists.strongswan.org</a><br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
><br>
<br>
<br>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org" target="_blank">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>