# Help connecting to a work VPN

## mark_lagace

Hello all,

I'm afraid I'm a complete VPN newbie and I would appreciate some assistance setting up my gentoo box to connect to my work VPN connection.  In particular, any pointers to current IPSEC/IKE/radius configuration guides/howtos would be most appreciated.

Naturally, 'work' provides a windows client and setup script that makes everything work automagically (assuming you run windows 2k/xp of course) and beyond that the IT folks are only marginally knowledgeable about the actual underpinnings of the software.  The client they provide is Watchguard MUVPN, which appears to be a repackaged Safenet Softremote 10.x client.  I've taking screenshots of the policy editor screens (blacking out the IP address I'm connecting to) and I've saved a log of a successful connection.  You can see both  here.

Any advice would be greatly appreciated - particularly with respect to where I can find appropriate documentation for setting this up under Gentoo.Last edited by mark_lagace on Fri Nov 17, 2006 1:13 pm; edited 2 times in total

----------

## hanj

You might want to give kvpnc a try..

```

* net-misc/kvpnc

     Available versions:  0.7.2 ~0.8.6.1

     Installed:           none

     Homepage:            http://home.gna.org/kvpnc/

     Description:         kvpnc - a KDE-VPN connection utility.
```

http://home.gna.org/kvpnc/en/features.html

HTH

hanji

----------

## mark_lagace

I gave kvpnc a shot, but didn't have much success (although I appreciate the suggestion).

My problem is that I have read the IPsec HOWTO from http://www.ipsec-howto.org but I think I'm missing a few steps in the process and I'm not sure where to look for further information.

From observing what happens with the windows client, I've been able to break it down into the following steps:

1. Security policies are loaded

2. The software creates a new "interface" for my network card

3. IKE Phase I occurs using aggressive mode, pre-shared key, DES and SHA-1 and DH group 1 (768bit?)

4. At this point, a pop up requester for my work login and password occurs <-- What causes this??? There doesn't appear to be any form of user authentication that is part of IPsec as far as I have read...

5. If it gets the right username and password, it carries on with IKE Phase 2 using triple-DES and MD5.

6. It gives me a private IP address on the work subnet (10.1.1.X) and sets up my routes properly so that traffic directed to 10.1.1.X goes through the virtual interface it set up.<-- I presume once I get to this point in linux, it's simply a matter of setting up a tunnel.

So for the first stage (phase 1) I have the following in my raccoon.conf file (where aaa.bbb.ccc.ddd is my work servers external IP address).

```

path pre_shared_key "/etc/psk.txt";

timer   { natt_keepalive 10sec; }

listen  {

        isakmp 192.168.0.1 [500];

        isakmp_natt 192.168.0.1 [4500];

        }

remote aaa.bbb.ccc.ddd {

        exchange_mode aggressive;

        nat_traversal on;

        proposal {

                encryption_algorithm des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group 1;

        }

}

```

Where I am stuck right now is how to set up the security associations (in the raccoon.conf file) and the security policy.

I presume for my security associations I would use something like:

```

sainfo address 192.168.0.0/24 any address 10.1.1.0/24 any {

    pfs_group modp768;

    encryption_algorithm 3des;

    authentication_algorithm md5;

}

```

Where 192.168.0.0/24 is my internal network and 10.1.1.0/24 is the work internal network.  But what policy would I set up - and where on earth would I configure my work username an password in all of this?

 :Sad: 

----------

## mark_lagace

OK, after some more reading I'm pretty sure that the answer to the question about user authentication is the XAUTH extension to IKE, but unfortunately I must be doing something seriously wrong with my racoon setup since I can't get phase I negotiations to work at all...

My logs show:

```
Nov 11 20:30:42 [racoon] INFO: initiate new phase 1 negotiation: 192.168.0.15[500]<=>aaa.bbb.ccc.ddd[500]_

Nov 11 20:30:42 [racoon] INFO: begin Aggressive mode._

Nov 11 20:31:42 [racoon] ERROR: phase1 negotiation failed due to time up. 76e6cc95350bb3d9:0000000000000000_

```

Back to the drawing board...  I still welcome any advice

----------

## mark_lagace

Update:  I still haven't been able to connect up to work, so I decided to try and troubleshoot a bit more by setting up a VPN connection between my home computers.

