[strongSwan] IKEv2 PFS disabled
Nicole Hähnel
ml at nicole-haehnel.de
Thu Mar 3 09:40:20 CET 2011
Hi,
thank you for your config.
We got the tunnel running, but it seems the fortigate doesn't route any
package through the tunnel.
So we have to test some more.
Regards,
Nicole
Am 28.02.2011 18:48, schrieb Alexis Salinas:
> I'm answering this request with copy to the list in case some else wants the configuration. As I said before, notice that PFS has to be disabled on StrongSwan for this to work.
> Cheers,
> Alexis.
>
>
> Strongswan:
> config setup
> cachecrls=no
> charonstart=yes
> crlcheckinterval=0
> plutostart=no
> strictcrlpolicy=no
> nat_traversal=yes
> plutodebug=none
> charondebug="dmn 0, mgr 0, ike 2, chd 0, job 0, cfg 3, knl 2, net 2, enc 0, lib 0"
>
> conn to-fortigate4.0
> left=192.168.3.47
> leftid=@H020109D0206
> leftsubnet=172.22.0.0/24
> leftnexthop=192.168.2.128
> leftfirewall=yes
> right=XX.XX.XX.95
> rightsubnet=10.0.0.0/24
> ike=aes128-md5-modp1536!
> esp=aes128-md5!
> keyexchange=ikev2
> mobike=no
> ikelifetime=60m
> keylife=20m
> compress=no
> authby=secret
> dpdaction=restart
> dpddelay=10
> dpdtimeout=30
> auto=add
> keyingtries=1
> rekeymargin=3m
> forceencaps=no
> reauth=yes
>
>
> Fortigate:
> config vpn ipsec phase1-interface
> edit "omg-p1"
> set type dynamic
> set interface "wan1"
> set ike-version 2
> set proposal aes128-md5
> set psksecret ENC wYvCBAv7cFED5aApm22Ps1hhGZr5pZ4gnAYth7T+a7bN6TVrX9qlZR6gzP6T8JyOQ7zzHZGZR5biQJoHDU4Kz172t5AO0xyVr5zX88g57PwQv+BM
> next
> end
> config vpn ipsec phase2-interface
> edit "omg-p2"
> set phase1name "omg-p1"
> set proposal aes128-md5
> set replay disable
> set dst-subnet 172.22.0.0 255.255.255.0
> set src-subnet 10.0.0.0 255.255.255.0
> next
> end
>
> config firewall policy
> edit 1
> set srcintf "internal"
> set dstintf "wan1"
> set srcaddr "all"
> set dstaddr "all"
> set action accept
> set schedule "always"
> set service "ANY"
> set nat enable
> next
> edit 2
> set srcintf "internal"
> set dstintf "omg-p1"
> set srcaddr "all"
> set dstaddr "all"
> set action accept
> set schedule "always"
> set service "ANY"
> next
> edit 3
> set srcintf "omg-p1"
> set dstintf "internal"
> set srcaddr "all"
> set dstaddr "all"
> set action accept
> set schedule "always"
> set service "ANY"
> next
> end
>
>
>
> Cheers,
> Alexis
>
> -----Original Message-----
> From: Nicole Hähnel [mailto:ml at nicole-haehnel.de]
> Sent: 28-Feb-11 06:21
> To: Alexis Salinas
> Subject: Re: [strongSwan] IKEv2 PFS disabled
>
> Hi,
>
> we are also trying to connect a FortiGate 50B to our strongswan gateway
> with ikev2.
> But we are not able to bring the tunnel up until now.
>
> Can you please provide us your FortiGate vpn and firewall configs?
>
> Thanks in advance!
>
> Nicole
>
>
> Am 13.12.2010 19:04, schrieb Alexis Salinas:
>> Thank you both very much for your quick answer, I'll certainly report this to Fortinet as I already have a ticket open with them. And if you think it could be of any help, I can report back when they fix the bug. Just to confirm, by disabling PFS on the Fortigate, everything works.
>>
>> Thank you,
>> Alexis
>>
>>
>>
>> -----Original Message-----
>> From: Martin Willi [mailto:martin at strongswan.org]
>> Sent: December-13-10 12:52 AM
>> To: Alexis Salinas
>> Cc: users at lists.strongswan.org
>> Subject: Re: [strongSwan] IKEv2 PFS disabled
>>
>> Hi Alexis,
>>
>>> esp=aes128-md5-modp1536!
>>> pfs=yes
>> The pfs keyword is not used for IKEv2 connections. If the esp proposal
>> contains a DH group, a DH exchange is done for CREATE_CHILD_SA
>> exchanges.
>>
>>> ike 0:omg-p1:64:omg-p2:962: incoming proposal:
>>> ike 0:omg-p1:64:omg-p2:962: proposal id = 1:
>>> ike 0:omg-p1:64:omg-p2:962: protocol = ESP:
>>> ike 0:omg-p1:64:omg-p2:962: encapsulation = TUNNEL
>>> ike 0:omg-p1:64:omg-p2:962: type=ENCR, val=AES_CBC (key_len = 128)
>>> ike 0:omg-p1:64:omg-p2:962: type=INTEGR, val=MD5
>>> ike 0:omg-p1:64:omg-p2:962: PFS is disabled
>>> ike 0:omg-p1:64:omg-p2:962: my proposal:
>>> ike 0:omg-p1:64:omg-p2:962: proposal id = 1:
>>> ike 0:omg-p1:64:omg-p2:962: protocol = ESP:
>>> ike 0:omg-p1:64:omg-p2:962: encapsulation = TUNNEL
>>> ike 0:omg-p1:64:omg-p2:962: type=ENCR, val=AES_CBC (key_len = 128)
>>> ike 0:omg-p1:64:omg-p2:962: type=INTEGR, val=MD5
>>> ike 0:omg-p1:64:omg-p2:962: type=DH_GROUP, val=1536
>>> ike 0:omg-p1:64:omg-p2:962: lifetime=1800
>>> ike 0:omg-p1:64:omg-p2:962: no proposal chosen
>> Fortigate expects a DH group in the piggy-packed CHILD_SA creation in
>> IKE_AUTH. This seems wrong to me. As we have done a DH exchange in
>> IKE_SA_INIT, it does not make much sense to repeat one in IKE_AUTH.
>>
>> End of section 1.2 RFC5996 says:
>>
>>> Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
>>> Thus, the SA payloads in the IKE_AUTH exchange cannot contain
>>> Transform Type 4 (Diffie-Hellman group) with any value other than
>>> NONE. Implementations SHOULD omit the whole transform substructure
>>> instead of sending value NONE.
>> You probably should report this bug to Fortigate and/or try it without
>> PFS enabled.
>>
>> Regards
>> Martin
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>>
More information about the Users
mailing list