Bug #1969
closed
IPsec refuses connection after first Cisco Client connection
0%
Description
Full details etc in thread
http://forum.pfsense.org/index.php/topic,41631.0.html
I have mobile IPsec set up, and Shrewsoft VPN client connects just fine. Cisco VPN client also connects and works perfectly, so long as it is the first VPN connection since a reboot. If it is not, it will "connect", but will refuse to route any traffic, and you will have no internet until you disconnect. It also appears that once a Cisco client has connected, Shrewsoft will behave similarly until a reboot.
Here are my settings:
My settings:
Using Mobile IPsec--
Providing a virtual IP and DNS
Phase 1 settings:
Interface: WAN
Auth Method: Mutual PSK + Xauth
Negotiation: Agressive
My identifier: My IP address
Peer identifier: UDN (user@domain.com)
preshared key: mypks
Policy Generation: on
Proposal checking: obey
Encryption: AES128, with MD5
DH key group 2
Nat Traversal enabled
DPD on, 5 seconds, 5 retries
Phase 2:
Mode: tunnel
Local network: 0.0.0.0/0
Protocol: ESP
Encryption: AES, 3des
Hash: md5
PFS off
pfSense is installed on testing hardware (a Dell Dimension desktop, intel chipsets etc), and has no access to anything sensitive, so if desired I can provide limited access to the web interface and to IPsec for testing.
Please let me know, as it would be wonderful if it could be a drop-in replacement for expensive Cisco gear, with no client changes required (especially as the Cisco client is particularly good).
Thanks.
Updated by c c about 13 years ago
I believe this to be the same issue as bug 1970, except that somehow the Cisco client is not disconnecting properly (or pfSense doesnt know how to interpret the disconnection).
Updated by Jim Pingle almost 12 years ago
- Status changed from New to Feedback
Worth trying again on a recent 2.1, and keep the recent edits to the recommending settings for mobile IPsec in mind from here:
http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0
Updated by c c over 11 years ago
I can confirm that this issue occurs with the 2.1 nightly as of 4/23/2013 with the latest Cisco VPN Ipsec client, using Strict / Unique / Force and all options as specified in
http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0
If proposal checking is set to "strict", I get
Apr 28 12:19:31 racoon: [Self]: INFO: respond new phase 1 negotiation: {Scrubbed}[500]<=>{Scrubbed}[50539]
Apr 28 12:19:31 racoon: INFO: begin Aggressive mode.
Apr 28 12:19:31 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Apr 28 12:19:31 racoon: INFO: received Vendor ID: DPD
Apr 28 12:19:31 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 28 12:19:31 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Apr 28 12:19:31 racoon: INFO: received Vendor ID: CISCO-UNITY
Apr 28 12:19:31 racoon: [{Scrubbed}] INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
Apr 28 12:19:31 racoon: ERROR: no suitable proposal found.
Apr 28 12:19:31 racoon: [{Scrubbed}] ERROR: failed to get valid proposal.
Apr 28 12:19:31 racoon: [{Scrubbed}] ERROR: failed to pre-process ph1 packet [Check Phase 1 settings, lifetime, algorithm] (side: 1, status 1).
Apr 28 12:19:31 racoon: [{Scrubbed}] ERROR: phase1 negotiation failed.
If it is set to "obey", the issue described (one correct connection, followed by all others failing) recurs with the following log:
Apr 28 12:24:29 racoon: [Self]: INFO: ISAKMP-SA established {SERVER_IP}[4500]-{CLIENT_IP}[59241] spi:7db617222bab00f1:2ca5d8efdb8a9a4a
Apr 28 12:24:29 racoon: INFO: Using port 0
Apr 28 12:24:29 racoon: user 'ipsectest' authenticated
Apr 28 12:24:29 racoon: INFO: login succeeded for user "ipsectest"
Apr 28 12:24:29 racoon: WARNING: Ignored attribute INTERNAL_ADDRESS_EXPIRY
Apr 28 12:24:29 racoon: ERROR: Cannot open "/etc/motd"
Apr 28 12:24:29 racoon: WARNING: Ignored attribute 28683
Apr 28 12:24:29 racoon: WARNING: Ignored attribute 28684
Apr 28 12:24:29 racoon: [Self]: INFO: respond new phase 2 negotiation: {SERVER_IP}[4500]<=>{CLIENT_IP}[59241]
Apr 28 12:24:29 racoon: INFO: Update the generated policy : 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in
{REPEATS X4} Apr 28 12:24:29 racoon: ERROR: not matched {REPEATS X4}
Apr 28 12:24:29 racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Apr 28 12:24:29 racoon: INFO: Adjusting peer's encmode UDP-Tunnel(61443)->Tunnel(1)
Apr 28 12:24:29 racoon: WARNING: authtype mismatched: my:hmac-sha peer:hmac-md5
Apr 28 12:24:29 racoon: ERROR: not matched
Apr 28 12:24:29 racoon: INFO: Adjusting peer's encmode UDP-Tunnel(61443)->Tunnel(1)
Apr 28 12:24:29 racoon: [Self]: INFO: IPsec-SA established: ESP {SERVER_IP}[500]->{CLIENT_IP}[500] spi=38303437(0x24876cd)
Apr 28 12:24:29 racoon: [Self]: INFO: IPsec-SA established: ESP {SERVER_IP}[500]->{CLIENT_IP}[500] spi=3442386948(0xcd2ea804)
Apr 28 12:24:30 racoon: ERROR: no configuration found for {CLIENT_IP}.
Apr 28 12:24:30 racoon: ERROR: failed to begin ipsec sa negotication.
Apr 28 12:24:41 racoon: ERROR: no configuration found for {CLIENT_IP}.
Apr 28 12:24:41 racoon: ERROR: failed to begin ipsec sa negotication.
Apr 28 12:24:42 racoon: ERROR: no configuration found for {CLIENT_IP}.
{ad infinitum until disconnect}
{Disconnecting here}
Apr 28 12:29:30 racoon: [98.218.150.61] ERROR: delete payload with invalid doi:0.
Apr 28 12:29:30 racoon: [Self]: INFO: ISAKMP-SA expired {SERVER_IP}[4500]-{CLIENT_IP}[59949] spi:38e4590885e9aa23:bcb3607bd17ead8e
Apr 28 12:29:30 racoon: INFO: deleting a generated policy.
Apr 28 12:29:30 racoon: [Self]: INFO: ISAKMP-SA deleted {SERVER_IP}[4500]-{CLIENT_IP}[59949] spi:38e4590885e9aa23:bcb3607bd17ead8e
Apr 28 12:29:30 racoon: INFO: Released port 0
The "warning: authtype mismatched" can be eliminated by switching to MD5, but it doesnt make a difference. Generating traffic triggers two more "error: failed... error: no config..." lines in the ipsec log.
I can do a packet capture on the IPSec interface of pfsense, and I can see incoming pings, and their destination:
12:52:18.793013 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1871, length 40
12:52:19.826520 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1872, length 40
12:52:21.329649 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1873, length 40
12:52:23.829947 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1881, length 40
12:52:25.326576 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1882, length 40
After I disconnect, and have cleared the ipsec log, this appears after a moment or two:
Apr 28 12:49:50 racoon: DEBUG: pk_recv: retry[0] recv()
Apr 28 12:49:50 racoon: DEBUG: got pfkey ACQUIRE message
Apr 28 12:49:50 racoon: DEBUG: suitable outbound SP found: 0.0.0.0/0[0] 10.1.53.1/32[0] proto=any dir=out.
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501288: {LAN_SUBNET}/24[0] {LAN_IP}/32[0] proto=any dir=in
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501648: {LAN_IP}/32[0] {LAN_SUBNET}/24[0] proto=any dir=out
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x285013c8: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in
Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: suitable inbound SP found: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Resolved
these scenarios were fixed a while back for at least the significant majority. Any outstanding issue in racoon is no longer applicable since we use strongswan now in 2.2.