iOS/Mac-Compatible IPSec VPN Server on Ubuntu

Question

I pay for a VPS from a Xen VPS host and the load on it is fairly light, so I'd like to run a VPN off of it. The configuration I'm shooting for is "roadwarrior"-style, as I'd like to use it to secure connections from my iPhone and Mac when I'm not at home. Keep in mind that I'm a programmer, not a sysadmin, so this is all fairly foreign to me.

After failing to get a StrongSWAN/PPP/xL2TP setup working, I came across racoon which seems to be a very simple option. I'm trying to avoid the use of certificates because the process of getting certs onto an iOS device is probably annoying (just a guess). Thus, I've configured racoon on the VPS so that I can connect to it successfully and authenticate via XAUTH backed by the system user database. That all seems to be working, it's the NAT/networking stuff that isn't working, and I'm completely out of my element with it.

My VPS is running Ubuntu 10.10. I get the following output from ifconfig (I'm guessing it might be relevant):

eth0      Link encap:Ethernet  HWaddr 00:16:3e:4a:7f:29  
          inet addr:69.172.231.11  Bcast:69.172.231.63  Mask:255.255.255.192
          inet6 addr: fe80::216:3eff:fe4a:7f29/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5234214 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2417090 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:553246281 (553.2 MB)  TX bytes:5237753987 (5.2 GB)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1577698 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1577698 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

Here is my racoon configuration file:

path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

timer {
        natt_keepalive 10sec;
}

remote anonymous {
        exchange_mode main, aggressive, base;
        doi ipsec_doi;
        situation identity_only;
        nat_traversal on;
        script "/etc/racoon/phase1-up.sh" phase1_up;
        script "/etc/racoon/phase1-down.sh" phase1_down;
        generate_policy on;
        ike_frag on;
        passive on;
        my_identifier address 69.172.231.11;
        peers_identifier fqdn "zcr.me";
        proposal {
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method xauth_psk_server;
                dh_group 2;
        }
        proposal_check claim;
}


sainfo anonymous {
        encryption_algorithm aes;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

mode_cfg {
        auth_source system;
        save_passwd on;
        network4 10.1.0.0;
        pool_size 100;
}

That configuration has been pieced together from various tutorials around the 'net, so it may be...strange. When I connect to the VPN, the following output is received on the client side:

4/12/11 2:21:43 PM  racoon[191] Connecting.
4/12/11 2:21:43 PM  racoon[191] IKE Packet: transmit success. (Initiator, Aggressive-Mode message 1).
4/12/11 2:21:43 PM  racoon[191] IKEv1 Phase1 AUTH: success. (Initiator, Aggressive-Mode Message 2).
4/12/11 2:21:43 PM  racoon[191] IKE Packet: receive success. (Initiator, Aggressive-Mode message 2).
4/12/11 2:21:43 PM  racoon[191] IKEv1 Phase1 Initiator: success. (Initiator, Aggressive-Mode).
4/12/11 2:21:43 PM  racoon[191] IKE Packet: transmit success. (Initiator, Aggressive-Mode message 3).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: transmit success. (Mode-Config message).
4/12/11 2:21:46 PM  racoon[191] IKEv1 XAUTH: success. (XAUTH Status is OK).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: transmit success. (Mode-Config message).
4/12/11 2:21:46 PM  racoon[191] IKEv1 Config: retransmited. (Mode-Config retransmit).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: receive success. (MODE-Config).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: transmit success. (Initiator, Quick-Mode message 1).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: receive success. (Initiator, Quick-Mode message 2).
4/12/11 2:21:46 PM  racoon[191] IKE Packet: transmit success. (Initiator, Quick-Mode message 3).
4/12/11 2:21:46 PM  racoon[191] IKEv1 Phase2 Initiator: success. (Initiator, Quick-Mode).
4/12/11 2:22:03 PM  racoon[191] IKE Packet: transmit success. (Information message).
4/12/11 2:22:03 PM  racoon[191] IKEv1 Information-Notice: transmit success. (R-U-THERE?).
4/12/11 2:22:03 PM  racoon[191] IKEv1 Dead-Peer-Detection: request transmitted. (Initiator DPD Request).
4/12/11 2:22:04 PM  racoon[191] IKEv1 Dead-Peer-Detection: response received. (Initiator DPD Response).
4/12/11 2:22:04 PM  racoon[191] IKE Packet: receive success. (Information message).
4/12/11 2:22:04 PM  racoon[191] IKE Packet: transmit success. (Information message).
4/12/11 2:22:04 PM  racoon[191] IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA).
4/12/11 2:22:04 PM  racoon[191] IKE Packet: transmit success. (Information message).
4/12/11 2:22:04 PM  racoon[191] IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA).

The same connection generates the following output on the server side:

Apr 12 13:20:20 Zaccaro racoon: INFO: respond new phase 1 negotiation: SERVER.IP.ADDRESS[500]<=>CLIENT.IP.ADDRESS[500]
Apr 12 13:20:20 Zaccaro racoon: INFO: begin Aggressive mode.
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: RFC 3947
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02#012
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: CISCO-UNITY
Apr 12 13:20:20 Zaccaro racoon: INFO: received Vendor ID: DPD
Apr 12 13:20:20 Zaccaro racoon: WARNING: No ID match.
Apr 12 13:20:20 Zaccaro racoon: INFO: Selected NAT-T version: RFC 3947
Apr 12 13:20:20 Zaccaro racoon: INFO: Adding remote and local NAT-D payloads.
Apr 12 13:20:20 Zaccaro racoon: INFO: Hashing CLIENT.IP.ADDRESS[500] with algo #2 
Apr 12 13:20:20 Zaccaro racoon: INFO: Hashing SERVER.IP.ADDRESS[500] with algo #2 
Apr 12 13:20:20 Zaccaro racoon: INFO: Adding xauth VID payload.
Apr 12 13:20:20 Zaccaro racoon: INFO: NAT-T: ports changed to: SERVER.IP.ADDRESS[32768]<->CLIENT.IP.ADDRESS[4500]
Apr 12 13:20:20 Zaccaro racoon: INFO: Hashing SERVER.IP.ADDRESS[4500] with algo #2 
Apr 12 13:20:20 Zaccaro racoon: INFO: NAT-D payload #0 verified
Apr 12 13:20:20 Zaccaro racoon: INFO: Hashing CLIENT.IP.ADDRESS[32768] with algo #2 
Apr 12 13:20:20 Zaccaro racoon: INFO: NAT-D payload #1 doesn't match
Apr 12 13:20:20 Zaccaro racoon: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
Apr 12 13:20:20 Zaccaro racoon: INFO: NAT detected: PEER
Apr 12 13:20:20 Zaccaro racoon: INFO: Sending Xauth request
Apr 12 13:20:20 Zaccaro racoon: INFO: ISAKMP-SA established SERVER.IP.ADDRESS[4500]-CLIENT.IP.ADDRESS[32768] spi:651d506ebbf13d5b:98e862615eac09da
Apr 12 13:20:23 Zaccaro racoon: INFO: Using port 0
Apr 12 13:20:23 Zaccaro racoon: INFO: login succeeded for user "username"
Apr 12 13:20:23 Zaccaro racoon: WARNING: Ignored attribute INTERNAL_ADDRESS_EXPIRY
Apr 12 13:20:23 Zaccaro racoon: WARNING: Ignored attribute 28683
Apr 12 13:20:23 Zaccaro racoon: INFO: unsupported PF_KEY message REGISTER
Apr 12 13:20:23 Zaccaro racoon: INFO: respond new phase 2 negotiation: SERVER.IP.ADDRESS[4500]<=>CLIENT.IP.ADDRESS[32768]
Apr 12 13:20:23 Zaccaro racoon: INFO: no policy found, try to generate the policy : 10.1.0.0/32[0] 0.0.0.0/0[0] proto=any dir=in
Apr 12 13:20:23 Zaccaro racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Apr 12 13:20:23 Zaccaro racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Apr 12 13:20:23 Zaccaro racoon: INFO: IPsec-SA established: ESP/Tunnel CLIENT.IP.ADDRESS[32768]->SERVER.IP.ADDRESS[4500] spi=141535132(0x86fa79c)
Apr 12 13:20:23 Zaccaro racoon: INFO: IPsec-SA established: ESP/Tunnel SERVER.IP.ADDRESS[4500]->CLIENT.IP.ADDRESS[32768] spi=48270910(0x2e08e3e)
Apr 12 13:20:23 Zaccaro racoon: ERROR: such policy does not already exist: "10.1.0.0/32[0] 0.0.0.0/0[0] proto=any dir=in"
Apr 12 13:20:23 Zaccaro racoon: ERROR: such policy does not already exist: "10.1.0.0/32[0] 0.0.0.0/0[0] proto=any dir=fwd"
Apr 12 13:20:23 Zaccaro racoon: ERROR: such policy does not already exist: "0.0.0.0/0[0] 10.1.0.0/32[0] proto=any dir=out"
Apr 12 13:20:40 Zaccaro racoon: INFO: generated policy, deleting it.
Apr 12 13:20:40 Zaccaro racoon: INFO: purged IPsec-SA proto_id=ESP spi=48270910.
Apr 12 13:20:40 Zaccaro racoon: INFO: ISAKMP-SA expired SERVER.IP.ADDRESS[4500]-CLIENT.IP.ADDRESS[32768] spi:651d506ebbf13d5b:98e862615eac09da
Apr 12 13:20:41 Zaccaro racoon: INFO: ISAKMP-SA deleted SERVER.IP.ADDRESS[4500]-CLIENT.IP.ADDRESS[32768] spi:651d506ebbf13d5b:98e862615eac09da
Apr 12 13:20:41 Zaccaro racoon: INFO: Released port 0
Apr 12 13:20:41 Zaccaro racoon: INFO: unsupported PF_KEY message REGISTER
Apr 12 13:21:02 Zaccaro sm-msp-queue[23481]: unable to qualify my own domain name (Zaccaro) -- using short name

