Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 19594 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec between XG and pfSense Phase 2 issues

Ruben Krauth

Hi All, I' m having a huge headache over this issue..

We've got XG Firewalls deployed at our customer sited, they are all working nicely, but we like to set up an IPSec tunnel to our local pfSense firewall to monitor the equipment.

I'm getting the phase 1 up just nicely, but the phase 2 seems to go wrong.

This is what I've got:

-Sophos FW with 2 WAN nics (behind NAT routers due to 1 line being cable and the other line having a MTU issue forcing us to (temporary) use the ISPs box)

-Our pfSense FW with a WAN NIC having a public address.

To test I've allowed all firewall traffic from/to the two public addresses.

Logs - XG:

"AMMonitoring-1" #36831: Main mode peer ID is ID_IPV4_ADDR: 'xx.xx.xxx.xx'

"AMMonitoring-1" #36831: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4

"AMMonitoring-1" #36831: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024} "AMMonitoring-1" #36831: Dead Peer Detection (RFC 3706): enabled

"AMMonitoring-1" #36832: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP+failureDROP {using isakmp#36831}

"AMMonitoring-1" #36832: STATE_QUICK_I1: initiate "AMMonitoring-1" #36832: STATE_QUICK_I1: retransmission; will wait 20s for response

"AMMonitoring-1" #36832: STATE_QUICK_I1: retransmission; will wait 40s for response

"AMMonitoring-1" #36832: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

"AMMonitoring-1" #36832: starting keying attempt 2 of at most 3, but releasing whack

"AMMonitoring-1" #36997: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP+failureDROP {using isakmp#36831}

"AMMonitoring-1" #36997: STATE_QUICK_I1: initiate "AMMonitoring-1" #36997: STATE_QUICK_I1: retransmission; will wait 20s for response

"AMMonitoring-1" #36997: STATE_QUICK_I1: retransmission; will wait 40s for response

"AMMonitoring-1" #36997: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

"AMMonitoring-1" #36997: starting keying attempt 2 of at most 3, but releasing whack

"AMMonitoring-1" #37017: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP+failureDROP {using isakmp#36831}

"AMMonitoring-1" #37017: STATE_QUICK_I1: initiate

"AMMonitoring-1" #37017: STATE_QUICK_I1: retransmission; will wait 20s for response

"AMMonitoring-1" #37017: STATE_QUICK_I1: retransmission; will wait 40s for response

"AMMonitoring-1" #37017: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

"AMMonitoring-1"#37017: starting keying attempt 2 of at most 3, but releasing whack

Logs - pfSense:

Jul 10 15:22:17 charon 16[MGR] IKE_SA checkout not successful

Jul 10 15:22:17 charon 16[MGR] IKE_SA checkout not successful Jul 10 15:22:17 charon 16[MGR] checkout IKEv1 SA by message with SPIs 020045aae424c37e_i 7057f4b29446169d_r

Jul 10 15:22:17 charon 16[MGR] checkout IKEv1 SA by message with SPIs 020045aae424c37e_i 7057f4b29446169d_r

Jul 10 15:22:17 charon 01[NET] waiting for data on sockets

Jul 10 15:22:17 charon 01[NET] waiting for data on sockets

Jul 10 15:22:16 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:16 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:16 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:16 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:16 charon 16[IKE] delaying task initiation, QUICK_MODE exchange in progress

Jul 10 15:22:16 charon 16[IKE] delaying task initiation, QUICK_MODE exchange in progress

Jul 10 15:22:16 charon 16[IKE] received INVALID_MESSAGE_ID error notify Jul 10 15:22:16 charon 16[IKE] received INVALID_MESSAGE_ID error notify

Jul 10 15:22:16 charon 16[ENC] parsed INFORMATIONAL_V1 request 2300479425 [ HASH N(INVAL_MID) ]

Jul 10 15:22:16 charon 16[ENC] parsed INFORMATIONAL_V1 request 2300479425 [ HASH N(INVAL_MID) ]

Jul 10 15:22:16 charon 16[NET] received packet: from yy.yyy.yy.yy[4500] to xx.xxx.xx.xxx[4500] (68 bytes)

Jul 10 15:22:16 charon 16[NET] received packet: from yy.yyy.yy.yy[4500] to xx.xxx.xx.xxx[4500] (68 bytes)

Jul 10 15:22:16 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:16 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:16 charon 16[MGR] checkout IKEv1 SA by message with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r

Jul 10 15:22:16 charon 16[MGR] checkout IKEv1 SA by message with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r

Jul 10 15:22:16 charon 01[NET] waiting for data on sockets

Jul 10 15:22:16 charon 01[NET] waiting for data on sockets

Jul 10 15:22:16 charon 01[NET] received packet: from yy.yyy.yy.yy[4500] to xx.xxx.xx.xxx[4500]

Jul 10 15:22:16 charon 01[NET] received packet: from yy.yyy.yy.yy[4500] to xx.xxx.xx.xxx[4500]

Jul 10 15:22:16 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:16 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:16 charon 03[NET] sending packet: from xx.xxx.xx.xxx[4500] to yy.yyy.yy.yy[4500]

Jul 10 15:22:16 charon 03[NET] sending packet: from xx.xxx.xx.xxx[4500] to yy.yyy.yy.yy[4500]

