Guest User!

You are not Sophos Staff.

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

cannot create VPN with PGPNet

Ari Maniatis
I am trying to create a VPN with PGPNet 7.1 and ASL. I have followed the vpn_howto as closely as possible (substituting "VPN gateway" for "Secure gateway" as the connection type).

However I get no connection. The remote client is on a 192.168 network behind a router. Should that make a difference? Our private LAN here is 10.1.1.0/24.

I am not sure what packet filtering needs to be set up on the ASL to allow incoming connections. To the packet filter, do the incoming VPN packets appear to be coming from 192.168 on the WAN interface of the ASL? Or do they appear to be coming from the public IP address of the client's router?

Should I be able to establish a VPN even with the packet filtering wrong? Will the little indicator go green in PGP?

Given that the "LiveLog" window doesn't scroll, it is difficult to copy and paste the relevant section of the log with error messages before it is refreshed. Does this log exist somewhere on disk?

Thank you for any pointers to help make this work.

Ari Maniatis


This thread was automatically locked due to age.
Parents
  • 0
    yep same problem here.volwed the instructions on the vpn how to . there is also a typo in there because there is no pgpnet version 7.0.4 => the only version i can get was 7.0.3
    hope someone can help me out here .
    thanks

    I copyd and paste my livelog:
    VPN LiveLog

    Oct 31 16:14:41 astarobox Pluto[8653]:"Roadwarrior_1" #82: responding to Main Mode from unknown peer 192.168.100.22 
    Oct 31 16:14:41 astarobox Pluto[8653]:"Roadwarrior_1": deleting connection "Roadwarrior_1" instance with peer 192.168.100.22 
    Oct 31 16:14:41 astarobox Pluto[8653]   acket from 192.168.100.22:500: ignoring Vendor ID payload 
    Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1" #83: no acceptable Oakley Transform 
    Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1" #83: peer requested 86400 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION (variable length) 
    Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1" #83: responding to Main Mode from unknown peer 192.168.100.22 
    Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1": deleting connection "Roadwarrior_1" instance with peer 192.168.100.22 
    Oct 31 16:14:47 astarobox Pluto[8653]   acket from 192.168.100.22:500: ignoring Vendor ID payload 
    Oct 31 16:14:55 astarobox Pluto[8653]:"Roadwarrior_1" #84: no acceptable Oakley Transform 
    Oct 31 16:14:55 astarobox Pluto[8653]:"Roadwarrior_1" #84: peer requested 86400 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION (variable length) 
    Oct 31 16:14:55 astarobox Pluto[8653]:"Roadwarrior_1" #84: responding to Main Mode from unknown peer 192.168.100.22 
    Oct 31 16:14:55 astarobox Pluto[8653]:"Roadwarrior_1": deleting connection "Roadwarrior_1" instance with peer 192.168.100.22 
    Oct 31 16:14:55 astarobox Pluto[8653]   acket from 192.168.100.22:500: ignoring Vendor ID payload 


    stop LiveLog     [:S]
  • 0 in reply to coronmang
    quote:
      Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1" #83: peer requested 86400 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION (variable length) 


    OK. I got one step past where you are. You didn't change your PGPNet IKE retry times to 6 hours. If you do that, you'll get some different errors which is where I am stuck.

    Please post your success or otherwise.

    Ari Maniatis
Reply
  • 0 in reply to coronmang
    quote:
      Oct 31 16:14:47 astarobox Pluto[8653]:"Roadwarrior_1" #83: peer requested 86400 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION (variable length) 


    OK. I got one step past where you are. You didn't change your PGPNet IKE retry times to 6 hours. If you do that, you'll get some different errors which is where I am stuck.

    Please post your success or otherwise.

    Ari Maniatis
