Home Forums Archive VaporSec VaporSec on Panther talks to OpenBSD 3.4!

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #357104
    pat
    Participant

    Now this was a headache! My setup:
    LAN at office (192.168.1.0/24) behind openbsd 3.4, connected to internet via cablemodem, receiving official IP via DHCP (dyndns helps out)
    At home: os x 10.3.2 on 17″ powerbook, DHCP from cablemodem as well
    aim: be a part of the office-LAN while at home…

    i do get applescript error 2706 when starting vaporsec up, but i can click it away and don’t bother.

    after a lot of trying, i got this far, that i could narrow my problems down to the “setkey”-part of the whole process. i could even narrow it more down to the part in the script ipsec.sh, where it tries to find out the IP of the machine it is running on in this part:

    ################################################################################
    #
    # setup tunnels
    # this will iterate through all the interfaces and make tunnels with that IP
    #
    ################################################################################

    setup_tunnels () {
    awk ‘BEGIN {while (“ifconfig -a” | getline) {
    if ( /^en/ ) {
    sub( /:/, “”)
    interface = $1
    }
    if ($1 == “inet” && $2 != “127.0.0.1”) {
    print $2
    }
    }
    }
    ‘ | while read IP
    do
    make_tunnel
    done
    }

    the “setkey -DP” result just didn’t make sense. BUT everything went fine, when i changed

    ifconfig -a

    to

    ifconfig -L en1

    en1 being my wirelesslan-if, in use now

    of course the script isn’t as flexible this way, but at least i got my ipsec tunnel running…

    it looks to me, as if there is a bug somewhere in the way the script searches and uses the IPs it finds. with the -a it did “make_tunnel” 2 times, with the “-L en1” the subroutine “make_tunnel” ran only once and did the setup correctly.

    maybe of interest: my openbsd configs. i did a lot of trying, until i found a working example, that played along with VaporSec. As i am no expert, theses settings might not be optimal, but for the moment they work for me. the VaporSec Settings i describe further down.

    OpenBSD:
    /etc/isakmpd/isakmpd.policy
    Keynote-Version: 2
    Authorizer: “POLICY”
    Conditions: app_domain == “IPsec policy” &&
    esp_present == “yes” &&
    esp_enc_alg != “null” -> “true”;

    OpenBSD:
    /etc/isakmpd/isakmpd.conf

    [General]
    Default-phase-1-lifetime= 120,60:3600
    Default-phase-2-lifetime= 120,60:3600
    Retransmits= 5
    Check-interval= 5
    Exchange-max-time= 120
    Policy-File= /etc/isakmpd/isakmpd.policy

    [Phase 1]
    Default= ISAKMP-clients

    [Phase 2]
    Passive-Connections= IPsec-clients

    [Default-main-mode]
    DOI= IPSEC
    EXCHANGE_TYPE= ID_PROT
    Transforms= 3DES-SHA

    [Default-quick-mode]
    DOI= IPSEC
    EXCHANGE_TYPE= QUICK_MODE
    Suites= QM-ESP-BLF-SHA-SUITE

    # Phase 1 peer sections
    #######################

    [ISAKMP-clients]
    Phase= 1
    Transport= udp
    Configuration= PGP-main-mode
    Authentication= thisisthesharedsecret

    # Phase 2 sections
    ##################

    [IPsec-clients]
    Phase= 2
    Configuration= PGP-quick-mode
    Local-ID= default-route
    Remote-ID= dummy-remote

    # Client ID sections
    ####################
    [default-route]
    ID-type= IPV4_ADDR_SUBNET
    Network= 0.0.0.0
    Netmask= 0.0.0.0

    [dummy-remote]
    ID-type= IPV4_ADDR
    Address= 0.0.0.0

    # Transform descriptions
    ########################
    # Some predefined section names are recognized by the daemon, voiding the
    # need to fully specify the Main Mode transforms and Quick Mode suites,
    # protocols and transforms.
    #
    # For Main Mode:
    # {DES,BLF,3DES,CAST}-{MD5,SHA}[-{DSS,RSA_SIG}]
    #
    # For Quick Mode:
    # QM-{ESP,AH}[-TRP]-{DES,3DES,CAST,BLF,AES}[-{MD5,SHA,RIPEMD}][-PFS]-SUITE

    [PGP-main-mode]
    DOI= IPSEC
    EXCHANGE_TYPE= ID_PROT
    Transforms= CAST-SHA,3DES-SHA

    [PGP-quick-mode]
    DOI= IPSEC
    EXCHANGE_TYPE= QUICK_MODE
    Suites= QM-ESP-3DES-MD5-SUITE,QM-ESP-BLF-SHA-SUITE

    [PGP-aggressive-mode]
    DOI= IPSEC
    EXCHANGE_TYPE= AGGRESSIVE
    Transforms= CAST-SHA,3DES-MD5

    # Main mode transforms
    ######################

    [3DES-MD5]
    ENCRYPTION_ALGORITHM= 3DES_CBC
    HASH_ALGORITHM= MD5
    AUTHENTICATION_METHOD= PRE_SHARED
    GROUP_DESCRIPTION= MODP_1024
    Life= LIFE_1_DAY

    [CAST-SHA]
    ENCRYPTION_ALGORITHM= CAST_CBC
    HASH_ALGORITHM= SHA
    AUTHENTICATION_METHOD= PRE_SHARED
    GROUP_DESCRIPTION= MODP_1536
    Life= LIFE_1_DAY

    # Lifetimes
    ###########

    [LIFE_1_DAY]
    LIFE_TYPE= SECONDS
    LIFE_DURATION= 86400,79200:93600

    ———VaporSec settings for this:
    MAIN:
    Mode: main
    Proposal Check: claim
    Nonce size: 16

    PHASE 1
    Lifetime 5 minutes
    DH Group 2
    Encryption 3des
    Authentication sha1

    PHASE 2
    Lifetime 8 hours
    PFS Group 2
    Encryption 3des
    Authentication hmac_sha1

    ID
    Local (no entry)
    Remote (no entry)

    #357113
    Anonymous
    Participant

    My configuration is virtually identical to yours (local wifi through router with DHCP to workplace LAN, not working with Vaporsec), but when I try your hack I get:

    Dec 29 20:55:50 localhost racoon: ERROR: sockmisc.c:731:str2saddr(): getaddrinfo(192.168.0,0): No address associated with nodename
    Dec 29 20:55:50 localhost racoon: ERROR: cfparse.y:1350:cfparse(): fatal parse failure.

    This is different in that before applying your hack the erro was due to a null value passed to sockmisc. Is this a DNS problem? Any clues?

    B

    #357116
    bryancn
    Participant

    Thanks Joel – a typo of course, allowing progress to the next problem (opportunity?).

    The issue is NAT Traversal, I think. I have a belkin 54g wireless router with udp port 500 open and get:

    Dec 30 19:16:05 localhost racoon: ERROR: isakmp.c:2033:isakmp_chkph1there(): phase2 negotiation failed due to time up waiting for phase1. ESP 210.54.170.19->192.168.2.2

    The server is trying to negotiate with my internal IP so I assume the router isn’t handling this. Did I read somewhere that Vaporsec handles NAT traversal or is it something that you set up at the server (in my case FreeS/WAN) end?

    You (Pat) say you configured your client inside the router. Did you have to cope with this?

    #357118
    pat
    Participant

    [quote:d55dd17b5e=”bryancn”]Thanks Joel – a typo of course, allowing progress to the next problem (opportunity?).

    (…)

    You (Pat) say you configured your client inside the router. Did you have to cope with this?[/quote:d55dd17b5e]

    Did I? Not excactly inside the router. I connect a Netgear MA 102 AP to my cablemodem. The AP is on a switch to which the cablemodem is connected. why? downstairs a friend uses the same cablemodem to get his IP from the same provider and he connects to the switch too. me upstairs, i connect wirelessly.
    Well, no, this way I didn’t have to cope with NAT traversal. I guess I can’t help you with that. As I connect my powerbook directly, (although via accesspoint) getting an official IP from my provider http://www.hispeed.ch and rely on the panthers firewall… By the way, I put a little more verbose record of what i did here: http://homepage.mac.com/tsup/vpn/

    #357133
    Anonymous
    Participant

    I have tried in the last two day to allow my Powerbook G4 with Airport card to access the Internet via a OpenBSD 3.3 box using VaporSec but without success.

    My OBSD box has three network cards :-
    fx0 connects to cable modem with an IP address of w.x.y.z (an routable IP address assigned by the ISP).
    fx1 connects to a hub which allows me to plug in computers and printer. fx1 has an IP address of 192.168.1.1/255.255.255.0.
    dc0 connects via a cross-over cable to an Intel PRO wireless access point and has an IP address of 192.168.2.1/255.255.255.0

    My laptop has an Intel wireless network card, running Windows XP Pro with an IP address of 192.168.2.14/255.255.255.0. I can use ‘Sentinel VPN Client’ to secure my WLAN with IPSec to surf the Internet via the OBSD firewall, as well as accessing printing device on the internal network (192.168.1.0/255.255.255.0). This shows that I have a functional IPSec setup on my OBSD box.

    My 12″ PowerBook running ‘Panther’ with an Airport card cannot do a thing. The ‘ifconfig -a’ command output shows that my airport card ‘en1’ is up and running, also showing the manually assigned IP address (192.168.2.2/255.255.255.0) correctly. The VaporSec ‘Show ’em’ output indicates there are IPSec tunnels between 192.168.2.1 and 192.168.2.2. But I cannot ‘ping’ the IP address of 192.168.2.1.

    I looked up some older comments from the bulletin board and found one comment saying that ‘racoon’ (which is what VaporSec based on) does not allow IPSec setup between two hosts on the same subnet (which is what I am trying to do). ‘Racoon’ only allows a computer to setup an IPSec connection with a remote IPSec gateway and communicates with hosts behind the IPSec gateway. Is this correct ?

    Would you be so kind to share your experience in using ‘VaporSec’ to secure wireless connection. Thanks.

    Alex Lee

    #357136
    pat
    Participant

    Actually I haven’t (completely) secured the wireless part of my Internetaccess. Whenever I do anything else than pinging the LAN “over there”, I do it insecurely. All I do have, is a secured tunnel from my official IP, “as private IP”, to the official IP of the “LAN over there” to the private IP of its internal interface and the private range network “over there”. But anyhow. I don’t have a foolproof concept. just an idea.
    (first: there may be many places, where something can go wrong / be set so that the Mac and the OpenBSDbox don’t understand each other, but the XPmachine does.. I just think of the settings of VaporSec on the Mac or /etc/isakmpd/isakmpd.conf and isakmpd.policy on the OpenBSDbox. to my experience, these are subtle things and almost everything matters 😉 As you can see here http://www.allard.nu/openbsd/openbsd/index.html ssh sentinel has a specific isakmpd.conf. If your isakmpd.conf works with the XPclient, I guess you would have to reproduce its settings excactly with VaporSec on the Mac, or you will fail for sure. But how you do this, I don’t know, as I don’t use ssh sentinel. and: do you have “pf” running and setup /etc/pf.conf accordingly? well, as you can surf with the XP, I guess you do.
    It helped me a lot to keep open several terminal windows on the Mac, showing, one for each output,:
    – terminalwindow1 on the Mac: tail -f /var/log/system.log (shows you every addition to this logfile as it happens)
    – terminalwindow2 ont the Mac, but logged in on the OpenBSDbox, running isakmpd in the NOT-daemon-mode with “isakmpd -d -DA=70” (shows you a lot of rather cryptic output. important in so far as you at least see if anything happens at all…)
    – terminalwindow3 on the Mac: ping the system I want to reach… (test for success)
    with this you can see what the macinternals do when you tell VaporSec to “Vaporize” and if and how the OpenBSDbox responds. So that’s a “first level control”
    But let’s assume, the problem is NOT there…).

    so basically you need a tunnel from the powerbook to the openbsdbox. If you know german, maybe this would be excactly what you need:
    http://www.openbsd.de/ipsec/html/index.html

    automatically translated here:

    http://babelfish.altavista.com/babelfish/urltrurl?url=http%3A%2F%2Fwww.openbsd.de%2Fipsec%2Fhtml%2Findex.html&lp=de_en&tt=url

    maybe this helps. a more speculative, untried, only guessed way might be this:
    Now you want to surf with the powerbook, having assigned it a private range IP. powerbook and OpenBSDbox being on the same private range subnet (192.168.1.0/24). this doesn’t work, you write. how about simulating “my” setup? meaning: separate the “real” IP of the powerbook from the “simulated one”. This way:
    a) in the Network Control Panel you assign to your powerbook the private IP 192.168.3.1 and you set the netmask to 255.255.0.0 and the gateway to 192.168.2.1 (i assume, that’s the gateway to the internet for all your machines on the local private range network, isn’t it?)
    b) In VaporSec in the “Main settings” you set “Local IP” to the IP 192.168.2.2, and in the same pane, a little further up, you set the “Remote Network” to 192.168.2.0/24 (or maybe 192.168.2.0/16 I’m not sure)
    c) set the netmask of interface dc0 to 255.255.0.0 (so the XP machine (192.168.2.14) and the powerbook (192.168.3.1) are reachable for it at all)
    c) assign interface fx1 the completely different private range IP 10.0.0.1 with the subnet 255.255.255.0. yes, this requires IPchanges with the printer and other computers as well and / or maybe even with the DHCP setup if you use OpenBSD as server on that interface
    d) check /etc/isakmpd/isakmpd.conf for any setting of a subnetwork, make sure it is something like 192.168.0.0 with netmask 255.255.0.0

    what this may may may bring:
    – “isolate” the powerbooks “main” IP 192.168.3.1
    – setup the tunnel between the powerbook “local IP” 192.168.2.2 and the OpenBSD interface at 192.168.2.1
    – make 3.1 still reachable for 2.1 and vice versa

    this is very speculative and rather likely to not work too… .:-) but maybe it does. i guess it would take about half an hour to try it. caution: if you mess around, first write down somehow the original settings, so you can easily reconstruct them… I wouldn’t like to take the blame for haveing sent you into blowing up your at least partially working setup…

    #357150
    Anonymous
    Participant

    Still ‘no go’ with VaporSec and OBSD box.
    I looked at the system.log and noticed that my PowerBook did contact the OBSD box but could not establish ‘phase 1’ Security Association. It always timed out. I was using similar IPSec configuration setting on VaporSec as in the Sentinel VPN client.

    I do not know if it is the VaporSec version 1.0 problem. I’ll try again when the VaporSec Panther version is available. Thanks for your reply.

    #357174
    Anonymous
    Participant

    Please let me have your e-mail address, I am most happy to send you my gateway’s IP address.

    My e-mail address is ” alexleeATcharterDOTnet “.

    #357182
    bryancn
    Participant

    Alex

    Following you time out ptoblem you say: “The VaporSec ‘Show ’em’ output indicates there are IPSec tunnels between 192.168.2.1 and 192.168.2.2. But I cannot ‘ping’ the IP address of 192.168.2.1”

    What does a tail of system.log produce? Mine always contains something like “phase2 negotiation failed due to time up waiting for phase1. ESP 210.54.170.19->192.168.2.2 ” which I think means the VaporSec/Router combination can’t handle NAT translation.

    B

    #357188
    Anonymous
    Participant

    This is the error message I got.
    192.168.2.1 is the IP address of network card ‘dc0’.
    192.168.2.2 is the manually configured IP address of Airport Extreme card.
    There isn’t any need for ‘NAT’. If phase 1 fails to establish security association then surely phase 2 will time out.

    ++++++++++++++++++++++++++++++
    Jan 12 21:01:09 localhost racoon: ERROR: isakmp.c:2033:isakmp_chkph1there(): phase2 negotiation failed due to time up waiting for phase1. ESP 192.168.2.1->192.168.2.2
    Jan 12 21:02:38 localhost racoon: ERROR: isakmp.c:1694:isakmp_ph1resend(): phase1 negotiation failed due to time up. 45da2f8ce3b8a2bf:0000000000000000
    ++++++++++++++++++++++++++++++

    #357302
    Anonymous
    Participant

    the issue here according to me is not one of NAT or not, since I have the same problem but both on the router which has a public IP and on the machines behind NAT which have private IPs….

    The issue is according to me with the providers blocking that specific UDP port.

    For me the issue comes up when I use a Panther Server on one side and a Panther client on the other, no VaporSec, just the regular clients. The tunnel is there and I can initiate connections from client to server, but not from server to client….

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.

Comments are closed