ScreenOS Firewalls (NOT SRX)
Reply
Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

VPN tunnels drop for lengthy periods, causing outages... ???

Corporate office has a pair of SSG-5's upinked to a pair of Cisco routers and then out to the Internet.

Field offices have Cisco 1720 routers uplinked to DSL modems and then out to the Internet.

 

At random times, these VPN tunnels stop passing traffic, even though I never drop a packet between the external interfaces of the Juniper firewall and Cisco router.

 

Juniper config for one of the tunnels:

------------------- 

set ike gateway "Temecula-Gateway" address 72.1.1.1 Main outgoing-interface "ethernet0/0" preshare "*****" proposal "pre-g2-3des-md5"
set vpn "Temecula-IKE" gateway "Temecula-Gateway" no-replay tunnel idletime 0 proposal "g2-esp-3des-md5"
set vpn "Temecula-IKE" monitor optimized rekey
set vpn "Temecula-IKE" id 0x18 bind interface tunnel.5
set vpn "Temecula-IKE" dscp-mark 0
set interface "tunnel.5" zone "Untrust"
set interface tunnel.5 ip unnumbered interface ethernet0/0
set route 192.168.21.0/24 interface tunnel.5
--------------------

 

Field office Cisco config for the above:

 

------------------------

access-list 110 permit ip 192.168.21.0 0.0.0.255 192.168.0.0 0.0.0.255
crypto ipsec transform-set 3des-md5 esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600

crypto map js-ipsec 10 ipsec-isakmp
 description San Diego
 set peer 63.1.1.1
 set transform-set 3des-md5
 set pfs group2
 match address 110

crypto isakmp key ***** address 63.1.1.1
 

crypto isakmp peer address 63.1.1.1
 set aggressive-mode password *****

set aggressive-mode client-endpoint ipv4-address 166.1.1.1
 ---------------

 

On the Cisco router, I have a secondary interface set up to use with a Verizon card as a backup (the 166.1.1.1 IP).  Not sure if the backup configs are causing the issue or not, but I just enabled debugging on the Cisco router, and setup a Syslog server for the Juniper firewalls to catch some data when the drop occurs.

 

Any ideas? 

Trusted Expert Trusted Expert
Trusted Expert
WL
Posts: 790
Registered: ‎07-26-2008

Re: VPN tunnels drop for lengthy periods, causing outages... ???

Hi

 

When the traffic stops passing, do you see any event logs on the FW for the VPN?

Could you check the "get event" to see if the problem is because the VPN went down or did not rekey properly?

Also, does the problem recover by itself or do you need to clear the sessions etc to get connetivity back?

****pls click the button " Accept as Solution" if my post helped to solve your problem****
Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

I have seen logs on the firewall saying the tunnel went down, but I just now started working on this problem full time and am waiting for correlation of times in the logs to when my monitoring setup shows the pings start to drop.  Customer complains of their WAN application dropping during this time as well, so it's a definite issue.

 

Problem recovers itself, but I guess the field offices will just power cycle the router to get it back up immediately if they want.

 

I really appreicate the quick response, and I will get logs up from the firewall and router as soon as I hear of the tunnel dropping again. 

 

Thanks again! 

Recognized Expert
PentinProcessor
Posts: 258
Registered: ‎11-06-2007
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

I would try the steps in this KB article:
KB9488 - How to troubleshoot a VPN tunnel that is going up and down which is called from the VPN Resolution Guide.

Step 5 of KB9488 may apply to your environment.

Let us know how it goes.

Regards,

Josine




Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

Ok, so my NMS shows the pings between VPN tunnel endpoints start dropping at 10:58am.  Pings between the external interfaces stay up.

 

From the firewall:

 

-------------

2009-02-24 10:54:52     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1 Phase 2 msg ID 45fa438a: Responded to the peer's first message. (2009-02-24 10:54:51)<000>
2009-02-24 10:54:52     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1 Phase 2 msg ID 45fa438a: Completed negotiations with SPI fc1f8e78, tunnel ID 24, and lifetime 3600 seconds/4194303 KB.
(2009-02-24 10:54:52)<000>
 --------------

 

From the router:

 

