Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 1867 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

Problem with Nortel Shasta: KeepAlive+Connection type

ChristoB
Situation:

Site-to-Site-VPN    Nortel shasta - Astaro ASG120
Tunnel with preshared key comes up and is always up from ASG.
Tunnel seems not to be usable in a stable way from Nortel shasta.

The idea for that VPN is:
Customer mobile user connect via wireless direct connection to provider.
Provider links that connection to the vpn tunnel.
On the other side of the tunnel there is the business-LAN of the customer.

What happens:
When we establish the tunnel manually from the ASG (turn the red light green...) the tunnel comes up. Some traffic through the tunnel works.
Then the tunnel is not anymore accessible from the providers side.

How it should be:
Tunnel should be activated from the provider (Nortel shasta).
Tunnel should be up and down automaticely.

The Configuration of Nortel shasta shows that this VPN connection work in mode "responder" whereas in other similar VPNs with different endpoints the Nortel shasta works as "initiator".

- Is there a possibility to configure the ASG so that the initiation of the tunnel comes only from providers side ?

- is there any possibility to send keep alive packets to keep the tunnel permanently open (as second best solution) ?

- Is there any knowhow with VPN between Nortel Shasta and ASG ?

Kind regards
Christo


This thread was automatically locked due to age.
Parents
  • 0
    Normaly the tunnels stays up, as long as there is a connection to the endpoint. 

    Roadwarrior configurations are the only ones, with more or less a "responder" mode, because the Astaro can't find the endpoint (dynamic).

    Did the Nortel logs offer any information why the traffic stops? Is there a second tunnel opened?
  • 0 in reply to NimmdirKeks
    After we did not succeed in testing with roadwarrior connections we continued with site-to-site tests.
     
    After some successful checks last evening (ping works, RDP works) I tried to reconnect from the client this morning.
     
    Unfortunately the ASG120 shows in VPN connections the lights yellow-green for both tunnels.
     
    The message shown (and copied from VPN Status) is
     
    STATE_QUICK_I1 (sent QI1, expecting QR1)
     
    What does that mean ?
    Could it mean that QI1 is "initiating" and QR1 is "response" so that the ASG120 tries to reestablish the tunnel, sends an initiating request and waits for an answer that doesn´t come ?
Reply
  • 0 in reply to NimmdirKeks
    After we did not succeed in testing with roadwarrior connections we continued with site-to-site tests.
     
    After some successful checks last evening (ping works, RDP works) I tried to reconnect from the client this morning.
     
    Unfortunately the ASG120 shows in VPN connections the lights yellow-green for both tunnels.
     
    The message shown (and copied from VPN Status) is
     
    STATE_QUICK_I1 (sent QI1, expecting QR1)
     
    What does that mean ?
    Could it mean that QI1 is "initiating" and QR1 is "response" so that the ASG120 tries to reestablish the tunnel, sends an initiating request and waits for an answer that doesn´t come ?
Children
  • 0 in reply to ChristoB
    Yes, the Astaro is trying to initiate State 1 and is waiting for an answer from the remote endpoint.
  • 0 in reply to NimmdirKeks
    Is there any possibility to prevent the Astaro from being initiator ?

    The provider which whom I try to work that out tells me that all 25 other tunnels he has with other customers have his Nortel Shasta as Initiator and not (as with Astaro) as responder.

    We even set down the SA Lifetime in Phase 1 and 2 down to 3000 seconds.
    Outcome: After about an hour the VPN-Routes show:
    0          10.10.aaa.0/16       ->  10.10.xxx.0/24     => %trap
    0          10.10.aaa.0/16       ->  10.10.xxy.0/24     => %hold

    Resetting the VPN-Connection (disable and enable in WebAdmin) brings the tunnel again up:

    0          10.10.aaa.0/16       -> 10.10.xxx.0/24     =>  tun0x1002@fff.ggg.hhh.iii 
    0          10.10.aaa.0/16       -> 10.10.xxy.0/24     =>  tun0x1004@fff.ggg.hhh.iik
  • 0 in reply to ChristoB
    Only if you switch the connection to a roadwarrior style. 

    May I guess, that you never got any traffic over the tunnel?
  • 0 in reply to NimmdirKeks
    Only if you switch the connection to a roadwarrior style. 


    Actually couldn't you just change the remote endpoint to ?  That causes ASL to wait for a connection instead of initiating.  Use a good authentication process so you can still be sure the other end is who you think it is.  I do this for endpoints that change IPs too often to rely on DDNS (ASL seems to take a while to notice the change).
  • 0 in reply to pablito
    to "NimmDirKeks": 
    I tried Road warrior but couldn´t get further than through the first phase. In phase 2 I get "no SA".
     
    Actually I can ping through the tunnel and establish a remote desktop session to a W2K server in the LAN when the tunnel is configured as site-to-site witth dedicated endpoints.
     
    To "pablito": The same with road warrior as with dynamic end point (that was what Astaro Support suggested).
     
    My colleague wonders whether the overlapping of the encryption domains could be the cause of the trouble: both remote networks are like 10.10.xxx.0/24 and 10.10.yyy.0/24 and the local network is 10.10.0.0./16.
     
    I doubt that this causes the problem, because the traffic runs correctly for more than an hour.
     
    Currently I have no idea what to do.
  • 0 in reply to ChristoB
    Hello again,
     
    Astaro Support helped us with two suggestions:


    • Try to work with equal PSKs for both tunnels for that may cause the problems.
    We tried that but that did not help (but could be an issue in other cases).
     


    • Check the definition of the remote subnet of the other VPN tunnel endpoint.
    That led us to the solution:
     
    The configuration for the local subnet on the Astaro was the range of the customers LAN.
    The configuration of the remote subnet on the Nortel Shasta was 0.0.0.0/0 (any).
    After I changed the local subnet to any on the astaro, the tunnel stayed up and running and was accessible even after more than 12 hours of "absence".
     
    I have not yet understood why it worked for a while.
    Otherwise I would have rechecked the configuration of the other side earlier.
    The other admin had the remote subnet definition as the customers LAN (as we agreed in the beginning) but then changed that and did not tell (or send a new config file...).
Cookie Information Banner