[strongSwan] "sending keep alive" seems breaking VPN connection

[Noel Kuntze]

Hi,

I think that's wrong. The acquires show that the packets are between the IKE ports, which doesn't seem to work over the tunnel. This shouldn't happen in the first place. It's a side effect of the mark and PBR rules that are installed:
The VTI uses the mark (0x)2

> /etc/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 <--- redirects the packets
>             fi
>             # Launch routing script
>             /etc/ipsec.route.sh
>             ;;
>         down-client)
>             ip tunnel del "${VTI_INTERFACE}"
>             ;;
>     esac
> 
> 
> /etc/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 <- this is always true here!
>     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 | <- use ip route with, for example, json output.
>               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 <- Use the interface name instead
>     ip route append default via 127.0.0.1 dev lo table $TABLE_ID <- this is superfluous.
>     ip route flush cache <- this is superfluous.

The problem is that "iptables -t mangle -A OUTPUT ! --src $LOCAL_IP -j MARK --set-mark 0x1" applies to all packets here. Add the owner match here, too and it should work.

Kind regards

Noel

On 05.06.2018 11:11, Tobias Brunner wrote:
> Hi Gilles,
> 
>> Following your comment, it seems the issue comes first for "Hide.me"
>> which is not answering correctly to the "CREATE_CHILD_SA"
>> request.
> 
> No, the problem is that an acquire is generated in the first place.  The
> behavior by the peer is definitely not correct, but that's not the
> actual problem (and fixing it wouldn't get you anything).
> 
>>    - Does it mean that if they fix this issue, I will not lose anymore
>> the connection on my side?
> 
> No, as I said, you have to fix your routing/iptables setup so the
> correct source IP is used for traffic that's routed via VTI device.
> 
>> If it is not possible for them to change the behaviour of their VPN, you
>> mentioned I may handle it on my side by fixing the route when the
>> virtual IP is created. Can you provide more details?
> 
> Install routes with `src ${PLUTO_MY_SOURCEIP}` so that source IP is used
> or NAT traffic to the virtual IP before it hits VTI device and the IPsec
> policies.
> 
> Regards,
> Tobias
> 

-------------- 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/20180605/15297ab8/attachment-0001.sig>