[strongSwan-dev] IKEv2: Allow peer to choose between transport xor tunnel mode in presence of NAT

Sebastian Wurst wurstsebastian80 at gmail.com
Thu Jul 11 05:28:42 CEST 2013


Hi Martin!

Thank you so much for your help! Though, I still can't get this to work as
expected. This is how my old tunnel mode ipsec.conf file looks like
(strongswan 4.6.4 and 5.0 too):

config setup
    uniqueids=no
conn %default
    type=tunnel
    keyexchange=ikev2
    auto=start
    mark=1/1
    ike=aes128gcm12-aesxcbc-modp1024
    esp=aes128gcm12-modp1024
conn remote-2.1.1.1
    leftupdown="/usr/sbin/updown.sh"
    left=0.0.0.0
    leftcert=/etc/client-cert.pem
    leftsubnet=0.0.0.0/0
    right=2.1.1.1
    rightcert=/etc/ipsec.d/certs/2.1.1.1.pem



So I simply changed "type" from "tunnel" to "transport" and then
1. strongswan 4.6.4 <-> strongswan 5.1 negotiates compatibility tunnel mode
as expected, but
2. strongswan 5.1 <-> strongswan 5.1 fails to negotiate transport mode (or
even tunnel mode):

Here is a snippet from strongswan 5.1 syslog that confirms this:
Jul 6 12:19:11 debian charon: 01[IKE] no acceptable traffic selectors found
Jul 6 12:19:11 debian charon: 01[IKE] failed to establish CHILD_SA, keeping
IKE_SA
Jul 6 12:19:11 debian charon: 01[ENC] generating IKE_AUTH response 1 [ IDr
AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
Jul 6 12:19:11 debian charon: 01[NET] sending packet: from 2.1.1.100[4500]
to 2.1.1.1[4500] (519 bytes)



So besides changing tunnel type, I also deleted the "leftsubnet=0.0.0.0/0"
line from ipsec.conf. As a result:
1. strongswan 5.1 <-> strongswan 5.1 now is able to negotiate transport
mode as expected, but
2. strongswan 4.6.4 <-> strongswan 5.1 fails to negotiate compatibility
tunnel mode.

Here is a snippet from the strongswan 4.6.4 syslog:

Jul 5 13:33:38 debian charon: 16[IKE] traffic selectors 2.1.1.100/32 ===
1.1.1.100/32 inacceptable
Jul 5 13:33:38 debian charon: 16[IKE] failed to establish CHILD_SA, keeping
IKE_SA
Jul 5 13:33:38 debian charon: 16[ENC] generating IKE_AUTH response 1 [ IDr
AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
Jul 5 13:33:38 debian charon: 16[NET] sending packet: from 2.1.1.100[4500]
to 2.1.1.1[4500]



In other words I can't figure out how to change ipsec.conf file so that
tunnel and transport modes could be negotiated from the same "conn"
instance.

Strongswan 2.1.1.100 is the one with public IP address. 2.1.1.1 is the
firewall IP address and 1.1.1.100 is the IP address of the strongswan that
is behind NAT.

Best regards,
SW



On 10 July 2013 00:05, Martin Willi <martin at strongswan.org> wrote:

> Hi Sebastian,
>
> > 1. IPsec transport mode when peer is using the new strongSwan 5.1.0dr2
> > 2. IPsec tunnel mode when peer is using the old strongSwan 5.0.4 (i.e.
> as a
> > fallback mechanism)
>
> Even if you configure transport mode, 5.1.0 should accept tunnel mode
> for that connection. When using transport mode, any client not
> supporting it (for example because it detected NAT) just omits the
> transport mode notify and the connection uses a tunnel mode fallback.
>
> > Do I really need two conn templates in ipsec.conf file (one for transport
> > mode and one for tunnel mode)?
>
> No, you'll need just one having type=transport.
>
> Regards
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130710/07227aee/attachment.html>


More information about the Dev mailing list