I've just set up a very basic tunnel between my system: 192.168.0.15 (vladimir) and my wife's system: 192.168.0.10 (kerinsky) using a pre-shared key.

It appears to start up fine, but when I ping between the two computers, I see both encrypted and unencrypted packets going through.  Here's a sample from tcpdump from my computer pinging my wife's:

```

14:20:04.155772 IP vladimir > 192.168.0.10: ESP(spi=0x065244b6,seq=0xf), length 116

14:20:04.155930 IP 192.168.0.10 > vladimir: ESP(spi=0x0adb6f83,seq=0xf), length 116

14:20:04.155930 IP 192.168.0.10 > vladimir: ICMP echo reply, id 65304, seq 4, length 64

```

As you can see, the last entry appears to be the ICMP echo reply that is unencrypted.  Is this normal? (Logically I would need to see the unencrypted packet eventually to realize that I've had a reply to my ICMP echo request I suppose).

Assuming everything is working fine at this stage, I'll move on step by step to recreating the type of connection I need for work and seeing where it breaks...

----------

## col

you should have the 2 pc's on different subnets....like 192.168.x.x & 10.x.x.x

----------

## mark_lagace

I finally solved my problem by getting the latest CVS sources and compiling the ipsec-tools with --hybrid-auth.  This gave me the option of using authentication_method xauth_psk_client which is what I needed to connect to work.  It also provided me much more complete debugging messages than the default x86 or even ~86 emerged versions.

Time permitting, I will write up a howto for others, but for the moment I'm burned out on IPSEC...

M.

----------

## mark_lagace

Bah!  I thought I had everything working, and I actually did for one night, but now I can't figure out what's wrong since rebooting my system.

The VPN appears to connect fine, but after that I can't connect to any computers on my work subnet.

Here's the log of racoon connecting:

```

Nov 17 08:30:29 [racoon] INFO: @(#)ipsec-tools CVS (http://ipsec-tools.sourceforge.net)_

Nov 17 08:30:29 [racoon] INFO: @(#)This product linked OpenSSL 0.9.8d 28 Sep 2006 (http://www.openssl.org/)_

Nov 17 08:30:29 [racoon] INFO: Reading configuration from "/etc/racoon/racoon.conf"_

Nov 17 08:30:29 [racoon] INFO: Resize address pool from 0 to 255_

Nov 17 08:30:29 [racoon] INFO: 192.168.0.15[4500] used as isakmp port (fd=7)_

Nov 17 08:30:29 [racoon] INFO: 192.168.0.15[4500] used for NAT-T_

Nov 17 08:30:29 [racoon] INFO: 192.168.0.15[500] used as isakmp port (fd=8)_

Nov 17 08:30:29 [racoon] INFO: 192.168.0.15[500] used for NAT-T_

Nov 17 08:35:40 [racoon] INFO: IPsec-SA request for 207.61.88.250 queued due to no phase1 found._

Nov 17 08:35:40 [racoon] INFO: initiate new phase 1 negotiation: 192.168.0.15[500]<=>aaa.bbb.ccc.ddd[500]_

Nov 17 08:35:40 [racoon] INFO: begin Aggressive mode._

Nov 17 08:35:40 [racoon] INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02__

Nov 17 08:35:40 [racoon] INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt_

Nov 17 08:35:40 [racoon] INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02__

Nov 17 08:35:40 [racoon] INFO: NAT-D payload #-1 doesn't match_

Nov 17 08:35:40 [racoon] INFO: NAT-D payload #0 doesn't match_

Nov 17 08:35:40 [racoon] INFO: NAT detected: ME PEER_

Nov 17 08:35:40 [racoon] INFO: KA list add: 192.168.0.15[4500]->aaa.bbb.ccc.dddd[4500]_

Nov 17 08:35:40 [racoon] NOTIFY: couldn't find the proper pskey, try to get one by the peer's address._

Nov 17 08:35:40 [racoon] INFO: Adding remote and local NAT-D payloads._

Nov 17 08:35:40 [racoon] INFO: Hashing aaa.bbb.ccc.ddd[4500] with algo #2 (NAT-T forced)_

Nov 17 08:35:40 [racoon] INFO: Hashing 192.168.0.15[4500] with algo #2 (NAT-T forced)_

Nov 17 08:35:40 [racoon] INFO: ISAKMP-SA established 192.168.0.15[4500]-aaa.bbb.ccc.ddd[4500] spi:213e642c279635c7:0eebba337cc38456_

Nov 17 08:35:41 [racoon] INFO: initiate new phase 2 negotiation: 192.168.0.15[4500]<=>aaa.bbb.ccc.ddd[4500]_

Nov 17 08:35:41 [racoon] INFO: NAT detected -> UDP encapsulation (ENC_MODE 1->61443)._

Nov 17 08:35:42 [racoon] WARNING: attribute has been modified._

Nov 17 08:35:42 [racoon] INFO: Adjusting my encmode UDP-Tunnel->Tunnel_

Nov 17 08:35:42 [racoon] INFO: Adjusting peer's encmode UDP-Tunnel(61443)->Tunnel(1)_

Nov 17 08:35:42 [racoon] INFO: IPsec-SA established: ESP/Tunnel aaa.bbb.ccc.ddd[0]->192.168.0.15[0] spi=42252260(0x284b7e4)_

Nov 17 08:35:42 [racoon] INFO: IPsec-SA established: ESP/Tunnel 192.168.0.15[0]->aaa.bbb.ccc.ddd[0] spi=1108157702(0x420d2506)_

```

Output from ifconfig:

```

eth0      Link encap:Ethernet  HWaddr 

          inet addr:192.168.0.15  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:75633 errors:0 dropped:0 overruns:0 frame:0

          TX packets:62588 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:60830568 (58.0 Mb)  TX bytes:5403734 (5.1 Mb)

          Interrupt:16 Base address:0xd800

eth0:1    Link encap:Ethernet  HWaddr 

          inet addr:10.1.1.199  Bcast:10.255.255.255  Mask:255.0.0.0

          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:60 errors:0 dropped:0 overruns:0 frame:0

          TX packets:60 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:3000 (2.9 Kb)  TX bytes:3000 (2.9 Kb)

          Interrupt:16 Base address:0xd800

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:60 errors:0 dropped:0 overruns:0 frame:0

          TX packets:60 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3000 (2.9 Kb)  TX bytes:3000 (2.9 Kb)

```

route:

```

192.168.0.0/24 dev eth0  scope link

10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.1.1.199

127.0.0.0/8 dev lo  scope link

default via 192.168.0.1 dev eth0

```

My security associations:

```

10.1.1.0/24[any] 10.1.1.199[any] any

        in prio def ipsec

        esp/tunnel/aaa.bbb.ccc.ddd-192.168.0.15/require

        created: Nov 17 08:30:29 2006  lastused:

        lifetime: 0(s) validtime: 0(s)

        spid=8 seq=6 pid=7537

        refcnt=1

10.1.1.199[any] 10.1.1.0/24[any] any

        out prio def ipsec

        esp/tunnel/192.168.0.15-aaa.bbb.ccc.ddd/require

        created: Nov 17 08:30:29 2006  lastused: Nov 17 08:38:52 2006

        lifetime: 0(s) validtime: 0(s)

        spid=1 seq=5 pid=7537

        refcnt=3

10.1.1.0/24[any] 10.1.1.199[any] any

        fwd prio def ipsec

        esp/tunnel/aaa.bbb.ccc.ddd-192.168.0.15/require

        created: Nov 17 08:30:29 2006  lastused:

        lifetime: 0(s) validtime: 0(s)

        spid=18 seq=4 pid=7537

        refcnt=1

```

Forwarding is enabled (echo "1" > /proc/sys/net/ipv4/ip_forward).

The kernel hasn't changed since this worked that once.

If I configure my wife's computer on the 10.1.1.X subnet and disable my security policies so it doesn't attempt to start up a VPN connection, I can ping her computer without any problems using the above networking config.

Help!  I have no idea where to even begin to troubleshoot this!

P.S. My internet connection is connected to 192.168.0.1, which shares the connection (nat) with my desktop and my wife's.  My desktop computer is 192.168.0.15.  Work's VPN gateway is aaa.bbb.ccc.ddd.  The IP address range used internally at work is 10.1.1.0/24.

----------

## mark_lagace

Quick update - I can ping my home computer from work, but not the other way around (and no, my work computer does not block ICMP).

----------

