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

Asg7 - fvg318

andersjj
Trying to get a site to site VPN working with ASG7 at the "home office" and FVG318 at the "branch office".

Using AES-128 PFS...tried to match up all the settings on the FVG318...keep getting the following log which ends in "No phase 2 handle"

here's the netgear log

2009-02-20 : INFO:  accept a request to establish IKE-SA: astaro.domain.com
2009-02-20 : INFO:  remote configuration for identifier "astaro.domain.com" found
2009-02-20 : INFO:  Initiating new phase 1 negotiation: branch_ip[500]homeoffice_ip[500]
2009-02-20 : INFO:  Beginning Identity Protection mode.
2009-02-20 : INFO:  Received unknown Vendor ID
2009-02-20 : INFO:  Received unknown Vendor ID
2009-02-20 : INFO:  Received unknown Vendor ID
2009-02-20 : INFO:  Received unknown Vendor ID
2009-02-20 : INFO:  ISAKMP-SA established for branch_ip[500]-homeoffice_ip[500] with spi:a775074169fe97d1:01b0e6014a326da2
2009-02-20 : INFO:  Sending Informational Exchange: notify payload[INITIAL-CONTACT]
2009-02-20 : INFO:  Initiating new phase 2 negotiation: branch_ip[500]homeoffice_ip[0]
2009-02-20 : ERROR:  Unknown notify message from homeoffice_ip[500].No phase2 handle found.


asg7 key line seems to be

pluto[14149]: "S_myfirst ipsec_0"[8] xx.xx.xx.xx #12: cannot respond to IPsec SA request because no connection is known for xx.xx.xx.0/24===xx.xx.xx.xx...xx.xx.xx.xx

Do I have the source and dest IP's reversed or something?  Any help would be great...thanks...hopefully it's something simple I didn't enter in ASG7 config...


This thread was automatically locked due to age.
  • 0 in reply to BAlfson
    OK, I see that you have defined the Remote Gateway as "Respond only" - I'm guessing because your Internet connection uses DHCP and you sometimes have a change of public IP.

    The trick with "Respond only" is that you can have only one pre-shared key defined in the Astaro.  If you have already defined a key in 'Remote Access' for 'IPSec' or 'L2TP over IPSec', you must use the same key here.  But, since the connection seems to make, I don't think that's a problem here.  In any case, "they" recommend using Certificates for connections that are to stay up all the time.  You can use a service like DynDNS.org and that will allow you to set the 'Gateway type' to "Initiate connection."

    Try selecting 'Strict Routing' and 'Auto Packet Filter'.  I still don't understand what that second, incomplete SA is doing there.  If that doesn't go away, check that your Policy definitions are consistent in both devices.  If that doesn't do it, it's time to look at the log.

    Let us know!
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    I do have remote access enabled, but the shared key is the same.

    I am using dyndns now just so I don't have to keep track of the ip address, so I'll try changing the remote gateway to initiate and see if that helps any...
  • 0 in reply to andersjj
    Strict routing didn't help any....ugh....

    I'm sure it's somthing stupid I'm not doing right...

    Let me know if you want to see any logs...
  • 0 in reply to andersjj
    Live logs from Packet Filter and IPSec VPN when you try to connect.

    Cheers - Bob
    PS Via email, John told me that the phantom SA was because he had added 'Any' as a second network in 'Local Networks' in the 'IPSec connection' definition and in 'Remote Networks' in the 'Remote Gateway' definition.  Removing those resolved that problem.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    per your mail, I DO have NAT Traversal turned on, keepalive set at 60 secs..
  • 0 in reply to andersjj
    Just for the heck of it, turned off NAT traversal...now the TOP MOST light on the Site To Site vpn monitor is green, but the light under that with the SA information is now yellow...
  • 0 in reply to andersjj
    rebooted "branch" vpn device and both IPSEC lights are now green on ASG7
  • 0 in reply to andersjj
    Sooo, does that mean it's working?

    I didn't see any NAT-T messages in the log, so I guessed that it was off.

    Cheers - Bob
    PS I think both ends must have NAT-T enabled for it to work.  Here's what the Wikipedia article on NAT-T says about NAT traversal and IPsec:
    In order for IPsec to work through a NAT, the following protocols need to be allowed on the firewall:
    • Internet Key Exchange (IKE) - User Datagram Protocol (UDP) port 500 
    • Encapsulating Security Payload (ESP) - Internet Protocol (IP) 50

    or, in case of NAT-T:
    • IPsec NAT-T - UDP port 4500

    Often this is accomplished on home routers by enabling "IPsec Passthrough".

    The default behavior of Windows XP SP2 was changed to no longer have NAT-T enabled by default, because of a rare and controversial security issue. This prevents most home users from using IPsec without making adjustments to their computer configuration. To enable NAT-T for systems behind NATs to communicate with other systems behind NATs, the following registry key needs to be added and set to a value of 2: 

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule


    IPsec NAT-T patches are also available for Windows 2000, Windows NT and Windows 98.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    No, still not working.  I'm wondering if my ISP might be blocking something that would allow the inital connection, but perhaps would not be allowing any communication after the connection is made?

    is that even possible a possible scenario?  Perhaps I should look for a more "wide open" connection somewhere to try to the "branch office" router with?
  • 0 in reply to andersjj
    For some reason, when I looked at them on my office PC, I didn't get the entire files.  I just opened them up on my laptop and I'm seeing some interesting things with the packet filter log.

    I saw one place where a port 25 packet from your branch office IP was blocked.  No problem, just curious.

    DNS requests from 192.168.x.99 to 192.168.x.102 are blocked.  If .102 is your internal DNS server, you need a PF rule allowing that traffic.  Same for port 137 (NETBIOS NS).

    63.*.*.102 appears to be the public IP of your main office.  The Astaro is dropping DNS requests from it to root name servers; you definitely need to allow that traffic, but I don't think that's done with a PF rule.  Do you have 'Network >> DNS' set with 'Internal (Network)' and your ISP's name servers listed on the 'Forwarders' tab?  I think the usual approach is to let them query the root name servers if necessary.

    Let me look more closely at the IPSec log, and I'll write again later.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Cookie Information Banner