Welcome, Guest. Please login or register.
Did you miss your activation email?
+  pfSense Forum
|-+  pfSense English Support» IPsec» IPSec connected but not passing traffic
Username:
Password:
 
Home Help Search Login Register
 

Pages: [1]   Go Down
« previous next »
  Print  
Author Topic: IPSec connected but not passing traffic  (Read 4397 times)
0 Members and 1 Guest are viewing this topic.
namezero111111
Jr. Member
**
Offline Offline

Posts: 80


View Profile
« on: April 11, 2012, 04:47:38 pm »
Dear folks,

I have a problem with an IPSec tunnel where after any amount of time (sometimes 20 mins, sometimes hours or days), traffic will just stop flowing even though the tunnel is up. One side will show multiple SAD entries.
If I start deleting "unused" SADs, the tunnel will start working again. Obviously that isn't a solution.

Here are some facts:
- Both sides running on 2.0.1-RELEASE (amd64) built on Mon Dec 12 18:43:51 EST 2011
- Both sides have "Prefer older SAs" in the advanced settings disabled (it used to be enabled but made no difference).
- DPD is enabled and I tried playing with the values as well as disabling it completely
- With DPD disabled, the tunnel stays stalled longer

Log file from main side:
Code:
Apr 11 21:08:42 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:37 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:32 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:27 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:22 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:17 racoon: [SRVNAME1]: [192.168.4.170] ERROR: unknown Informational exchange received.
Apr 11 21:08:09 racoon: [SRVNAME1]: INFO: ISAKMP-SA deleted 192.168.4.161[500]-192.168.4.170[500] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 21:08:09 racoon: [SRVNAME1]: INFO: ISAKMP-SA expired 192.168.4.161[500]-192.168.4.170[500] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 20:44:09 racoon: [SRVNAME1]: INFO: ISAKMP-SA established 192.168.4.161[500]-192.168.4.170[500] spi:925fc1a1ea707663:82dd5b1ab2aae2a1
Apr 11 20:44:09 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 11 20:44:09 racoon: INFO: received Vendor ID: DPD
Apr 11 20:44:09 racoon: INFO: begin Identity Protection mode.
Apr 11 20:44:09 racoon: [SRVNAME1]: INFO: initiate new phase 1 negotiation: 192.168.4.161[500]<=>192.168.4.170[500]
Apr 11 20:44:09 racoon: [SRVNAME1]: INFO: renegotiating phase1 to 192.168.4.170 due to active phase2
Apr 11 19:08:10 racoon: [SRVNAME1]: INFO: IPsec-SA established: ESP 192.168.4.161[500]->192.168.4.170[500] spi=177262234(0xa90ce9a)
Apr 11 19:08:10 racoon: [SRVNAME1]: INFO: IPsec-SA established: ESP 192.168.4.161[500]->192.168.4.170[500] spi=16163632(0xf6a330)
Apr 11 19:08:10 racoon: [SRVNAME1]: INFO: initiate new phase 2 negotiation: 192.168.4.161[500]<=>192.168.4.170[500]
Apr 11 19:08:09 racoon: [SRVNAME1]: [192.168.4.170] INFO: received INITIAL-CONTACT
Apr 11 19:08:09 racoon: [SRVNAME1]: INFO: ISAKMP-SA established 192.168.4.161[500]-192.168.4.170[500] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 19:08:09 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 11 19:08:09 racoon: INFO: received Vendor ID: DPD
Apr 11 19:08:09 racoon: INFO: begin Identity Protection mode.
Apr 11 19:08:09 racoon: [SRVNAME1]: INFO: initiate new phase 1 negotiation: 192.168.4.161[500]<=>192.168.4.170[500]
Apr 11 19:08:09 racoon: [SRVNAME1]: INFO: IPsec-SA request for 192.168.4.170 queued due to no phase1 found.
Apr 11 19:08:06 racoon: ERROR: such policy already exists. anyway replace it: 192.168.5.176/28[0] 192.168.0.0/16[0] proto=any dir=in
Apr 11 19:08:06 racoon: ERROR: such policy already exists. anyway replace it: 192.168.0.0/16[0] 192.168.5.176/28[0] proto=any dir=out
Apr 11 19:08:06 racoon: ERROR: such policy already exists. anyway replace it: 192.168.4.0/27[0] 192.168.4.11/32[0] proto=any dir=in
Apr 11 19:08:06 racoon: ERROR: such policy already exists. anyway replace it: 192.168.4.11/32[0] 192.168.4.0/27[0] proto=any dir=out
Apr 11 19:08:06 racoon: INFO: unsupported PF_KEY message REGISTER
Apr 11 19:08:06 racoon: [Self]: INFO: 192.168.4.161[500] used as isakmp port (fd=15)
Apr 11 19:08:06 racoon: [Self]: INFO: 192.168.4.161[500] used for NAT-T
Apr 11 19:08:06 racoon: [Self]: INFO: 192.168.4.161[4500] used as isakmp port (fd=14)
Apr 11 19:08:06 racoon: [Self]: INFO: 192.168.4.161[4500] used for NAT-T
Apr 11 19:08:06 racoon: INFO: Reading configuration from "/var/etc/racoon.conf"
Apr 11 19:08:06 racoon: INFO: @(#)This product linked OpenSSL 0.9.8n 24 Mar 2010 (http://www.openssl.org/)
Apr 11 19:08:06 racoon: INFO: @(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net)

Main site config:
Code:
# This file is automatically generated. Do not edit
path pre_shared_key "/var/etc/psk.txt";

path certificate  "/var/etc";


listen
{
        adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
        isakmp 192.168.4.161 [500];
        isakmp_natt 192.168.4.161 [4500];
}


remote 192.168.4.170
{
        ph1id 1;
        exchange_mode main;
        my_identifier address 192.168.4.161;
        peers_identifier address 192.168.4.170;
        ike_frag on;
        generate_policy = off;
        initial_contact = on;
        nat_traversal = off;


        dpd_delay = 10;
        dpd_maxfail = 30;
        support_proxy on;
        proposal_check claim;


        proposal
        {
                authentication_method pre_shared_key;
                encryption_algorithm blowfish 128;
                hash_algorithm sha1;
                dh_group 2;
                lifetime time 7200 secs;
        }
}

sainfo subnet 192.168.0.0/16 any subnet 192.168.5.176/28 any
{
        remoteid 1;
        encryption_algorithm aes 128;
        authentication_algorithm hmac_sha1;

        lifetime time 14400 secs;
        compression_algorithm deflate;
}

Log file from remote side:
Code:
Apr 11 21:09:30 racoon: [REMOTESRV]: INFO: ISAKMP-SA deleted 192.168.4.170[500]-192.168.4.161[47456] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 21:09:30 racoon: [REMOTESRV]: INFO: ISAKMP-SA expired 192.168.4.170[500]-192.168.4.161[47456] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 20:45:02 racoon: [REMOTESRV]: INFO: ISAKMP-SA established 192.168.4.170[500]-192.168.4.161[47456] spi:925fc1a1ea707663:82dd5b1ab2aae2a1
Apr 11 20:45:02 racoon: INFO: received Vendor ID: DPD
Apr 11 20:45:02 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 11 20:45:02 racoon: INFO: begin Identity Protection mode.
Apr 11 20:45:02 racoon: [REMOTESRV]: INFO: respond new phase 1 negotiation: 192.168.4.170[500]<=>192.168.4.161[47456]
Apr 11 19:09:31 racoon: [REMOTESRV]: INFO: IPsec-SA established: ESP 192.168.4.170[500]->192.168.4.161[500] spi=16163632(0xf6a330)
Apr 11 19:09:31 racoon: [REMOTESRV]: INFO: IPsec-SA established: ESP 192.168.4.170[500]->192.168.4.161[500] spi=177262234(0xa90ce9a)
Apr 11 19:09:31 racoon: [REMOTESRV]: INFO: respond new phase 2 negotiation: 192.168.4.170[500]<=>192.168.4.161[47456]
Apr 11 19:09:30 racoon: [REMOTESRV]: [192.168.4.161] INFO: received INITIAL-CONTACT
Apr 11 19:09:30 racoon: [REMOTESRV]: INFO: ISAKMP-SA established 192.168.4.170[500]-192.168.4.161[47456] spi:46e62d437290ff7b:5cc826162841f6bd
Apr 11 19:09:30 racoon: INFO: received Vendor ID: DPD
Apr 11 19:09:30 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 11 19:09:30 racoon: INFO: begin Identity Protection mode.
Apr 11 19:09:30 racoon: [REMOTESRV]: INFO: respond new phase 1 negotiation: 192.168.4.170[500]<=>192.168.4.161[47456]
Apr 11 19:09:23 racoon: [REMOTESRV]: INFO: ISAKMP-SA deleted 192.168.4.170[500]-192.168.4.161[19023] spi:570fe0f8e55158b9:4fc91de568468927
Apr 11 19:09:23 racoon: INFO: purged ISAKMP-SA spi=570fe0f8e55158b9:4fc91de568468927.
Apr 11 19:09:23 racoon: INFO: purging ISAKMP-SA spi=570fe0f8e55158b9:4fc91de568468927.
Apr 11 19:09:23 racoon: [REMOTESRV]: [192.168.4.161] WARNING: remote address mismatched. db=192.168.4.161[19023], act=192.168.4.161[47456]
Apr 11 19:09:22 racoon: ERROR: 192.168.4.161 give up to get IPsec-SA due to time up to wait.
Apr 11 19:08:55 racoon: NOTIFY: the packet is retransmitted by 192.168.4.161[47456] (2).
Apr 11 19:08:52 racoon: [REMOTESRV]: INFO: initiate new phase 2 negotiation: 192.168.4.170[500]<=>192.168.4.161[19023]
Apr 11 19:08:45 racoon: NOTIFY: the packet is retransmitted by 192.168.4.161[47456] (2).
Apr 11 19:08:40 racoon: INFO: unsupported PF_KEY message REGISTER
Apr 11 19:08:39 racoon: ERROR: pfkey DELETE received: ESP 192.168.4.161[500]->192.168.4.170[500] spi=248157879(0xeca96b7)
Apr 11 19:08:39 racoon: ERROR: pfkey DELETE received: ESP 192.168.4.161[500]->192.168.4.170[500] spi=262712372(0xfa8ac34)
Apr 11 19:08:39 racoon: INFO: unsupported PF_KEY message REGISTER

Remote side config:
Code:
# This file is automatically generated. Do not edit
path pre_shared_key "/var/etc/psk.txt";

path certificate  "/var/etc";


listen
{
        adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
        isakmp 192.168.4.170 [500];
        isakmp_natt 192.168.4.170 [4500];
}


remote 192.168.4.161
{
        ph1id 1;
        exchange_mode main;
        my_identifier address 192.168.4.170;
        peers_identifier address 192.168.4.161;
        ike_frag on;
        generate_policy = off;
        initial_contact = on;
        nat_traversal = off;


        dpd_delay = 10;
        dpd_maxfail = 30;
        support_proxy on;
        proposal_check claim;


        proposal
        {
                authentication_method pre_shared_key;
                encryption_algorithm blowfish 128;
                hash_algorithm sha1;
                dh_group 2;
                lifetime time 7200 secs;
        }
}

sainfo subnet 192.168.5.176/28 any subnet 192.168.0.0/16 any
{
        remoteid 1;
        encryption_algorithm aes 128;
        authentication_algorithm hmac_sha1;

        lifetime time 14400 secs;
        compression_algorithm deflate;
}


The only posts I could find were related to mismatched settings, but they all seem to agree.

Does anyone have any idea? It seems like other people have this working.
Logged
Gero
Newbie
*
Offline Offline

Posts: 10


View Profile
« Reply #1 on: May 14, 2012, 05:06:37 pm »
I have no exact indication why your setup is not working but have you tried changing to MD5 instead of SHA1 in the proposal?
Logged
namezero111111
Jr. Member
**
Offline Offline

Posts: 80


View Profile
« Reply #2 on: May 15, 2012, 11:10:34 am »
Thanks for the reply!

I forgot to close the issue. My apologies.
It turned out to be the underlying connection being flaky.

However, if that does happen, the SAD state go out of sync and the tunnel becomes unusable (i.e. connection breaks for let's say 3 min, then IPSec might be unusable for another two hours before the SADs get synchronized again).

Has anyone else seen this issue?
Logged
dhatz
Hero Member
*****
Offline Offline

Posts: 931


View Profile
« Reply #3 on: May 15, 2012, 12:44:34 pm »
namezero111111, what is your setting of

System -> Advanced -> Misc -> Security Assoc -> Prefer older IPsec SAs

?
Logged
cmb
Administrator
Hero Member
*****
Offline Offline

Posts: 6055


View Profile WWW
« Reply #4 on: May 18, 2012, 02:28:15 am »
Quote from: dhatz on May 15, 2012, 12:44:34 pm
namezero111111, what is your setting of

System -> Advanced -> Misc -> Security Assoc -> Prefer older IPsec SAs

?

If it's checked, uncheck it. It's almost never necessary. The last 3 IPsec issues along the lines of failing for a while where the config was otherwise correct have been caused by that, people seem to want to check it for some reason when it's virtually never desirable.
Logged
pfSense Commercial Support

Paying customers receive support priority and as in depth of assistance as desired through the official commercial support channels at portal.pfsense.org. Forum users receive as much help as time permits.
namezero111111
Jr. Member
**
Offline Offline

Posts: 80


View Profile
« Reply #5 on: May 25, 2012, 05:06:05 pm »
Thanks everybody and apologies for taking so long to reply.
I've tried both with Older Sas on and off, but neither seemed to be working better than the other.

With DPD enabled, shouldn't the two endpoints resynchronize SAD states when one of them notices a dead peer?
Logged
cmb
Administrator
Hero Member
*****
Offline Offline

Posts: 6055


View Profile WWW
« Reply #6 on: May 26, 2012, 02:31:20 pm »
Quote from: namezero111111 on May 25, 2012, 05:06:05 pm
With DPD enabled, shouldn't the two endpoints resynchronize SAD states when one of them notices a dead peer?

Yes, that's the best option to ensure neither end has old SAs.
Logged
pfSense Commercial Support

Paying customers receive support priority and as in depth of assistance as desired through the official commercial support channels at portal.pfsense.org. Forum users receive as much help as time permits.
namezero111111
Jr. Member
**
Offline Offline

Posts: 80


View Profile
« Reply #7 on: May 26, 2012, 06:44:51 pm »
Like I said, I tried that, but unfortunately we were still experiencing out of sync SAD states. We still have it enabled, but it looks like both sides see the dead peer and then generate new SADs on their own?
Logged
chia
Newbie
*
Offline Offline

Posts: 4


View Profile
« Reply #8 on: July 19, 2012, 03:56:38 am »
PFSENSE, NANOBSD, 2.0.1
I had the same problem, IPSEC tunnel was establised, all green, no traffic goes through.
When you look at SAD, SAD (Status,Ipsec, SAD)shows me multiple connections.
I think, the reason are short interrupts, Phase1 does not recognise the break, stays established, but Phase2 opens a new connection.
But this does not work.
My solution:
Change Mode from aggressive to main on both sides. (even with dynamic IPs)
Logged
diegogyn
Full Member
***
Offline Offline

Posts: 138


View Profile
« Reply #9 on: July 20, 2012, 12:20:32 pm »
I have the same issue but I´m using Side-to-Client (Road Warriors).
I did my config based on this link: http://doc.pfsense.org/index.php/IPsec_for_road_warriors_in_PfSense_2.0.1_with_PSK_in_stead_of_xauth

The IPSEC tunnel was establised but I can´t se the other network (The gateway always is empty)

Ideias?
Logged
dhatz
Hero Member
*****
Offline Offline

Posts: 931


View Profile
« Reply #10 on: July 26, 2012, 12:34:45 pm »
Quote from: namezero111111 on April 11, 2012, 04:47:38 pm
I have a problem with an IPSec tunnel where after any amount of time (sometimes 20 mins, sometimes hours or days), traffic will just stop flowing even though the tunnel is up. One side will show multiple SAD entries.
If I start deleting "unused" SADs, the tunnel will start working again. Obviously that isn't a solution.

Here are some facts:
- Both sides running on 2.0.1-RELEASE (amd64) built on Mon Dec 12 18:43:51 EST 2011
- Both sides have "Prefer older SAs" in the advanced settings disabled (it used to be enabled but made no difference).
- DPD is enabled and I tried playing with the values as well as disabling it completely
- With DPD disabled, the tunnel stays stalled longer

Are you still having this problem ?

You might also want to check the discussion at the ipsec-tools-devel list:
http://marc.info/?l=ipsec-tools-devel&m=129842631426424&w=2
Logged
Pages: [1]   Go Up
  Print  
« previous next »
 
Jump to:  

 

Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Page created in 0.03 seconds with 20 queries.