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

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.
Parents
  • 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
  • 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 
Reply
  • 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 
Children
No Data