--------------
Feb 24 10:54:53.296 PST: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-3des esp-md5-hmac  (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x62FF359B(1660892571), conn_id= 0, keysize= 0, flags= 0x400B
Feb 24 10:54:53.296 PST: IPSEC(lifetime_expiry): SA lifetime threshold reached, expiring in 52 seconds
Feb 24 10:54:53.300 PST: ISAKMP: received ke message (1/1)
Feb 24 10:54:53.300 PST: ISAKMP: set new node 0 to QM_IDLE     
Feb 24 10:54:53.300 PST: SA has outstanding requests  (local 72.1.1.1 port 500, remote 63.1.1.1 port 500)
Feb 24 10:54:53.300 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): sitting IDLE. Starting QM immediately (QM_IDLE      )
Feb 24 10:54:53.300 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):beginning Quick Mode exchange, M-ID of 1174029194
Feb 24 10:54:53.304 PST: CryptoEngine0: generating alg parameter for connid 1
Feb 24 10:54:53.484 PST: CRYPTO_ENGINE: Dh phase 1 status: 0
Feb 24 10:54:53.484 PST: CRYPTO_ENGINE: Dh phase 1 status: OK
Feb 24 10:54:53.488 PST: CryptoEngine0: generate hmac context for conn id 1
Feb 24 10:54:53.492 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): sending packet to 63.1.1.1 my_port 500 peer_port 500 (R) QM_IDLE     
Feb 24 10:54:53.492 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):Node 1174029194, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Feb 24 10:54:53.492 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileysurprised:ld State = IKE_QM_READY  New State = IKE_QM_I_QM1
Feb 24 10:54:53.584 PST: ISAKMP (0:134217729): received packet from 63.1.1.1 dport 500 sport 500 Global (R) QM_IDLE     
Feb 24 10:54:53.588 PST: CryptoEngine0: generate hmac context for conn id 1
Feb 24 10:54:53.588 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing HASH payload. message ID = 1174029194
Feb 24 10:54:53.588 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing SA payload. message ID = 1174029194
Feb 24 10:54:53.588 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):Checking IPSec proposal 1
Feb 24 10:54:53.588 PST: ISAKMP: transform 1, ESP_3DES
Feb 24 10:54:53.588 PST: ISAKMP:   attributes in transform:
Feb 24 10:54:53.588 PST: ISAKMP:      SA life type in seconds
Feb 24 10:54:53.588 PST: ISAKMP:      SA life duration (VPI) of  0x0 0x0 0xE 0x10
Feb 24 10:54:53.592 PST: ISAKMP:      SA life type in kilobytes
Feb 24 10:54:53.592 PST: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
Feb 24 10:54:53.592 PST: ISAKMP:      encaps is 1 (Tunnel)
Feb 24 10:54:53.592 PST: ISAKMP:      authenticator is HMAC-MD5
Feb 24 10:54:53.592 PST: ISAKMP:      group is 2
Feb 24 10:54:53.592 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):atts are acceptable.
Feb 24 10:54:53.592 PST: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-3des esp-md5-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x22
Feb 24 10:54:53.596 PST: CryptoEngine0: validate proposal request
Feb 24 10:54:53.596 PST: Crypto mapdb : proxy_match
    src addr     : 192.168.21.0
    dst addr     : 192.168.0.0
    protocol     : 0
    src port     : 0
    dst port     : 0
Feb 24 10:54:53.600 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing NONCE payload. message ID = 1174029194
Feb 24 10:54:53.600 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing KE payload. message ID = 1174029194
Feb 24 10:54:53.600 PST: CryptoEngine0: generating alg parameter for connid 0
Feb 24 10:54:53.828 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing ID payload. message ID = 1174029194
Feb 24 10:54:53.828 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing ID payload. message ID = 1174029194
Feb 24 10:54:53.828 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing NOTIFY RESPONDER_LIFETIME protocol 3
    spi 4229926520, message ID = 1174029194, sa = 844472AC
Feb 24 10:54:53.828 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileyfrustrated:A authentication status:
    authenticated