I think part of the problem might be stemming from the phase1up and phase1down scripts.

phase1-up.sh:

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

echo "
spdadd 192.168.1.0/24 ${INTERNAL_ADDR4}/32 any
        -P out ipsec esp/tunnel/${LOCAL_ADDR}[4500]-${REMOTE_ADDR}[4500]/require;
spdadd ${INTERNAL_ADDR4}/32 192.168.1.0/24 any
        -P in ipsec esp/tunnel/${REMOTE_ADDR}[4500]-${LOCAL_ADDR}[4500]/require;
" | setkey -c

phase1-down.sh:

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

echo "
deleteall ${REMOTE_ADDR} ${LOCAL_ADDR} esp;
deleteall ${LOCAL_ADDR} ${REMOTE_ADDR} esp;

spddelete 192.168.1.0/24[any] ${INTERNAL_ADDR4}[any] any
        -P out ipsec esp/tunnel/${LOCAL_ADDR}-${REMOTE_ADDR}/require;
spddelete  ${INTERNAL_ADDR4}[any] 192.168.1.0/24 [any] any
        -P in ipsec esp/tunnel/${REMOTE_ADDR}-${LOCAL_ADDR}/require;
" | setkey -c

All of this happens and the client says it is connected successfully with the IP address 10.1.0.0. At that point, any attempt to connect to the internet fails instantly. And that's the problem.

Edit: Here is a bit more diagnostic information.

When I am connected to the VPN, a ping to the public IP address of the VPS is successful. However, ping to 8.8.8.8 (the DNS server that the VPN is set to use by default) gives a timeout. Thus, no hostnames can be resolved at all.

Second edit:

» route -nv      
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
69.172.231.0    0.0.0.0         255.255.255.192 U     0      0        0 eth0
0.0.0.0         69.172.231.1    0.0.0.0         UG    0      0        0 eth0

» iptables -L -nv
Chain INPUT (policy ACCEPT 49270 packets, 6376K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 42570 packets, 8573K bytes)
 pkts bytes target     prot opt in     out     source               destination

please dfine "any attempt to connect to the internet fails instantly" ? is ping to your router working? is ping to the oher end of the vpn working? My guess is that the client set the default route to go over the VPN and this won't work if you dont have masquerade set up and you probably don't want everything to go to vpn anyway — Aleksandar Ivanisevic, Apr 20 '11 at 10:30
I added a bit more information that should answer your question. And yes, I do want everything from the client to go over the VPN, as the network I use it from blocks several important ports (like the ports used for IMAP), and it is completely insecure. Luckily, the insecure network doesn't block the required ports for VPN connections. — Carter Allen, Apr 21 '11 at 03:34

score 3 · Accepted Answer · answered Apr 21 '11 at 05:45

3

Where did you get the phase1-up.sh and phase1-down.sh scripts? There should be some examples in the racoon distribution, under .../racoon/samples/roadwarrior/client/. Try using those. As a quick experiment, you might replace all of the occurrences of 192.168.1.0/24 in those scripts with 10.1.0.0/24, but I don't know how you've set up the network on your Ubuntu VPS. If neither of those steps works, please post the output of the commands

