dynamic IPSEC: Holy grail sighted

From: Kent Hauser (kent.hauser_at_verizon.net)
Date: 08/16/03

  • Next message: The Anarcat: "Re: dynamic IPSEC: Holy grail sighted" 
    To: Christian Kratzer <ck@cksoft.de>
Date: Fri, 15 Aug 2003 23:29:17 -1000

    Hi,

    Thanks to some pointers from Christian Kratzer, I am now able to join the
    office VPN from a random WiFi hotspot. With the configuration files changes
    detailed below, from a public WiFi hotspot I can now use this 3 step
    procedure to login to the office VPN.

    1) While at hotspot, boot up my -STABLE laptop.
    2) Insert wireless card.
    3) "rsh server"

    This procedure works for a DHCP assigned private address translated by NAT at
    the hotspot to an unknown public address. The office VPN server is also
    behind a NAT firewall & uses private network addresses with a *dynamically*
    assigned public address. In other words, it's about as a complicated as you
    can get (I think).

    Three pieces of software must be configured for this to work. First "racoon"
    is used to exchange keys and security policies. Second, "DHCP" is configured
    to install security policies & alias the remote's interface with the remote's
    VPN address. Finally, the office router is setup to use DDNS (see dyndns.org)
    so that the office dynamic IP address can be found from a fixed DNS name.

    First racoon configuration. The office router must be programmed to pass port
    500 to the server for racoon negotiation. The office server is set to
    "listen" and "generate policy". This means that the policy proposed by the
    remote is inserted in the server's tables. There is a question of trust
    involved here I will not address. Also, my example uses "shared private
    keys", but there are plenty of examples of cert-based racoon, etc. The mods
    for my remote racoon conf are merely timers.

    Second, DHCP on the remote is configured using "/etc/dhcp-exit-hooks" and
    "/etc/dhcp.conf". The file "/etc/dhcp-exit-hooks" is executed by DHCP
    whenever an address is assigned. My "dhcp-exit-hooks" script (below) is a
    poorly written combination "perl" & "sh" script which translated DNS names to
    numbers & creates a security policy which is installed in the kernel by
    "setkey". I did the perl part in perl so that I could translate DNS names to
    numbers for setkey (see above: my server public address has static name but
    dynamic number). The "server" definitions at the head of the script should
    probably go in "/etc/rc.conf" in a production environment.

    Finally, DHCP is also configured to alias the private VPN address on the WiFi
    interface. This causes the kernel to use the correct source address on VPN
    packets. In a production environment, the "dhcp-exit-hooks" script should
    probably set up a GIF interface for this purpose to eliminate the need for
    the "dhcp.conf" file.

    After all this is done, "setkey -PD" on the remote shows packets from the
    remote's VPN address to the VPN network travelling thru a tunnel from the
    WiFi dynamic address to the office's public address. A "setkey -PD" on the
    server show packets from the VPN network to the remote passing thru a tunnel
    from the server's private address to the WiFi hotspot's public address
    (obviously racoon magic). AH & ESP are negotiated. I haven't checked if the
    server sets up a proxy arp for the remote -- but this is standard VPN fare.

    One final thing. Everything's screwed up if the WiFi hotspot chooses the same
    private network address as the office VPN. FWIW, I would recommend VPNs use
    the reserved class-B addresses (172.16->171.31) instead of the more common
    192.168 & 10 (both of which I've seen in hotspots & hotels). I've never seen
    an address in the Class-B range assigned by a public server.

    That's it. Comments appreciated. And if anyone knows perl & wants to clean up
    my mess, pls send me a copy.

    Cheers. Kent

    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

  • Next message: The Anarcat: "Re: dynamic IPSEC: Holy grail sighted"

    Relevant Pages

    • dynamic IPSEC: Holy grail sighted
      ... office VPN from a random WiFi hotspot. ... The office VPN server is also ... lifetime time 60 min; # sec,min,hour ...
      (freebsd-questions)
    • dynamic IPSEC: Holy grail sighted
      ... office VPN from a random WiFi hotspot. ... The office VPN server is also ...
      (freebsd-questions)
    • Re: VPN into ASA 5510 unable to access internet and other network
      ... up for the users connecting via office VPN to the hosting ips? ... the intermediate network devices have a route to get to the natted ... so I would think that they wouldn't need a special route. ...
      (comp.dcom.sys.cisco)
    • Re: VPN into ASA 5510 unable to access internet and other network
      ... up for the users connecting via office VPN to the hosting ips? ... the intermediate network devices have a route to get to the natted ... so I would think that they wouldn't need a special route. ...
      (comp.dcom.sys.cisco)
    • RE: VPN Connection Problems
      ... Note that we are able to successfully VPN into the office. ... to browse the network, RDP to the server or even ping the server. ... > This newsgroup only focuses on SBS technical issues. ...
      (microsoft.public.windows.server.sbs)