Children
  • 0 in reply to Ari Maniatis
    Hi all

     I have some experiance with other VPN gateways based on IPSec.

    In the way "some" vendors implement IPSec they don *not* support the client to be behind a NAT gateway (router/FW). This could be the issue in Ari Maniatis case   [:S]P to troubleshoot.

    Best of luck

    Regards Rickard
  • 0 in reply to Rickard Fernstrom
    quote:
     I have some experiance with other VPN gateways based on IPSec.

    In the way "some" vendors implement IPSec they don *not* support the client to be behind a NAT gateway (router/FW). This could be the issue in Ari Maniatis case  Try to use a public IP to troubleshoot. 


    Could someone at Astaro please confirm whether this will be a problem with the IPSec implementation in ASL. Right now I am unable to get ASL to work with a SonicWall VPN (with a public IP) or with PGPNet (with a private IP behind a NAT router).

    Should I be perservering? Has anyone made this actually work?
  • 0 in reply to Ari Maniatis
    I use SSH IPsec client behind a Linksys NAT box and it does NOT work, when I remove the NAT box and run the SSH IPsec client with a public IP address, then it works fine.

    I think ASL has problem connecting to IPsec client and the client is behind a NAT device.
  • 0 in reply to comeanddance
    I spent hours looking for a NAT server that supported IPSec, with no luck.
    Even one (Sygate) that claimed it could, failed every one of my attempts to get it working. Would work fine without but as soon as I put the proxy server in the VPN failed to connect.

    I gave up and I am now trying to get the PPTP VPN working instead.

    Recently I came across an article in the Sept 2001 issue of Information Security magazine.

    I quote 
    "IPSec allows systems to encrypt using Encapsulating Security Payload (ESP) protocol and authenticate IP packets using the Authentication Header (AH) protocol. IPSec works fine so long as the two endpoints are using public IP addresses. NAT throws a money wrench into the works because it munges (a technical term?       -sam) headers.  IPSec can't always differentiate between NAT header changes and maliciously broken packets, thus making it difficult (or impossible) for network applications to work."

    The whole article, NAT vs. IPSec: The Battle Continues, can be read about halfway down the page at this link...
    web page

    [ 07 November 2001: Message edited by: sdarcy ]

  • 0 in reply to nospamsam
    Apr 1 08:52:51 asl Pluto[16464]:"pgp_1" #103: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xa6f4dbc5 (perhaps this is a duplicated packet) 
    Apr 1 08:53:06 asl Pluto[16464]:"pgp_1" #103: ignoring Delete SA payload 
    Apr 1 08:53:06 asl Pluto[16464]:"pgp_1" #103: received and ignored informational message 
    Apr 1 08:53:30 asl Pluto[16464]:"pgp_1" #105: STATE_MAIN_R3: sent MR3, ISAKMP SA established 
    Apr 1 08:53:30 asl Pluto[16464]:"pgp_1" #105: ignoring informational payload, type IPSEC_INITIAL_CONTACT 
    Apr 1 08:53:30 asl Pluto[16464]:"pgp_1" #105: responding to Main Mode from unknown peer 61.165.223.200 
    Apr 1 08:53:30 asl Pluto[16464]:"pgp_1" #106: cannot respond to IPsec SA request because no connection is known for 61.152.125.82...61.165.223.200 
    Apr 1 08:53:30 asl Pluto[16464]   acket from 61.165.223.200:500: ignoring Vendor ID payload 
    Apr 1 08:53:32 asl Pluto[16464]:"pgp_1" #105: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xddabde7f (perhaps this is a duplicated packet) 
    Apr 1 08:53:43 asl Pluto[16464]:"pgp_1" #105: ignoring Delete SA payload 
    Apr 1 08:53:43 asl Pluto[16464]:"pgp_1" #105: received and ignored informational message 


    why??
  • 0 in reply to comon
    Hi all,

    I think I had the same, until GHansen (KOTL) informed me where my error was - he said that a road warrior configuration to a *subnet* (I think that is what you have here, with the 192.168.x.y-address) is not yet supported, but will be soon.

    Try the workaround for now (which worked fine for us):

    Append a config like the follwing to your /var/chroot-ipsec/etc/ipsec.conf-default:

    conn mytunnel2subnet
    type=tunnel
    keyexchange=ike
    auth=esp
    pfs=yes
    keylifetime=28800
    ikelifetime=3600
    compress=no
    left= [your ASL's external IP]
    right=0.0.0.0
    rightsubnet=192.168.x.y/255.255.255.0
    auto=add
    leftnexthop= [your router's external IP]
    leftid= [your ASL's external IP]
    rightid=0.0.0.0
    authby=secret

    Save the changes, and restart your IPSEC, then it should work fine.

    Thx to Gert again - your support is incredible ;-)

    Greetings from Bremen,
    wjl
Unfiltered HTML