Okey, one correction
left=%hostname is working for one of my tunnels, but not the other. See
below.
The working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Azure
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(EAP_ONLY) ]
sending packet: from 85.24.x.x[500] to 137.135.x.x[500] (380 bytes)
received packet: from 137.135.x.x[500] to 85.24.x.x[500] (204 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
authentication of '137.135.x.x' with pre-shared key successful
IKE_SA Azure[2] established between
85.24.x.x[hostname]...137.135.x.x[137.135.x.x]
scheduling reauthentication in 27923s
maximum IKE_SA lifetime 28463s
connection 'Azure' established successfully
The non-working:
sending cert request for "C=US, O=Let's Encrypt, CN=Let's Encrypt
Authority X3"
authentication of 'hostname' (myself) with pre-shared key
establishing CHILD_SA Wesafe
generating IKE_AUTH request 1 [ IDi CERTREQ IDr AUTH SA TSi TSr
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 85.24.x.x[500] to 94.254.x.x[500] (380 bytes)
received packet: from 94.254.x.x[500] to 85.24.x.x[500] (76 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'Wesafe' failed
ipsec.secrets
%hostname 137.135.x.x : PSK "xxxx"
%hostname 94.254.x.x : PSK "xxxxx"
I don't know why Strongswan seems to send my local certificate, it
should only be used when roadwarriors connect.
Den 2017-04-21 kl. 10:16, skrev Dusan Ilic:
Hi!
I have some issues, please read on.
1. I have one side of the IP-sec tunnel with dynamic IP (associated
with a dynamic hostname), I would like not need to change the
"left"-parameter in both ipsec.conf and ipsec.secrets whenever the
local WAN IP changes, so I have tried putting "left = %any" or "left =
%hostname". Now, with %hostname (preferable) it wont connect, but with
%any it does connect, sometimes. I can see in the documentation that
%any does a local root lookup if the local host is initiating the
connection, but only accepting all local IP-adresses if it responds to
the remote peer initiation. In my case ths always work when the remote
peer is initiating the connection, but if my local end initiates it
(ie start=route) it seem to choose the wrong public source IP to
connect from.
In my case, my local gateway running Strongswan have multiple public
interfaces (but only one should be used for IP-sec tunnels), se below
route information:
default
nexthop via 90.225.x.x dev vlan845 weight 1
nexthop via 10.248.x.x dev ppp0 weight 256
nexthop via 85.24.x.x dev vlan847 weight 1
nexthop via 46.195.x.x dev ppp1 weight 1
My gateway is configured to use 10.248.0.x as "default route" (highest
weight/priority), but when Strongswan tried to initiate the tunnel it
seems to always default too the last route, 46.195.x.x, and this wont
work as the remote peer is expecting 85.24.x.x. Now, is there a way to
tell Strongswan to use this IP/interface? I hope "left=%hostname"
would work, because the hostname is dynamically ponting to the IP at
interface vlan847, but as already stated this isn't working either.
Any suggestions?
2. Probably also cause by the above routing setup (wild guess), I also
have IKEv2 EAP roadwarrior connectin in Strongswan on the same
interface. The Strongswan client on Android connects to my public
hostname, and everything works (and in this setup I can have
left=%hostname on the server), it's a full tunnel with
leftsubnet=0.0.0.0/0. However, all VPN-clients are beeing routed out
on this same interface the connect to, so the third route above is
being automatically used (vlan847) instead of the second route on ppp0
(with higher weight/priority). Locally connected clients to the
gateway all gets routed out on ppp0, but not VPN-clients. Why is this,
and what can be done to correct this? The reason for me wanting the
VPN clients connecting on vlan847 also routed on the the Internet on
ppp0 is simple, ppp0 is a VPN connection from the gateway out to the
Internet.
I can add that in strongswan.conf I have changed so that all
VPN-routes added by Strongswan is done in the standard, main routing
table (instead of 220), so technically the VPN-clients should be
routed the same as the local clients by the gateway.
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
