Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure with pfSense 2.3.2

[Karl Fife]

Going back to the OP, here's a postmortem on exactly what happened:

In short, we had unknowingly downgraded from 64 bit to 32 bit during an 
upgrade.  It's covered here:


https://doc.pfsense.org/index.php/Upgrade_Guide#Avoiding_Unintended_Architecture_Change

Interestingly, it worked like this:

We were running 64 bit 2.2.6.  Working fine.  We installed 64-bit 2.3.2, 
and restored our config.  Again, working fine.   Then we upgraded to 
*in-place* to 2.3.2_1, which for the *first time*, referenced a vestigal 
"upgrade URL" in our config, which had been carried-forward from an era 
when this was 'normal'.  Because the old URL happened to point to a 32 
bit architecture (the only architecture back then), we were unknowingly 
downgraded to the 32 bit architecture without realizing it.   And of 
course, the 32 bit defaults are VERY different from the 64 bit version 
(IIRC ~5x greater kern.ipc.nmbclusters and kern.ipc.nmbufs for 64 bit) 
causing our observed kernel panic on the ample Supermicro A1SRi-2758F 
(with its huge pile of cores and IGB NIC's) etc..  The pfSense project 
has correctly set stingy defaults in the 32 bit architecture, and 
there's no case to be made for running the 32 bit stack on a beefy board 
like this one.


I suspect many/most of people who have written in forum posts about how 
pfsense doesn't 'Just work' on the popular Supermicro A1SRi-2758F are 
running the 32 bit stack or unknowingly downgrading.


Last night we manually edited the config, and restored it to a clean 
64-bit image of 2.3.2, and as expected, it 'just worked' with no sysctrl 
modifications.  The upgrade to 2.3.2_1 was also flawless because the old 
upgrade URL had been removed from the config.



On 1/25/2017 4:01 PM, Karl Fife wrote:
This is a good theory, because RRD data from 2.2.6 suggests that the 
difference in utilization between the versions is slight, and that we 
had 'barely' exhausted our system default allocation.


Is there a difference between nano and full with respect to the 
installer explicitly setting tunables for kern.ipc.nmbclusters and 
kern.ipc.nmbuf?  Vick Khera says he sees explicitly set tunables on 
his 2.3.2 system, yet my virgin installation of Nano pfSense 2.3.2 has 
no explicit declarations?


Vick, is your Supermicro A1SRi-2758F running an installation that came 
from Netgate, or is it a community edition installation?  If the 
latter, Full or Nano?



On 1/25/2017 3:49 PM, Jim Pingle wrote:

On 01/25/2017 01:10 PM, Karl Fife wrote:

The piece that's still missing for me is that there must have been some
change in default system setting for FreeBSD, or some other change
between versions, because the system booted fine with pfSense v 2.2.6

Aside from what has already been suggested by others, it's possible that
the newer drivers from FreeBSD 10.3 in pfSense 2.3.x enabled features on
the NIC chipset that consumed more mbufs. For example, it might be using
more queues per NIC by default than it did previously.

Jim

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold




___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec Bug?

[Eero Volotinen]

how about disabling pfs?

Eero

2017-02-03 13:25 GMT+02:00 Roland Giesler :

> On Fri, Feb 3, 2017 at 1:19 PM, Eero Volotinen 
> wrote:
>
>> It's a bit antique selection of ciphers.
>>
>
> It is indeed.  We were experimenting for a long time with many others and
> got similar result (no matches).  So I opted to check what pfSense offers
> and set Sonicwall to ask for that, but Sonicwall can't do MODP_3072,
> which is the only combination of what pfSense offers and what Sonicwall
> supports.
>
> We gave up in the end and opted to use SSH tunnels to work through, rather
> than set up a VPN.  In the end we may have to set up OpenVPN, which mobile
> clients rather that site-to-site...  :-(  Not what we had in mind.
>
> Roland
>
>
>>
>> Problem is in DH group. try enabling same DH also in pfsense.
>>
>> --
>> Eero
>>
>> 2017-02-03 13:17 GMT+02:00 Roland Giesler :
>>
>>> On Tue, Jan 24, 2017 at 8:16 PM, Eero Volotinen 
>>> wrote:
>>>
 What hardware is other side running? Why you are trying to use 3des?

>>>
>>> The other side is Sonicwall.  I'm using 3DES because it's enabled by
>>> default and seeming a simple place to start.
>>>
>>> However, regardless of what I select (by ticking the boxes - net very
>>> difficult), that is then not offered.  So if I select 3DES, it is not
>>> offered.  If I select SHA256 it's not offered, and so on.
>>>
>>> Roland
>>>
>>>
>>>

 Eero

 2017-01-17 16:36 GMT+02:00 Roland Giesler :

> We've battled all afternoon to establish an IPSec site-to-site
> connection.
> Here's what happens:
>
> TimeProcessPIDMessage
> Jan 17 15:58:53 charon 05[NET] <197> sending packet: from
> 129.232.232.130[500] to 105.27.116.62[500] (56 bytes)
> Jan 17 15:58:53 charon 05[ENC] <197> generating INFORMATIONAL_V1
> request
> 2809641300 [ N(NO_PROP) ]
> Jan 17 15:58:53 charon 05[IKE] <197> no proposal found
> Jan 17 15:58:53 charon 05[CFG] <197> configured proposals:
> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072,
> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAM
> ELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HM
> AC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/A
> ES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/P
> RF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD
> 5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_B
> P/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_20
> 48_256/MODP_1024,
> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_
> 128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_19
> 2/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC
> _SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_H
> MAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_5
> 12_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
> Jan 17 15:58:53 charon 05[CFG] <197> received proposals:
> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
> Jan 17 15:58:53 charon 05[IKE] <197> 105.27.116.62 is initiating a
> Aggressive Mode IKE_SA
>
> The strange thing is that I have set 3DES and SHA1 to in my setup, yet
> it
> is not being offered.  I have also test quite a few other like AES 265
> and
> SHA2, but they are also not offered.  The other side (SonicWall) is
> offering what we set mutually.
>
> Is this a bug?  If now, how to I force pfSense to behave and start
> using
> the settings I set.
>
> IPSec IKE V2 with pre-shared key.
>
> I'm running 2.3.2_1
>
> Anyone that has seen this?
>
> regards
>
>
> Roland Giesler
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>


>>>
>>
>
>
>
>
> Sent
> with Mailtrack
> 
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec Bug?

[Roland Giesler]

 On Fri, Feb 3, 2017 at 1:19 PM, Eero Volotinen 
wrote:

> It's a bit antique selection of ciphers.
>

It is indeed.  We were experimenting for a long time with many others and
got similar result (no matches).  So I opted to check what pfSense offers
and set Sonicwall to ask for that, but Sonicwall can't do MODP_3072, which
is the only combination of what pfSense offers and what Sonicwall supports.

We gave up in the end and opted to use SSH tunnels to work through, rather
than set up a VPN.  In the end we may have to set up OpenVPN, which mobile
clients rather that site-to-site...  :-(  Not what we had in mind.

Roland


>
> Problem is in DH group. try enabling same DH also in pfsense.
>
> --
> Eero
>
> 2017-02-03 13:17 GMT+02:00 Roland Giesler :
>
>> On Tue, Jan 24, 2017 at 8:16 PM, Eero Volotinen 
>> wrote:
>>
>>> What hardware is other side running? Why you are trying to use 3des?
>>>
>>
>> The other side is Sonicwall.  I'm using 3DES because it's enabled by
>> default and seeming a simple place to start.
>>
>> However, regardless of what I select (by ticking the boxes - net very
>> difficult), that is then not offered.  So if I select 3DES, it is not
>> offered.  If I select SHA256 it's not offered, and so on.
>>
>> Roland
>>
>>
>>
>>>
>>> Eero
>>>
>>> 2017-01-17 16:36 GMT+02:00 Roland Giesler :
>>>
 We've battled all afternoon to establish an IPSec site-to-site
 connection.
 Here's what happens:

 TimeProcessPIDMessage
 Jan 17 15:58:53 charon 05[NET] <197> sending packet: from
 129.232.232.130[500] to 105.27.116.62[500] (56 bytes)
 Jan 17 15:58:53 charon 05[ENC] <197> generating INFORMATIONAL_V1 request
 2809641300 [ N(NO_PROP) ]
 Jan 17 15:58:53 charon 05[IKE] <197> no proposal found
 Jan 17 15:58:53 charon 05[CFG] <197> configured proposals:
 IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072,
 IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAM
 ELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HM
 AC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/A
 ES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/P
 RF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD
 5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_
 BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_
 2048_256/MODP_1024,
 IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_
 128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_19
 2/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC
 _SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_H
 MAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_5
 12_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
 Jan 17 15:58:53 charon 05[CFG] <197> received proposals:
 IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
 Jan 17 15:58:53 charon 05[IKE] <197> 105.27.116.62 is initiating a
 Aggressive Mode IKE_SA

 The strange thing is that I have set 3DES and SHA1 to in my setup, yet
 it
 is not being offered.  I have also test quite a few other like AES 265
 and
 SHA2, but they are also not offered.  The other side (SonicWall) is
 offering what we set mutually.

 Is this a bug?  If now, how to I force pfSense to behave and start using
 the settings I set.

 IPSec IKE V2 with pre-shared key.

 I'm running 2.3.2_1

 Anyone that has seen this?

 regards


 Roland Giesler
 ___
 pfSense mailing list
 https://lists.pfsense.org/mailman/listinfo/list
 Support the project with Gold! https://pfsense.org/gold

>>>
>>>
>>
>




Sent
with Mailtrack

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec Bug?

[Eero Volotinen]

It's a bit antique selection of ciphers.

Problem is in DH group. try enabling same DH also in pfsense.

--
Eero

2017-02-03 13:17 GMT+02:00 Roland Giesler :

> On Tue, Jan 24, 2017 at 8:16 PM, Eero Volotinen 
> wrote:
>
>> What hardware is other side running? Why you are trying to use 3des?
>>
>
> The other side is Sonicwall.  I'm using 3DES because it's enabled by
> default and seeming a simple place to start.
>
> However, regardless of what I select (by ticking the boxes - net very
> difficult), that is then not offered.  So if I select 3DES, it is not
> offered.  If I select SHA256 it's not offered, and so on.
>
> Roland
>
>
>
>>
>> Eero
>>
>> 2017-01-17 16:36 GMT+02:00 Roland Giesler :
>>
>>> We've battled all afternoon to establish an IPSec site-to-site
>>> connection.
>>> Here's what happens:
>>>
>>> TimeProcessPIDMessage
>>> Jan 17 15:58:53 charon 05[NET] <197> sending packet: from
>>> 129.232.232.130[500] to 105.27.116.62[500] (56 bytes)
>>> Jan 17 15:58:53 charon 05[ENC] <197> generating INFORMATIONAL_V1 request
>>> 2809641300 [ N(NO_PROP) ]
>>> Jan 17 15:58:53 charon 05[IKE] <197> no proposal found
>>> Jan 17 15:58:53 charon 05[CFG] <197> configured proposals:
>>> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072,
>>> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAM
>>> ELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HM
>>> AC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/
>>> AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_
>>> 384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_
>>> HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_
>>> BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_
>>> 2048/MODP_2048_256/MODP_1024,
>>> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_
>>> 128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_19
>>> 2/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC
>>> _SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_
>>> HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_
>>> 512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
>>> Jan 17 15:58:53 charon 05[CFG] <197> received proposals:
>>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
>>> Jan 17 15:58:53 charon 05[IKE] <197> 105.27.116.62 is initiating a
>>> Aggressive Mode IKE_SA
>>>
>>> The strange thing is that I have set 3DES and SHA1 to in my setup, yet it
>>> is not being offered.  I have also test quite a few other like AES 265
>>> and
>>> SHA2, but they are also not offered.  The other side (SonicWall) is
>>> offering what we set mutually.
>>>
>>> Is this a bug?  If now, how to I force pfSense to behave and start using
>>> the settings I set.
>>>
>>> IPSec IKE V2 with pre-shared key.
>>>
>>> I'm running 2.3.2_1
>>>
>>> Anyone that has seen this?
>>>
>>> regards
>>>
>>>
>>> Roland Giesler
>>> ___
>>> pfSense mailing list
>>> https://lists.pfsense.org/mailman/listinfo/list
>>> Support the project with Gold! https://pfsense.org/gold
>>>
>>
>>
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec Bug?

[Roland Giesler]

 On Tue, Jan 24, 2017 at 8:16 PM, Eero Volotinen 
wrote:

> What hardware is other side running? Why you are trying to use 3des?
>

The other side is Sonicwall.  I'm using 3DES because it's enabled by
default and seeming a simple place to start.

However, regardless of what I select (by ticking the boxes - net very
difficult), that is then not offered.  So if I select 3DES, it is not
offered.  If I select SHA256 it's not offered, and so on.

Roland



>
> Eero
>
> 2017-01-17 16:36 GMT+02:00 Roland Giesler :
>
>> We've battled all afternoon to establish an IPSec site-to-site connection.
>> Here's what happens:
>>
>> TimeProcessPIDMessage
>> Jan 17 15:58:53 charon 05[NET] <197> sending packet: from
>> 129.232.232.130[500] to 105.27.116.62[500] (56 bytes)
>> Jan 17 15:58:53 charon 05[ENC] <197> generating INFORMATIONAL_V1 request
>> 2809641300 [ N(NO_PROP) ]
>> Jan 17 15:58:53 charon 05[IKE] <197> no proposal found
>> Jan 17 15:58:53 charon 05[CFG] <197> configured proposals:
>> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072,
>> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAM
>> ELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/
>> HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_
>> 96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA
>> 2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/
>> PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_
>> 256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/
>> MODP_2048/MODP_2048_256/MODP_1024,
>> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_
>> 128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_19
>> 2/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_
>> HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/
>> PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/
>> ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_
>> 2048_256/MODP_1024
>> Jan 17 15:58:53 charon 05[CFG] <197> received proposals:
>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
>> Jan 17 15:58:53 charon 05[IKE] <197> 105.27.116.62 is initiating a
>> Aggressive Mode IKE_SA
>>
>> The strange thing is that I have set 3DES and SHA1 to in my setup, yet it
>> is not being offered.  I have also test quite a few other like AES 265 and
>> SHA2, but they are also not offered.  The other side (SonicWall) is
>> offering what we set mutually.
>>
>> Is this a bug?  If now, how to I force pfSense to behave and start using
>> the settings I set.
>>
>> IPSec IKE V2 with pre-shared key.
>>
>> I'm running 2.3.2_1
>>
>> Anyone that has seen this?
>>
>> regards
>>
>>
>> Roland Giesler
>> ___
>> pfSense mailing list
>> https://lists.pfsense.org/mailman/listinfo/list
>> Support the project with Gold! https://pfsense.org/gold
>>
>
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec Bug?

[Roland Giesler]

On Tue, Jan 24, 2017 at 9:56 PM, Jim Thompson  wrote:

> On Tue, Jan 24, 2017 at 12:16 PM, Eero Volotinen 
> wrote:
> > What hardware is other side running? Why you are trying to use 3des?
> >
> > Eero
> >
> > 2017-01-17 16:36 GMT+02:00 Roland Giesler :
> >
> >> We've battled all afternoon to establish an IPSec site-to-site
> connection.
> >> Here's what happens:
> >>
> >> TimeProcessPIDMessage
> >> Jan 17 15:58:53 charon 05[NET] <197> sending packet: from
> >> 129.232.232.130[500] to 105.27.116.62[500] (56 bytes)
> >> Jan 17 15:58:53 charon 05[ENC] <197> generating INFORMATIONAL_V1 request
> >> 2809641300 [ N(NO_PROP) ]
> >> Jan 17 15:58:53 charon 05[IKE] <197> no proposal found
> >> Jan 17 15:58:53 charon 05[CFG] <197> configured proposals:
> >> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072,
> >> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/
> >> CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_
> >> 128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_
> >> SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_
> >> SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_
> >> CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/
> >> ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_
> >> 8192/MODP_2048/MODP_2048_256/MODP_1024,
> >> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_
> >> 128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_
> >> 192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/
> >> PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_
> >> MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_
> >> 384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/
> >> MODP_2048_256/MODP_1024
> >> Jan 17 15:58:53 charon 05[CFG] <197> received proposals:
> >> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
> >> Jan 17 15:58:53 charon 05[IKE] <197> 105.27.116.62 is initiating a
> >> Aggressive Mode IKE_SA
> >>
> >> The strange thing is that I have set 3DES and SHA1 to in my setup, yet
> it
> >> is not being offered.  I have also test quite a few other like AES 265
> and
> >> SHA2, but they are also not offered.  The other side (SonicWall) is
> >> offering what we set mutually.
>
> The other side proposed 3DES-CBC/HMAC-SHA1/MODP_1536.
> Your side didn't propose same (search for MODP_1536)
>
> Search for "Phase 1 DH Group Mismatch" in
> https://doc.pfsense.org/index.php/IPsec_Troubleshooting
>
> not a bug.
>

If I select 3DES, SHA1 MODP1536 in the pfSense interface and I try to
connect and pfSense doesn't offer what I selected, then surely something's
wrong?

How is setting something to offer ABC and then ABC not being offered not a
bug?

Roland


>
> Jim
>
> >>
> >> Is this a bug?  If now, how to I force pfSense to behave and start using
> >> the settings I set.
> >>
> >> IPSec IKE V2 with pre-shared key.
> >>
> >> I'm running 2.3.2_1
> >>
> >> Anyone that has seen this?
> >>
> >> regards
> >>
> >>
> >> Roland Giesler
> >> ___
> >> pfSense mailing list
> >> https://lists.pfsense.org/mailman/listinfo/list
> >> Support the project with Gold! https://pfsense.org/gold
> >>
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold