| View previous topic :: View next topic |
| Author |
Message |
digimag
Guru
Joined: 14 May 2005
Posts: 451
Location: Toulouse, France
|
 Posted: Tue Sep 05, 2017 5:17 pm Post subject: [solved] Strongswan auth ok, but not establishing tunnel |
 |
|
Hi,
So, I'm trying to use Strongswan in order to establish a secure channel with a Cisco gateway. It's a IPSec site-to-site VPN (IKEv1 / ESP).
It seems like the Security Association is established, but for some reason the tunnel is never established, I just see endless exchanges of some "INFORMATIONAL_V1" requests:
| Code: | # ipsec up my_vpn_tunnel
initiating Main Mode IKE_SA my_vpn_tunnel[1] to other.end.pub.ip
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from local.ip.behind.nat[500] to other.end.pub.ip[500] (268 bytes)
received packet: from other.end.pub.ip[500] to local.ip.behind.nat[500] (132 bytes)
parsed ID_PROT response 0 [ SA V V ]
received NAT-T (RFC 3947) vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from local.ip.behind.nat[500] to other.end.pub.ip[500] (244 bytes)
received packet: from other.end.pub.ip[500] to local.ip.behind.nat[500] (304 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: 7e:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
received unknown vendor ID: 1f:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from local.ip.behind.nat[4500] to other.end.pub.ip[4500] (108 bytes)
received packet: from other.end.pub.ip[4500] to local.ip.behind.nat[4500] (92 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
IKE_SA my_vpn_tunnel[1] established between local.ip.behind.nat[local.end.pub.ip]...other.end.pub.ip[other.end.pub.ip]
scheduling reauthentication in 85632s
maximum IKE_SA lifetime 86172s
received packet: from other.end.pub.ip[4500] to local.ip.behind.nat[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 236334172 [ HASH N((24576)) ]
received (24576) notify
received packet: from other.end.pub.ip[4500] to local.ip.behind.nat[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 3644459270 [ HASH N(DPD) ]
generating INFORMATIONAL_V1 request 144232008 [ HASH N(DPD_ACK) ]
sending packet: from local.ip.behind.nat[4500] to other.end.pub.ip[4500] (92 bytes)
received packet: from other.end.pub.ip[4500] to local.ip.behind.nat[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 2357496430 [ HASH N(DPD) ]
[…] |
The last four lines just keep repeating…
My /etc/ipsec.conf:
| Code: | config setup
charondebug="all"
strictcrlpolicy = no
nat_traversal = yes
conn %default
conn my_vpn_tunnel
forceencaps = yes
aggressive = no
leftsubnet=a.local.ip/32
left=local.ip.behind.nat
leftid=local.end.pub.ip
leftsourceip=a.local.ip
right=other.end.pub.ip
rightid=other.end.pub.ip
leftauth=psk
rightauth=psk
ike=aes256-sha1-modp1024,aes256-sha256-modp1024
esp=aes128-sha1-modp1024,aes128-sha1-modp1536
ikelifetime=24h
lifetime=8h
keyexchange=ikev1
auto = add
modeconfig = push
dpdaction = hold
type = tunnel |
Any ideas?
I'm rather new to this, and spent a few days already trying to understand what is going on… Maybe the solution is actually simple?
_________________
Sacha
Last edited by digimag on Thu Sep 07, 2017 6:43 am; edited 1 time in total |
|
| Back to top |
|
 |
chiefbag
Guru
Joined: 01 Oct 2010
Posts: 542
Location: The Kingdom
|
| Posted: Wed Sep 06, 2017 3:11 pm Post subject: |
|
|
| Code: | | IKE_SA my_vpn_tunnel[1] established between local.ip.behind.nat[local.end.pub.ip]...other.end.pub.ip[other.end.pub.ip] |
Looks like your phase 1 is up.
Do you have protocol 50/esp allowed on your firewall for phase 2?
Do you need "modeconfig = push" ? |
|
| Back to top |
|
|
digimag
Guru
Joined: 14 May 2005
Posts: 451
Location: Toulouse, France
|
| Posted: Thu Sep 07, 2017 6:25 am Post subject: |
|
|
| chiefbag wrote: | | Code: | | IKE_SA my_vpn_tunnel[1] established between local.ip.behind.nat[local.end.pub.ip]...other.end.pub.ip[other.end.pub.ip] |
Looks like your phase 1 is up.
Do you have protocol 50/esp allowed on your firewall for phase 2?
Do you need "modeconfig = push" ? |
Thank you for your response, but I just figured this out yesterday!
It was just because a used a /24 for the right subnet setting, while on the other side, they configured several individual IPs (/32) instead of putting everything under /24.
Unfortunately for a misconfiguration like that, there is no proper error message, making it quite hard to debug.
I also had to get rid of the leftsourceip/rightsourceip settings (I've put them because someone with similar issues got it to work with these). I don't really understand, what are they for? The doc says "source IP inside the tunnel", but what does it mean, and what practical use would be? 
_________________
Sacha |
|
| Back to top |
|
|
chiefbag
Guru
Joined: 01 Oct 2010
Posts: 542
Location: The Kingdom
|
| Posted: Thu Sep 07, 2017 7:12 am Post subject: |
|
|
| Quote: | | I also had to get rid of the leftsourceip/rightsourceip settings (I've put them because someone with similar issues got it to work with these). I don't really understand, what are they for? The doc says "source IP inside the tunnel", but what does it mean, and what practical use would be? |
As you said from the docs as below.
My understanding is that this can be used to NAT traffic to and from the tunnel, I have never used this type of option as I would normally use virtual subnets and nat traffic via iptables.
| Code: | eftsourceip = %config4 | %config6 | <ip address>
The internal source IP to use in a tunnel, also known as virtual IP.
If the value is one of the synonyms %config, %cfg, %modeconfig or %modecfg, an address (from
the tunnel address family) is requested from the peer.
Since 5.0.1 a comma-separated list is accepted to request multiple addresses, and with %config4 and
%config6 an address of the given address family will be requested explicitly.
If an IP address is configured, it will be requested from the responder, which is free to respond with a
different address.
rightsourceip = %config | <network>/<netmask> | <from>-<to> | %poolname
The internal source IP to use in a tunnel for the remote peer. If the value is config on the responder
side, the initiator must propose an address which is then echoed back. Also supported are address pools
expressed as <network>/<netmask> and <from>-<to> (since 5.2.2) or the use of an external IP address pool
using %poolname where poolname is the name of the IP address pool used for the lookup (see virtual IP for details).
Since 5.0.1 a comma-separated list of IP addresses / pools is accepted, for instance, to define pools of
different address families. |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
