[strongSwan] "sending keep alive" seems breaking VPN connection
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Mon Jun 4 20:44:55 CEST 2018
Hello,
The log you provide is not useful. Please provide a log file as the HelpRequests page says and use the exact configuration from the page to create it.
Kind regards
Noel
On 04.06.2018 00:10, Gilles Printemps wrote:
> Hi,
> To illustrate my issue and in addition to the configuration described previously,
> - I enabled more trace in the ipsec.conf [charondebug="ike 2, knl 3, cfg 0"].
> [Log can be downloaded using the following link "www.printemps.cc/Temp/syslog.txt <http://www.printemps.cc/Temp/syslog.txt>"]
> - I tried to launch a set of commands [See "cmds.txt" in attachment]
>
> Executed commands:
> - After starting ipsec, I establish the VPN connection.
> As you can see in "cmds.txt", connection is established correctly
> - I execute the following command to see if the traffic for the user is going through the VPN
> $ sudo -u vpn -i -- curl ipinfo.io <http://ipinfo.io/>
> Result is the expected one.
> - A little bit later (After 17:14:34 in the syslog.02/Less than 2mins after previous cmd], I execute the same command
> Result fails with the following status: curl: (6) Could not resolve host: ipinfo.io <http://ipinfo.io/>
> - I decide to wait and after 2 additional minutes, I try to execute again the same command
> Command is not failing but I can see that my IP address allocated but the VPN has changed.
>
> To summarise,
> - VPN connection is established correctly and the route defined through the scripts are working
> Traffic for the "vpn" user is going through the VPN
> - After few minutes (less than 2) without any activity through the VPN, connection is no more working.
> I have to wait additional minutes, to get a working connection.
> - Few minutest later, connection is killed again...
>
> - Why is the VPN connection killed after less than 2 minutes?
> - Is the issue come from the VPN server or from my configuration?
> - Why is it so long to re-establish a new working connection?
> - How to keep the connection longer?
>
> If someone can check the log and see where the issue is coming from, I would really appreciate because, currently, I'm lost...
> Thanks for your help,
> Gilles
>
> On Tue, May 29, 2018 at 10:51 AM, Gilles Printemps <gprintemps at gmail.com <mailto:gprintemps at gmail.com>> wrote:
>
> Hi,
> After several days, I finally have a configuration which force all the traffic from a specific user to be routed from a VPN via a vti interface.
>
> After creating the vti interface and establishing the different route, I can successfully check if the traffic is currently routed using the following commands:
>
> sudo -u vpn -i -- curl ipinfo.io <http://ipinfo.io>
>
> ping -I vti0 www.google.com <http://www.google.com>
>
>
> Unfortunately, after a period d of time, it is no more working and I can see several error packets on the vti interface. several minute later, connection is established again with the VPN but with a new connection (IP has changed).
>
>
> It seems this issue occurs after "sending keep alive" from IKE.
>
> Is something missing or wrong in my ipsec.conf?
>
>
> Thanks for your help,
>
> Gilles
>
>
> /etc/ipsec.conf
>
> config setup
> charondebug="ike 2, knl 3, cfg 0"
> conn %default
> ### Key Exchange
> keyexchange=ikev2
> ike=aes256-sha256-ecp384 # Algorithms used for the connection [phase1/ISAKMP SA]
> esp=aes256-sha256-ecp384,aes256-sha256 # Algorithms offered/accepted for a phase2 negotiation
> conn VPN
> dpdaction=restart
> leftupdown=/etc/ipsec.script.sh <http://ipsec.script.sh>
> left=%defaultroute
> leftsourceip=%config4
> leftauth=eap-mschapv2
> eap_identity=gprintemps
> right=free-nl.hide.me <http://free-nl.hide.me>
> rightauth=pubkey
> rightid=%any
> rightsubnet=0.0.0.0/0 <http://0.0.0.0/0>
> auto=start
> mark=2
>
>
> /etc/ipsec.script.sh <http://ipsec.script.sh>
>
> set -o nounset
> set -o errexit
> VPN_USER="vpn"
> VTI_INTERFACE="vti0"
> case "${PLUTO_VERB}" in
> up-client)
> ip tunnel add "${VTI_INTERFACE}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \
> okey "${PLUTO_MARK_OUT%%/*}" ikey "${PLUTO_MARK_IN%%/*}"
> ip link set "${VTI_INTERFACE}" up
> sysctl -w "net.ipv4.conf.${VTI_INTERFACE}.disable_policy=1"
> sysctl -w "net.ipv4.conf.${VTI_INTERFACE}.rp_filter=2"
> ip addr add ${PLUTO_MY_SOURCEIP} dev "${VTI_INTERFACE}"
> if [[ `ip rule list | grep -c 0x1` == 0 ]]; then
> ip rule add from all fwmark 0x1 lookup $VPN_USER
> fi
> # Launch routing script
> /etc/ipsec.route.sh <http://ipsec.route.sh>
> ;;
> down-client)
> ip tunnel del "${VTI_INTERFACE}"
> ;;
> esac
>
>
> /etc/ipsec.route.sh <http://ipsec.route.sh>
>
> export TABLE_ID="vpn"
> export VPN_USER="vpn"
> export VTI_INTERFACE="vti0"
> export LOCAL_IP="10.211.55.3"
>
> # Flush iptables rules
> iptables -F -t nat
> iptables -F -t mangle
> iptables -F -t filter
> # Mark packets from $VPN_USER
> iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
> iptables -t mangle -A OUTPUT ! --dest $LOCAL_IP -m owner --uid-owner $VPN_USER -j MARK --set-mark 0x1
> iptables -t mangle -A OUTPUT ! --src $LOCAL_IP -j MARK --set-mark 0x1
> iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
> # Deny $VPN_USER to access other interfaces than lo
> # iptables -A OUTPUT ! -o lo -m owner --uid-owner $VPN_USER -j DROP
> # Allow $VPN_USER to access lo and VPN interfaces
> iptables -A OUTPUT -o lo -m owner --uid-owner $VPN_USER -j ACCEPT
> iptables -A OUTPUT -o $VTI_INTERFACE -m owner --uid-owner $VPN_USER -j ACCEPT
>
> # Allow response from $VPN_INTERFACE
> iptables -A INPUT -i $VTI_INTERFACE -m conntrack --ctstate ESTABLISHED -j ACCEPT
> # Masquarade packets on $VPN_INTERFACE
> iptables -t nat -A POSTROUTING -o $VTI_INTERFACE -j MASQUERADE
> # Routing rules
> GATEWAY=$(ifconfig $VTI_INTERFACE |
> egrep -o '([0-9]{1,3}\.){3}[0-9]{1,3}' |
> egrep -v '255|(127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})' | tail -n1)
> ip route replace default via $GATEWAY table $TABLE_ID
> ip route append default via 127.0.0.1 dev lo table $TABLE_ID
> ip route flush cache
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180604/8a6726b7/attachment.sig>
More information about the Users
mailing list