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

IPSec Site 2 Site Not Functioning

dgriffin
I'm having a fairly odd issue. I have a site to site vpn between an ASG and a netgear firewall. It used to work fine until I updated to 8.0. The VPN connects and shows as up but it will not pass traffic. I have tried pinging from computers on both local and remote networks as well right from the ASG and it doesn't work. Both show routes have been added...

Thoughts?

THanks!

-Danny


This thread was automatically locked due to age.
  • 0
    Hi, can you post entries from the IPSEC log?

    Barry
  • 0
    Also, please show a pic of the 'Site-to-site VPN tunnel status', which is seen when you first select 'Site-to-Site VPN'.

    Cheers - Bob
  • 0 in reply to BAlfson
    Sure! That would probably help........


    these are the netgear side, if it helps:
    IKE:

    IPSEC:
    ipsec logs.zip
  • 0
    How about a log with debugging turned off...  I think that the problem will be easier to see. [;)]

    Cheers - Bob
    PS A couple things I've learned while participating here.  3DES is older, slower and less secure than AES.  RSA, though not as secure as certificates, is much more secure than a PSK.
  • 0 in reply to BAlfson
    Ok. Shut that off! Sorry about that...

    Now it's just logging this:
    2010:09:10-13:43:46 usnjvpnsec101 pluto[28639]: packet from 69.26.207.101:5: Quick Mode message is for a non-existent (expired?) ISAKMP SA
    2010:09:10-13:43:56 usnjvpnsec101 pluto[28639]: packet from 69.26.207.101:5: Quick Mode message is for a non-existent (expired?) ISAKMP SA 

    and I looked at the connection status this morning and it's showing this now (it's the connection UATVPN that's not working)


    Thanks.
    -Danny
  • 0
    The problem may be on the other side, and it's just a coincidence that this happened when it did.  In any case, how about disabling the 'IPsec Connection', then starting the IPsec live log and then re-enabling the connection?  That should tell us pretty quickly if anything's wrong in the Astaro.

    Cheers - Bob
  • 0 in reply to BAlfson
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: packet from 69.26.207.101:175: ignoring Vendor ID payload [810fa565f8ab14369105d706fbd57279]
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: packet from 69.26.207.101:175: ignoring Vendor ID payload [3b9031dce4fcf88b489a923963dd0c49]
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[1] 69.26.207.101:175 #9: responding to Main Mode from unknown peer 69.26.207.101:175
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[1] 69.26.207.101:175 #9: ignoring Vendor ID payload [KAME/racoon]
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[1] 69.26.207.101:175 #9: Peer ID is ID_FQDN: '69.26.207.101'
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[2] 69.26.207.101:175 #9: deleting connection "S_UATVPN" instance with peer 69.26.207.101 {isakmp=#0/ipsec=#0}
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[2] 69.26.207.101:175 #9: sent MR3, ISAKMP SA established
    2010:09:10-14:24:20 usnjvpnsec101 pluto[28639]: "S_UATVPN"[2] 69.26.207.101:175 #9: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    2010:09:10-14:24:22 usnjvpnsec101 pluto[28639]: "S_UATVPN"[2] 69.26.207.101:175 #10: responding to Quick Mode
    2010:09:10-14:24:22 usnjvpnsec101 pluto[28639]: "S_UATVPN"[2] 69.26.207.101:175 #10: IPsec SA established {ESP=>0x01c90f72 
  • 0
    That all looks perfect.  Either it's an error in the other side, or there's something else in the log that might point to a configuration error in the Astaro.

    Cheers - Bob
  • 0
    When you ping from a client on your local network you should see the incoming ICMP echo requests with `tcpdump -ni 10.0.1.1 icmp` started in a root shell. If you see those, make sure you also see ESP packets leaving the ASG on the external interface with `tcpdump -ni eth3 esp`. Please get back here with the results and we'll see how to proceed.
  • 0
    I ended up going out any buying $300 in parts and just building a server to run the ASG software. Works flawlessly. I would still like to get the other Netgear box working and I will check out the ICMP echo requests later today if I have time. 

    Thanks!

    -Danny