Jul 10 15:22:16 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:16 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:16 charon 16[NET] sending packet: from xx.xxx.xx.xxx[4500] to yy.yyy.yy.yy[4500] (2044 bytes)

Jul 10 15:22:16 charon 16[NET] sending packet: from xx.xxx.xx.xxx[4500] to yy.yyy.yy.yy[4500] (2044 bytes)

Jul 10 15:22:16 charon 16[IKE] sending retransmit 2 of request message ID 44203241, seq 4

Jul 10 15:22:16 charon 16[IKE] sending retransmit 2 of request message ID 44203241, seq 4

Jul 10 15:22:16 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:16 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:16 charon 16[MGR] checkout IKEv1 SA with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r

Jul 10 15:22:16 charon 16[MGR] checkout IKEv1 SA with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r Jul 10 15:22:15 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:15 charon 16[MGR] checkin of IKE_SA successful

Jul 10 15:22:15 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:15 charon 16[MGR] checkin IKE_SA con5000[63]

Jul 10 15:22:15 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:15 charon 16[MGR] IKE_SA con5000[63] successfully checked out

Jul 10 15:22:15 charon 16[MGR] checkout IKEv1 SA with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r

Jul 10 15:22:15 charon 16[MGR] checkout IKEv1 SA with SPIs 0dce1c3e4ace4628_i 9489fded74e0fb35_r

Settings - Sophos:

  • Type: Site-to-Site Policy: AMMon
  • Action on Restart: Initiate
  • Authentication type: PSK
  • Local Endpoint: "Port 2 - 192.168.2.222" - Remote endpoint: xx.xxx.xx.xxx
  • IP Family: IPv4
  • Local Subnet: "DataLAN"
  • Natted Subnet: Same as local
  • Local ID: IP 192.168.2.222
  • Allow NAT Traversal: Greyed out, can't change it.
  • Remote LAN Network: AMMon
  • Remote ID: xx.xxx.xx.xxx

Policy AMMon:

  • Allow Re-Key: Yes
  • Compression: Yes
  • Auth Mode: Main
  • Rekey attempts: 3

#Phase1

  • Encryption: 3DES
  • Auth: SHA1
  • DH Group: 2
  • Key life: 28800
  • Rekey Margin: 120
  • Randomize: 0
  • DPD: Yes
  • Check: 30s
  • Wait for: 120 sec
  • When unreachable: Re-Initiate

#Phase2:

  • Enc: 3DES - MD5 / AES128 - SHA1 / Blowfish - SHA2 256
  • DH Group: Same as Ph1
  • Key Life: 3600

Pfsense:

  • Key Exchange: IKEv1
  • Auth: Mutual PSK
  • Negotiation method: Main
  • My ID: xx.xxx.xx.xxx
  • Peer ID: 192.168.2.222
  • Phase 1: 3DES - SHA1 - DH2
  • Phase 2: Checked all encryptions/auth algorithms for testing
  • Key life: 3600 Protocol: ESP

 

If anyone has any idea, I'd love to hear it :)



This thread was automatically locked due to age.
Parents
  • +1
    Turn off pfs for phase 2. In other words don't leave the setting as "same as phase 1" because I think that keeps pfs on
  • 0 in reply to apalm123

    Much appreciated apalm123,

     

    I had a guess it was PFS related - as the VPN began dropping after about 3 hours (lifetime setting).

     

    PFS is pretty important to me. Does PFS play nicer if i choose a more conservative DH group?

  • 0 in reply to DirkCoetzee

    I'm not sure if it can player nicer, maybe. In my experience so far, most guides say to turn it off, perhaps losing some security at the expense of getting things working. Does it stay up when you disable this setting? I looked it up again, and to do so, set Phase 2 PFS Group to "None" to turn off PFS.

     

    Perhaps work on the other end to figure out if it's compatible with PFS?

  • 0 in reply to apalm123

    cheers,

     

    I know PFS works - the IPSEC transform set has stayed pretty much the same. We have recently replaced a WatchGuard with a Sophos Firewall. WG <-> pfSense worked pretty much flawlessly - with IKEv1, and PFS.

     

    With all the dramas, i recreated with IKEv2, with PFS. Symptoms are still the same. VPN initiates and works ok, but at renegotiation time it fails.

     

    Thanks again for your support!

Reply
  • 0 in reply to apalm123

    cheers,

     

    I know PFS works - the IPSEC transform set has stayed pretty much the same. We have recently replaced a WatchGuard with a Sophos Firewall. WG <-> pfSense worked pretty much flawlessly - with IKEv1, and PFS.

     

    With all the dramas, i recreated with IKEv2, with PFS. Symptoms are still the same. VPN initiates and works ok, but at renegotiation time it fails.

     

    Thanks again for your support!

Children
  • 0 in reply to DirkCoetzee

    FWIW:

    To others who may be experiencing the same issue.

     

    The upgrade to SFOS 17.0.5 MR-5 yields about a 50% improvement in stability between pfSense 2.4.1 and Sophos. PFS is semi stable and no longer breaks after the allotted time for renegotiation. 

     

    DPD still does not working. This is quite surprising as both pfSense and Sophos use Strongswan as their IPSEC engines. 

     

    Regards