CLOSED: pfSense to replace WatchGuard SOHO 6

rickh925

The WatchGuard 6 FW appliance died today at one of my clients. I replaced it with a backup pfSense ALIX unit. Internet comms are good. Only problem is that I can't get the IPSEC tunnel to go through Phase 2 with the remote office.

I'm on pfSense 2.1.3.

I have all of the settings from the old FW, but it seems to be getting tripped up on the Proposal. I have Phase 1 set to Default Policy Generation and Obey for the Proposal Checking. The other office is managed by another IT guy so I need to do some coordination. I can't remember what device they have up there, but think it is a newer model WatchGuard device. The log looks like it is at least communicating, but failing in the Proposal selection.

From the IPsec log with some messages removed since it is pretty long. (1.1.1.1 is the remote site and 2.2.2.2 is my local site):

Jun 2 23:58:20	racoon: [Mel-Tit]: [1.1.1.1] ERROR: error message: 'u No proposal is chosen'.
Jun 2 23:58:20	racoon: [Mel-Tit]: [1.1.1.1] ERROR: notification NO-PROPOSAL-CHOSEN received in informational exchange.
Jun 2 23:58:09	racoon: [Mel-Tit]: [1.1.1.1] ERROR: notification payload: 800b0001800c7080 .
Jun 2 23:58:09	racoon: [Mel-Tit]: [1.1.1.1] ERROR: notification RESPONDER-LIFETIME received in identity exchange.
Jun 2 23:58:09	racoon: DEBUG: succeed.
Jun 2 23:58:09	racoon: DEBUG: seen nptype=11(notify)
Jun 2 23:58:09	racoon: DEBUG: seen nptype=8(hash)
Jun 2 23:58:09	racoon: DEBUG: seen nptype=5(id)
Jun 2 23:58:09	racoon: DEBUG: begin.
Jun 2 23:58:09	racoon: DEBUG: use ID type of IPv4_address
Jun 2 23:58:09	racoon: DEBUG: 5b355031 ca6cf6a9
Jun 2 23:58:09	racoon: DEBUG: IV computed:
Jun 2 23:58:09	racoon: DEBUG: encryption(3des)
Jun 2 23:58:09	racoon: DEBUG: hash(sha1)
Jun 2 23:58:09	racoon: DEBUG: compute DH's shared.
Jun 2 23:58:09	racoon: DEBUG: begin.
Jun 2 23:58:09	racoon: DEBUG: de30e63b c22cf480 1f914637 6ed90936 04100200 00000000 000000c4 0a000064 b401d6b5 6a97395a b1fc1d16 4b1fd569 d412813a 5e51826c 0c4c730a f436a89a 6eabf341 d86b881a 860c91a8 a52c04b4 005962e7 57137017 ba33cbd0 a644a853 84905a01 929eeda7 e65730a0 ddbc7710 362e31db ce03223d 79b0e3fc eb5da77e 0d000018 892d2854 851eee7e e1ecbf6a c18eb708 2535ea21 0d00000c 404bf439 522ca3f6 0d00000c 09002689 dfd6b712 00000014 afcad713 68a1f1c9 6b8696fc 77570100
Jun 2 23:58:09	racoon: DEBUG: 196 bytes message received from 1.1.1.1[500] to 2.2.2.2[500]
Jun 2 23:58:09	racoon: DEBUG: ===
Jun 2 23:58:08	racoon: DEBUG: resend phase1 packet de30e63bc22cf480:1f9146376ed90936

Thanks
Rick Huebner

m4st3rc1p0

can you advise what's on the other end (your remote site) is it a pfsense also, i think you have a misconfiguration on your ipsec

rickh925

The other end is a Sonicwall TZ 200. I ordered a Sonicwall TZ 205 to replace the WatchGuard as the client didn't want to pay for me to troubleshoot this connection.

Anyway, the IPSec tunnel is intermittent. In fact, it is up most of the time EXCEPT when someone tries to connect across it. I have another client that is having trouble with OpenVPN and both are running across BrightHouse. I am starting to wonder if there is an MTU issue. I need to drop the MTU to 1300 and see if that helps.

cmb

NO-PROPOSAL-CHOSEN means the remote end is telling you it has nothing matching your P1 settings. Many times a wrong local or remote IP for the outside of the tunnel. Could potentially be any number of things in the P1. Unless somehow it stops complaining about that and negotiates successfully, you're not getting to the point where dropping large packets across the VPN would matter. If you can't ping across at default ping sizes, that's not the issue.