Feb 24 10:54:53.828 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing responder lifetime
Feb 24 10:54:53.832 PST: ISAKMP (134217729): responder lifetime of 0kb
Feb 24 10:54:53.832 PST: CryptoEngine0: generate hmac context for conn id 1
Feb 24 10:54:53.832 PST: crypto_engine: ipsec_key_create_by_keys
Feb 24 10:54:53.836 PST: crypto_engine: ipsec_key_create_by_keys
Feb 24 10:54:53.836 PST: CryptoEngine0: clear dh number for conn id 1
Feb 24 10:54:53.836 PST: ISAKMP: Locking peer struct 0x841D3D1C, IPSEC refcount 2 for for stuff_ke
Feb 24 10:54:53.836 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): Creating IPSec SAs
Feb 24 10:54:53.840 PST:         inbound SA from 63.1.1.1 to 72.1.1.1 (f/i)  0/ 0
        (proxy 192.168.0.0 to 192.168.21.0)
Feb 24 10:54:53.840 PST:         has spi 0x62FF359B and conn_id 0 and flags 23
Feb 24 10:54:53.840 PST:         lifetime of 3600 seconds
Feb 24 10:54:53.840 PST:         has client flags 0x0
Feb 24 10:54:53.840 PST:         outbound SA from 72.1.1.1 to 63.1.1.1 (f/i) 0/0
        (proxy 192.168.21.0 to 192.168.0.0)
Feb 24 10:54:53.840 PST:         has spi -65040776 and conn_id 0 and flags 2B
Feb 24 10:54:53.840 PST:         lifetime of 3600 seconds
Feb 24 10:54:53.840 PST:         has client flags 0x0
Feb 24 10:54:53.844 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): sending packet to 63.1.1.1 my_port 500 peer_port 500 (R) QM_IDLE     
Feb 24 10:54:53.844 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):deleting node 1174029194 error FALSE reason "No Error"
Feb 24 10:54:53.844 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):Node 1174029194, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Feb 24 10:54:53.844 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileysurprised:ld State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
Feb 24 10:54:53.848 PST: IPSEC(key_engine): got a queue event with 2 kei messages
Feb 24 10:54:53.848 PST: IPSEC(initialize_sas): ,
  (key eng. msg.) INBOUND local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-3des esp-md5-hmac  (Tunnel),
    lifedur= 3600s and 0kb,
    spi= 0x62FF359B(1660892571), conn_id= 0, keysize= 0, flags= 0x23
Feb 24 10:54:53.852 PST: IPSEC(initialize_sas): ,
  (key eng. msg.) OUTBOUND local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-3des esp-md5-hmac  (Tunnel),
    lifedur= 3600s and 0kb,
    spi= 0xFC1F8E78(4229926520), conn_id= 0, keysize= 0, flags= 0x2B
Feb 24 10:54:53.852 PST: Crypto mapdb : proxy_match
    src addr     : 192.168.21.0
    dst addr     : 192.168.0.0
    protocol     : 0
    src port     : 0
    dst port     : 0
Feb 24 10:54:53.852 PST: IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and 63.1.1.1
Feb 24 10:54:53.856 PST: IPSec: Flow_switching Allocated flow for sibling 800003C0
Feb 24 10:54:53.856 PST: ISAKMP: Locking peer struct 0x841D3D1C, IPSEC refcount 3 for from create_transforms
Feb 24 10:54:53.856 PST: IPSEC(create_sa): sa created,
  (sa) sa_dest= 72.1.1.1, sa_proto= 50,
    sa_spi= 0x62FF359B(1660892571),
    sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2003
Feb 24 10:54:53.856 PST: IPSEC(create_sa): sa created,
  (sa) sa_dest= 63.1.1.1, sa_proto= 50,
    sa_spi= 0xFC1F8E78(4229926520),
    sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2004
Feb 24 10:54:53.856 PST: ISAKMP: Unlocking IPSEC struct 0x841D3D1C from create_transforms, count 2
Feb 24 10:55:03.064 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:55:13.104 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:55:23.148 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:55:33.188 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:55:43.232 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:55:43.844 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileytongue:urging node 1174029194
Feb 24 10:55:45.492 PST: IPSEC(delete_sa): deleting SA,
  (sa) sa_dest= 72.1.1.1, sa_proto= 50,
    sa_spi= 0x763C196E(1983650158),
    sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2007,
  (identity) local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4)
Feb 24 10:55:45.492 PST: crypto engine: deleting IPSec SA SW:7
Feb 24 10:55:45.492 PST: crypto_engine: IPSec SA delete
Feb 24 10:55:45.496 PST: IPSEC(delete_sa): deleting SA,
  (sa) sa_dest= 63.1.1.1, sa_proto= 50,
    sa_spi= 0xFC1F8E74(4229926516),
    sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2006,
  (identity) local= 72.1.1.1, remote= 63.1.1.1,
    local_proxy= 192.168.21.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 192.168.0.0/255.255.255.0/0/0 (type=4)
Feb 24 10:55:45.496 PST: crypto engine: deleting IPSec SA SW:6
Feb 24 10:55:45.496 PST: IPSec: Flow_switching Deallocated flow for sibling 800003C1
Feb 24 10:55:45.496 PST: ISAKMP: Unlocking IPSEC struct 0x841D3D1C from delete_siblings, count 1
Feb 24 10:55:45.500 PST: ISAKMP: received ke message (3/1)
Feb 24 10:55:45.500 PST: ISAKMP: set new node 1750568199 to QM_IDLE     
Feb 24 10:55:45.500 PST: CryptoEngine0: generate hmac context for conn id 1
Feb 24 10:55:45.504 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): sending packet to 63.1.1.1 my_port 500 peer_port 500 (R) QM_IDLE     
Feb 24 10:55:45.504 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileytongue:urging node 1750568199
Feb 24 10:55:45.504 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL
Feb 24 10:55:45.508 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileysurprised:ld State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

Feb 24 10:55:45.508 PST: crypto_engine: IPSec SA delete
Feb 24 10:55:45.724 PST: %PQUICC_ETHER-1-LOSTCARR_1: Unit 1, lost carrier. Transceiver problem?
Feb 24 10:55:53.272 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:56:03.316 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:56:13.356 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Feb 24 10:56:19.212 PST: ISAKMP (0:134217729): received packet from 63.1.1.1 dport 500 sport 500 Global (R) QM_IDLE     
Feb 24 10:56:19.212 PST: ISAKMP: set new node 1567785816 to QM_IDLE     
Feb 24 10:56:19.212 PST: CryptoEngine0: generate hmac context for conn id 1
Feb 24 10:56:19.216 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing HASH payload. message ID = 1567785816
Feb 24 10:56:19.216 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1): processing DELETE payload. message ID = 1567785816
Feb 24 10:56:19.216 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileytongue:eer does not do paranoid keepalives.

Feb 24 10:56:19.216 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):deleting node 1567785816 error FALSE reason "Informational (in) state 1"
Feb 24 10:56:19.220 PST: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 10:56:19.220 PST: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
-------------------------

 

 So at 11:10am, I log in and can not ping across the tunnel.  A 'clear crypto session' on the router, brings things back up:

 

From Firewall:

 

---------------------------

09-02-24 11:10:55     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.67.82.73 Phase 1: Completed Main mode negotiations with a 28800-second lifetime. (2009-02-24 11:10:54)<000>
2009-02-24 11:10:55     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1 Phase 2: Initiated negotiations. (2009-02-24 11:10:54)<000>
2009-02-24 11:10:56     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1: Received a notification message for DOI 1 24576 RESPONDER-LIFETIME. (2009-02-24 11:10:55)<000>
2009-02-24 11:10:56     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1: Phase 2 msg ID f06b6f28: Received responder lifetime notification. (0 sec/4608000 KB) (2009-02-24 11:10:55)<000>
2009-02-24 11:10:56     Local0.Info     192.168.0.253   san-fwl-253: NetScreen device_id=san-fwl-253  [Root]system-information-00536: IKE 72.1.1.1 Phase 2 msg ID f06b6f28: Completed negotiations with SPI fc1f8e7a, tunnel ID 24, and lifetime 3600 seconds/4194303 KB.
(2009-02-24 11:10:55)<000>
----------------------------

 