route -nv
iptables -L -nv

on your Ubuntu VPS.

answered Apr 21 '11 at 05:45

justarobert

1,859
13
8

The sample roadwarrior configuration actually doesn't use phase1-up/down scripts, so I've removed that for now. I added the output from those two commands to my original question. – Carter Allen Apr 21 '11 at 06:25
The roadwarrior *server* doesn't use phase1-up/down, but the roadwarrior *client* requires them. You should have different configuration files for each. Beyond that, you are missing a `netmask4` argument in the `mode_cfg` block of your server config. When your VPN is up, what traffic do you want to have go through the VPN, just traffic between your remote client and the VPS, or all traffic between your remote client and the rest of the world, or something in between? – justarobert Apr 21 '11 at 06:43
I can't configure the client side beyond the simple form that the iPhone displays. As far as the mask goes, I'd like all traffic between the client and the outside world to be tunneled through the VPS. – Carter Allen Apr 21 '11 at 06:54
Sorry, the `netmask4` comment was unrelated to the traffic question. This comment interface is somewhat limited... What iPhone VPN client are you using, the built-in IPSec client? – justarobert Apr 21 '11 at 06:57
That's correct. It is labelled as a Cisco client, but racoon is supposed to support them just fine. – Carter Allen Apr 21 '11 at 06:58
1

Okay. It looked as if you were using racoon on the client side as well, given the client log you posted. Let us assume that you're using `netmask4 255.255.255.0`. In that case, you will want to run at least `iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth0 -j SNAT --to-source 69.172.231.11`. However, your VPS's iptables settings are extremely permissive, and you'll likely want to lock them down more. Also, check that IP forwarding is on: `cat /proc/sys/net/ipv4/ip_forward` should return 1. If not, you'll need to add `net/ipv4/ip_forward = 1` to `/etc/sysctl.conf` and run `sysctl -p`. – justarobert Apr 21 '11 at 07:14
1

Also, I believe you'll want `ip route add 10.1.0.0/24 dev eth0 src 69.172.231.11`. – justarobert Apr 21 '11 at 07:18
Hot damn! That works! Can you quickly explain what I need to do to make sure those iptables rules persist after a restart of the computer? And I know it is beyond the scope of the original question, but what would be the simplest way to "lock down" the my iptables rules? – Carter Allen Apr 21 '11 at 07:28
1

Persistence? Let's see. The `/etc/sysctl.conf` change is already persistent. For the route, add the line `up ip route add 10.1.0.0/24 dev eth0 src 69.172.231.11` to `/etc/network/interfaces` under `iface eth0`. To save your iptables rules, run `iptables-save > /etc/iptables.rules`, and then add `pre-up iptables-restore < /etc/iptables.rules` to `/etc/network/interfaces` under `iface eth0`. – justarobert Apr 21 '11 at 07:45
1

More generally, read https://help.ubuntu.com/community/IptablesHowTo for instructions on how to block traffic. Unfortunately, if you change your default policies to drop instead of accept, you will need to make some more exceptions to make your VPN work. See the IPTables filter section of http://en.gentoo-wiki.com/wiki/VPN_iPhone_IPSec for a bare minimum. – justarobert Apr 21 '11 at 07:49

Patrick Tescher · Answer 2 · 2011-04-21T16:22:12.660

0

It looks like your issue is unrelated to IPSEC. Out of the box Ubuntu does not route any packets, thus a connection like this will only allow you to access your server, not the internet.

What you need to do is follow a tutorial like this one: https://help.ubuntu.com/community/Internet/ConnectionSharing

That will help you set up Ubuntu as a router/firewall enabling NAT and routing.

You can skip the part about DHCP since you are already getting an IP through IPSEC.

edited Apr 21 '11 at 16:22

answered Apr 20 '11 at 16:22

Patrick Tescher

201
1
4

In the process of following that guide, I wasn't able to install the package "ipmasq" because it apparently hasn't been updated in a long time. I did everything else, and the same logs still occur, with the same results (no internet connection). – Carter Allen Apr 20 '11 at 23:53
You are definitely going to need that. Take a look at https://help.ubuntu.com/community/Internet/ConnectionSharing#Ubuntu%20Internet%20Gateway%20Method%20%28iptables%29 which should provide a bit more info. This should work with any Ubuntu distro. – Patrick Tescher Apr 21 '11 at 05:36

iOS/Mac-Compatible IPSec VPN Server on Ubuntu

2 Answers2