Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 5 subscribers
  • Views 990 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SG to SG VPN suddenly stops sending traffic

Steven Knights

I have a weird issue. I run an SG in our datacenter, with approx 9 tunnels to my clients (all SG or XG) and approx 30'ish ssl vpn remote access'

There is one client with an SG who's tunnel seems to stop send through traffic every couple of days/weeks. The tunnel shows online in the webinterface (on both ends), but RDP fails & pinging from the lan or the client's SG also fails (ping is allowed).

Issue occurs usually early in the morning. At a certain point I started rebooting the clients SG 30 minutes before their working day, which makes it so they can work 99% of the mornings, but every so often even that isn't a guarantee. I switched the tunnel from IPSEC to SSLVPN, but the problem still occurs.

I'm a bit at a loss as to what could be causing this. Restarting the tunnel immediatly fixes the issue; it's a quick fix, but seeing as none of the 8 other SSL/IPSEC tunnels have this issue I would really like to get to the bottom of this.

Any and all hints/pointers would be greatly appreciated!



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Could you please double-check the IPsec policy? Is the configured authentication algorithm identical in phase 2 on both firewalls? Or did you select a strict policy?

    Thanks,

Reply
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Could you please double-check the IPsec policy? Is the configured authentication algorithm identical in phase 2 on both firewalls? Or did you select a strict policy?

    Thanks,

Children
  • 0 in reply to FormerMember

    Both ends (SG210 and SG115 both on the latest 9.7 firmware) are configured with the following policy:
    IKE encryption AES256
    IKE auth SHA2 256
    IKE SA lifetime 86400
    IKE DH group2

    IPSEC encryption AES256
    IPSEC auth SHA2 256
    IPSEC SA lifetime 86400
    IPSEC DH group2


    strict policy turned off
    compression turned on

  • FormerMember
    0 FormerMember in reply to Steven Knights

    Hi ,

    If the configured policy is identical, then it might not be an issue with the traffic decryption. Would it be possible for you to provide IPsec logs in debugging? You could turn on debugging from the GUI, go to Site-to-Site VPN > IPsec > Debug.

    Thanks,

  • 0 in reply to FormerMember

    Hi Harsh,

    the tunnel is currently running in SSLVPN and I can't easily switch back without disturbing the customer.

    Would it help if I provide the regular (non-debug) ipsec logs of the day it last happened  (26/3)?
    And if so, how do I provide those logs ? Don't really want to throw a log full of public ip's and such in the forum Slight smile

    Perhaps related to this issue; I have noticed that one of the SSL tunnels has a remote subnet that overlaps with the remote subnet of another client's offce LAN; would that cause routing table issues that could be the root cause of this issue ?!

    thanks for your help!!

    gr

    Steven

  • FormerMember
    0 FormerMember in reply to Steven Knights

    Hi ,

    Thanks for the update. 

    In that case, you would have to schedule a maintenance window to collect the logs in debugging. 

    You could send me the old logs via private message.

    Yes, if the overlapping network is part of the site-to-site tunnel, then yes, it would create the routing issue. 

    Thanks,

  • 0 in reply to FormerMember

    no, the overlapping networks are not part of the affected clients tunnel.
    The issue we have is with rremote range 192.168.172.0/24
    and the overlap is between a client with 192.168.2.0/24 and 192.168.0.0/22

    So I guess that is unrelated (but something we will try to fix soon.)

    I will send you a PM with the logfile in a minute.. seeing as it's the complete IPsec log for that day, you will see unrelated tunnels in there. 
    Most important events related to the issue at hand in that logfile:

    7:30 daily reboot the client's firewall, so tunnel REF_IpsSitAfcsipsec goes down
    7:35 REF_IpsSitAfcsipsec is up again
    8:34 Client called; no traffic across the tunnel, we stop and start the ipsec tunnel; issue solved.

Unfiltered HTML