4

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         
2
  • 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 Apr 20, 2011 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. Apr 21, 2011 at 3:34

2 Answers 2

3
+50

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.

10
  • 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. Apr 21, 2011 at 6:25
  • 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. Apr 21, 2011 at 7:14
  • 1
    Also, I believe you'll want ip route add 10.1.0.0/24 dev eth0 src 69.172.231.11. Apr 21, 2011 at 7:18
  • 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. Apr 21, 2011 at 7:45
  • 1
    More generally, read 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 en.gentoo-wiki.com/wiki/VPN_iPhone_IPSec for a bare minimum. Apr 21, 2011 at 7:49
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.

2
  • 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). Apr 20, 2011 at 23:53
  • You are definitely going to need that. Take a look at help.ubuntu.com/community/Internet/… which should provide a bit more info. This should work with any Ubuntu distro. Apr 21, 2011 at 5:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .