IPsec with Smoothwall connects but drops with traffic
-
Hi
1st posting, hope someone can help here.
We have been running pfsense as a virtual appliance at a remote site for almost a year with an IPsec link back to our main campus so we can remotely access CCTV, door access systems, etc, and this has been running fine.
We have recently updated both our pfSense and Smoothwall appliances and now we are unable to access any remote systems (physical or virtual) except the pfSense appliance itself.
All devices on the remote network ping OK and we can happily access the pfSense desktop (either on the WAN or LAN address) without any problems at all. However, any attempt to access anything else causes the tunnel to drop out and reconnect.
This is a segment of the logs
Oct 2 08:57:08 charon 09[NET] received packet: from <remote_gateway>[500] to <pfsense_wan_address>[500] (68 bytes) Oct 2 08:57:08 charon 09[NET] <con1000|200> received packet: from <remote_gateway>[500] to <pfsense_wan_address>[500] (68 bytes) Oct 2 08:57:08 charon 09[ENC] parsed INFORMATIONAL_V1 request 1353737598 [ HASH D ] Oct 2 08:57:08 charon 09[ENC] <con1000|200> parsed INFORMATIONAL_V1 request 1353737598 [ HASH D ] Oct 2 08:57:08 charon 09[IKE] received DELETE for ESP CHILD_SA with SPI 17a40464 Oct 2 08:57:08 charon 09[IKE] <con1000|200> received DELETE for ESP CHILD_SA with SPI 17a40464 Oct 2 08:57:08 charon 09[CHD] CHILD_SA con1000{264} state change: REKEYED => DELETING Oct 2 08:57:08 charon 09[CHD] <con1000|200> CHILD_SA con1000{264} state change: REKEYED => DELETING Oct 2 08:57:08 charon 09[IKE] closing CHILD_SA con1000{264} with SPIs c3ad4b67_i (5248919 bytes) 17a40464_o (8685640 bytes) and TS <local_network>/22|/0 === <remote_network>/12|/0 Oct 2 08:57:08 charon 09[IKE] <con1000|200> closing CHILD_SA con1000{264} with SPIs c3ad4b67_i (5248919 bytes) 17a40464_o (8685640 bytes) and TS <local_network>/22|/0 === <remote_network>/12|/0 Oct 2 08:57:08 charon 09[CHD] CHILD_SA con1000{264} state change: DELETING => DELETED Oct 2 08:57:08 charon 09[CHD] <con1000|200> CHILD_SA con1000{264} state change: DELETING => DELETED Oct 2 08:57:08 charon 09[CHD] CHILD_SA con1000{264} state change: DELETED => DESTROYING Oct 2 08:57:08 charon 09[CHD] <con1000|200> CHILD_SA con1000{264} state change: DELETED => DESTROYING Oct 2 09:13:53 charon 11[CFG] vici client 55 connected Oct 2 09:13:53 charon 11[CFG] vici client 55 connected Oct 2 09:13:53 charon 05[CFG] vici client 55 registered for: list-sa Oct 2 09:13:53 charon 05[CFG] vici client 55 registered for: list-sa Oct 2 09:13:53 charon 05[CFG] vici client 55 requests: list-sas Oct 2 09:13:53 charon 05[CFG] vici client 55 requests: list-sas Oct 2 09:13:53 charon 05[CFG] vici client 55 disconnected Oct 2 09:13:53 charon 05[CFG] vici client 55 disconnected Oct 2 09:13:57 charon 01[CFG] vici client 56 connected Oct 2 09:13:57 charon 01[CFG] vici client 56 connected Oct 2 09:13:57 charon 08[CFG] vici client 56 registered for: list-sa Oct 2 09:13:57 charon 08[CFG] vici client 56 registered for: list-sa Oct 2 09:13:57 charon 01[CFG] vici client 56 requests: list-sas Oct 2 09:13:57 charon 01[CFG] vici client 56 requests: list-sas Oct 2 09:13:57 charon 05[CFG] vici client 56 disconnected Oct 2 09:13:57 charon 05[CFG] vici client 56 disconnected
The IPsec tunnel is configured as below
Key Exchange Version: IKEv1
Authentication Method: Mutual PSK
Negotiation Mode: Main
Indentifier: IP Address
P1 Proposal: 3DES/SHA1/DH5/3600 seconds/Disable rekey/NAT = auto/DPD=enabled/Delay=10/Maxfail=5
P2 Proposal: ESP/3DES/SHA1/PFS Key 5 (1536)/3600 secondsAES-NI CPU Crypto is not supported on the virtual appliance
For completeness, this is a segment of the IPsec logs from the Smoothwall appliance
08:57:08 CHalls deleting state (STATE_QUICK_I2) and sending notification 08:57:08 CHalls ESP traffic information: in=0B out=0B 09:21:55 CHalls initiating Main Mode to replace #65 09:21:55 CHalls transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 09:21:55 CHalls STATE_MAIN_I2: sent MI2, expecting MR2 09:21:55 CHalls transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 09:21:55 CHalls STATE_MAIN_I3: sent MI3, expecting MR3 09:21:55 CHalls Peer ID is ID_IPV4_ADDR: <pfSense WAN address> 09:21:55 CHalls transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 09:21:55 CHalls STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=3des_cbc_192 integ=sha group=MODP1536}
As it was working fine before, I can only assume that one of the updates has caused the issue. A full reboot of the remote host system seemed to restore normal service for a short period but it soon stopped working again.
Grateful for any suggestions or ideas
thanks all