# [solved] Strongswan auth ok, but not establishing tunnel

## digimag

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:

```
# 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:

```
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?

----------

## chiefbag

```
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" ?

----------

## digimag

 *chiefbag wrote:*   

> 
> 
> ```
> IKE_SA my_vpn_tunnel[1] established between local.ip.behind.nat[local.end.pub.ip]...other.end.pub.ip[other.end.pub.ip]
> ```
> ...

 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?  :Rolling Eyes: 

----------

## chiefbag

 *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.

```
 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.
```

----------