From router during the period of downtime:

 

----------------------------

.Feb 24 10:57:07.687 PST: ISAKMP:smileysad:0:1:smileyfrustrated:W:1):smileytongue:urging node 1567785816
Feb 24 11:07:44.033 PST: CRYPTO_ENGINE: key process suspended and continued
Feb 24 11:07:44.237 PST: CRYPTO_ENGINE: key process suspended and continued
Feb 24 11:07:44.441 PST: CRYPTO_ENGINE: key process suspended and continued
 ----------------------------

 

This particular tunnel actually has VPN monitoring disabled (I didnt this awhile back as part of troubleshooting, which made no difference).

 

Any ideas? 

Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???


I forgot to check the routing table on the firewall during this time.  Since I have a backup Internet connection and VPN connection for the remote sites, I have static routes pointing to the two tunnel interfaces for the remote subnet.  I wanted to make sure the route was still showing up as active and pointing to the correct tunnel.


With the VPN Monitor enabled, this allows me to have fully automated backup Internet connections and VPN tunnels for the remote sites.

 

 If I get a chance to troubleshoot this again while the connection is stalled, what information should I be pulling, or what things should I test?

Recognized Expert
PentinProcessor
Posts: 258
Registered: ‎11-06-2007
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

This message in the router debugs looks like a flag:

 

Feb 24 10:55:45.724 PST: %PQUICC_ETHER-1-LOSTCARR_1: Unit 1, lost carrier. Transceiver problem?

 

I would check the router's interface stats for any potential hardware issues.

 

 

If it happens again, I would capture the same router debugs that you captured above to confirm the behavior. 

 

You can also run 'debug ike detail' on the SSG-5

 

undebug all       (turn off any debugs)

set db size 4096   (increase debug buffer)

debug ike detail  

 

wait for problem to occur...and as soon as it does:

 

undebug all    (to turn off debugs and stop writing to circular debug buffer)

get db stream   (to view output in debug buffer)

unset db size   (to return debug buffer size to default)

 

get event 

 

What ScreenOS version are you running on the SSG-5? 

 

Let us know how it goes.

Josine

Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

[ Edited ]

The lost carrier errors from the Cisco router are from a non-related ethernet interface for the wireless backup. They can safely be ignored.

 

I will prepare with debugs on the SSG-5.


I just updated the firewalls to 6.1r4 last night, they were previously at r3.

 

Message Edited by ohhg on 02-25-2009 10:59 AM
Trusted Contributor
ric0
Posts: 65
Registered: ‎05-21-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

I recall the same problems when connecting to a PIX. Never figured that out; we replaced that with an SSG.

 

I think the main warning is this one:

Feb 24 10:55:03.064 PST: IPSEC(epa_des_crypt): decrypted packet failed SA identity check

 

Seems to me that the Phase2 renewal is started at the remote end but that is not noted.

JNCIA-FWV - JNCIA-IDP - Proud JNet Expert shirt owner :smileyhappy:
Contributor
ohhg
Posts: 14
Registered: ‎09-07-2008
0

Re: VPN tunnels drop for lengthy periods, causing outages... ???

I've been able to dedicate some more time to this issue.

 

In response to the "decrypted packet failed SA identity check" issue.  I fixed that by specifying a source interface, and destination IP for the VPN monitor.  I think the firewall was sourcing an external IP, or using the remote external IP as the destination, which wouldn't match Phase 2 which only includes the internal network at each location.  I changed it to use the internal interface as the source, and the IP address of the internal interface on the remote IOS router.

 

I have debug crypto session, isakmp, and ipsec enabled on all the remote routers with a large debug buffer to catch any logs on that end.


My question is on the Juniper side. 4096k is the size limitation for the dbuf, and it doesn't look like it's a circular buffer.  It fills up and stops logging.  This is a problem for me since I can't respond immediately when a tunnel goes down.

 

1) Is there a way to make this a circular buffer?

 

2) Even though the local buffer is filled, will the debug events still get sent to my syslog server if I have debug logs enabled to be sent to the syslog server?

 

Thanks!

 

-ohhg 

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.