Isaac Sutherland's questions

OS: Ubuntu 16.04.2 LTS

My VPN config has directives:

user ovpn
group ovpn
up "/path/to/my/script"
down "/path/to/my/script"

My visudo file has the directive:

%ovpn ALL=(ALL:ALL) NOPASSWD: /sbin/iptables

This allows openvpn to deescalate from root to the unprivileged user ovpn (for security reasons), but still use iptables to bring up and down routes loaded from a database. It works if I invoke the openvpn process directly from a shell, i.e.:

$ sudo openvpn /etc/openvpn/vpn0.conf

and then kill it with CTRL-C. By "it works" I mean that the iptables rules are added and removed as desired without any errors.

However, if I start and stop the openvpn process using the vanilla Ubuntu systemd openvpn service. i.e.

$ sudo systemctl start openvpn
$ sudo systemctl stop openvpn

then the "--down" script fails during execution of the "stop" command. When I examine the syslog I see that the --down script has failed at the shell command invoking sudo /sbin/iptables, specifically where it is attempting to fork the process. (regarding error message, my script is a python script using subprocess.call(['/usr/bin/sudo', '/sbin/iptables', ...]). Error message is:

File "/usr/lib/python2.7/subprocess.py", line 523, in call
  return Popen(*popenargs, **kwargs).wait()
File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
  errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1235, in _execute_child
  self.pid = os.fork()
OSError: [Errno 11] Resource temporarily unavailable

If I remove the user and group directives from the openvpn configuration file so that the process remains root throughout execution, then I don't get the error, and the iptables invocations work as expected, even when using the systemd service to start and stop.

So it smells like systemd is preventing me from escalating privileges using sudo while shutting down the service.

Any ideas on how to overcome this difficulty while still deescalating to an unprivileged user?

I have an openvpn tunnel which runs an --up script which queries a local mysql database for IP routing information and then applies the routes. However, since both the openvpn and mysql systemd services are configured with the After=network.target directive, I have a race condition: /var/run/mysqld/mysqld.sock might exist when the --up script runs, or it might not. If the sock file doesn't exist, then my script dies and the system doesn't initialize properly.

I thought that changing my openvpn.service directive to After=network.target mysql.service and running systemctl daemon-reload would do the trick. However, I added ls -lh /var/run/mysqld/mysqld.sock to the beginning of my --up script, and it still sometimes reports ls: cannot access '/var/run/mysqld/mysqld.sock': No such file or directory.

My guess is that systemd's is not using the sock file to determine whether or not mysqld has finished loading but rather some criteria that happens before the sock file is created.

Is there a way to tell systemd to not recognize mysql.service as having started until the sock file has been created?

I have an openvpn server which allows incoming connections from multiple mobile clients. The mobile clients are embedded linux platforms with two possible routes to the Internet: a cellular interface and a wifi interface. The mobile clients spend a lot of time out of range of any available wifi. So most of the time they will use the cellular Internet gateway. When in range of a wifi network, the wifi interface comes up, and the default route is changed to the wifi interface.

Problem: when the wifi interface comes up, the default route is changed to use the wifi interface, so the client openvpn starts sending packets out the wifi interface. These packets arrive at the server, but the server ignores them. I thought that since the server doesn't have a remote directive set, it should automatically allow the client to "float" to a new address, so the server should recognize the packets coming from the client and start responding to the new route immediately. Instead, I see the server's keepalive pings arriving on the client's cellular interface, and I see the client's keepalive pings arriving at the server from its wifi interface. Eventually an Inactivity timeout (--ping-restart) resets the old connection, and a new connection is established successfully via the wifi interface. Why isn't the server letting the client float?

Server configuration:

dev tun0
topology subnet
mode server
tls-server
duplicate-cn
push "topology subnet"
ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.200 10.0.0.254 255.255.255.0
port 12345
proto udp
persist-key
persist-tun
comp-lzo
ca /etc/openvpn/ssl/tmvca-cacert.pem
cert /etc/openvpn/ssl/principal-cert.pem
key /etc/openvpn/ssl/principal-key.pem
dh /etc/openvpn/ssl/dh1024.pem
username-as-common-name
keepalive 50 120
client-to-client
user nobody
group nogroup
verb 3
float

Client configuration:

client
remote mydomain.com 12345
nobind
proto udp
mssfix 1400
persist-key
persist-tun
dev tun
ns-cert-type server
resolv-retry infinite
ca /opt/odp/openvpn/ca.pem
cert /opt/odp/openvpn/crt.pem
key /opt/odp/openvpn/key.pem
dh /opt/odp/openvpn/dh1024.pem
comp-lzo
verb 3
syslog ovpn-gw
auth-user-pass /opt/odp/openvpn/auth.passwd
writepid "/tmp/ovpn-gw.pid"
tls-remote principal
tls-exit
ipchange /opt/odp/scripts/ipchange.sh
script-security 2

I've configured a 3G IP Gateway of mine to connect using IKE Phase 1 Aggressive Mode with PSK to my openswan installation running on Ubuntu server 12.04. I've configured openswan as follows:

/etc/ipsec.conf:

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    [email protected]
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    [email protected]
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    aggrmode=yes
    ike=aes128-md5;modp1536
    auto=add

/etc/ipsec.secrets:

@left.paxcoda.com @right.paxcoda.com: PSK "testpassword"

Note that both left and right are NAT'd, with dynamic public IP's. My left ISP gives my router a public IP, but my right ISP gives me a shared dynamic public IP and dynamic private IP. I have dynamic dns for the public ip on the left side. Here is what I see when I sniff the ISAKMP protocol:

21:17:31.228715 IP (tos 0x0, ttl 235, id 43639, offset 0, flags [none], proto UDP (17), length 437)
    74.198.87.93.49604 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->0000000000000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(da31a7896e2a19582b33...0000001462b01880674b3739630ca7558cec8a89))
    (id: idtype=FQDN protoid=0 port=0 len=17 right.paxcoda.com)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
21:17:31.236720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 456)
    192.168.0.11.isakmp > 74.198.87.93.49604: [bad udp cksum 0x649c -> 0xcd2f!] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->5b9776d4ea8b61b7: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(32ccefcb793afb368975...000000144a131c81070358455c5728f20e95452f))
    (id: idtype=FQDN protoid=0 port=0 len=16 left.paxcoda.com)
    (hash: len=16)
    (vid: len=16)
    (pay20)
    (pay20)
    (vid: len=16)

However, my 3G Gateway (on the right) doesn't respond, and I don't know why. I think left's response is indeed getting through to my gateway, because in another question, I was trying to set up a similar scenario with Main Mode IKE, and in that case it looks as though at least one of the three 2-way main mode exchanges succeeded.

What other explanation for the failure is there?

(The 3G Gateway I'm using on the right is a Moxa G3150, by the way.)

I have a wireless gateway that supports site-to-site IPSec. I have configured openswan on Ubuntu Server 12.04 (left side of the tunnel) with the following /etc/ipsec.conf:

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    auto=add

I have configured the wireless gateway (right side of the tunnel) similarly. I am using Main Mode (not Aggressive Mode) IKE stage 1, but it looks like it fails before it gets to stage 2. Any thoughts on why?

Here is the output from tcpdump:

# tcpdump -vv -i eth0 udp port 500 or udp port 4500
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:11:26.042928 IP (tos 0x0, ttl 235, id 39655, offset 0, flags [none], proto UDP (17), length 196)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
00:11:26.044511 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 172)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x6361 -> 0x70a3!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=12)
    (vid: len=16)
    (vid: len=16)
00:11:26.683227 IP (tos 0x0, ttl 235, id 39656, offset 0, flags [none], proto UDP (17), length 312)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 I ident:
    (ke: key len=192)
    (nonce: n len=16  data=(7d88f683ff25b40ac37b...00000014471b8027b9d2d76240f4329456eb22db))
    (pay20)
    (pay20)
00:11:26.688968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:36.704351 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:56.165304 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)

The right side of the tunnel is attempting to initiate the tunnel using Main Mode IKE phase 1. Main Mode involves three 2-way exchanges. OpenSWAN responds to the 1st 2 exchanges, but for some reason the right side doesn't initiate the 3rd exchange. What could possibly fail at that point in the process?

I'm using OpenSWAN to set up a net-to-net VPN tunnel. I have succeeded in configuring a test scenario as follows:

About test and test2:

• they are Ubuntu 12.04 virtual machines created using ubuntu-vm-builder
• they use bridged networking to the host's physical ethernet (the 192.168.0.0/24 subnet).
• I installed the standard openswan package.
• each has a dummy interface which is accessible from the other end of the VPN tunnel.

This is how I configured the tunnel:

/etc/ipsec.conf (identical on both left and right):

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=192.168.0.12
    rightsubnet=10.2.0.0/16
    rightsourceip=10.2.0.1
    auto=start

/etc/ipsec.secrets (identical on both left and right):

192.168.0.11 192.168.0.12: PSK "mytestpassword"

/etc/rc.local (on left):

modprobe dummy
ifconfig dummy0 10.1.0.1 netmask 255.255.0.0

iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/16 ! -d 10.2.0.0/16 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart

exit 0

/etc/rc.local (on right):

modprobe dummy
ifconfig dummy0 10.2.0.1 netmask 255.255.0.0

iptables -t nat -A POSTROUTING -o eth0 -s 10.2.0.0/16 ! -d 10.1.0.0/16 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart

exit 0

Now, I would like to set up the following scenario:

Issues I need to understand:

• Can IPSec connect through a VPN gateway which is sharing a public ip via NAT (inbound NAT traversal)? Do NAT-T and IPSec passthrough relate to this or are they just for outbound NAT (i.e. dealing with clients which are behind NAT but where the gateway has a public IP)? Would it be sufficient to forward some ports from router1 to test, or would that be incompatible with IPSec?
• Can both ends of an IPSec tunnel have dynamic IP's as long as one has a domain name and dynamic dns?

Under Ubuntu 12.04, I've written the following C program to help me shut down my server's apache2 and samba services while I run automated backups. Notice that in the Makefile I'm setting the SUID bit so that the program will have root privileges when run by the lowly user tmv.

services.c:

#include <stdio.h>
#include <stdlib.h>

void usage(char * arg0) {
    printf("Usage: %s start|stop\n", arg0);
    exit(1);
}

int main(int argc, char ** argv) {
    fprintf(stderr, "Running as: ");
    system("whoami");
    if (argc != 2) usage(argv[0]);
    if (!strcmp(argv[1], "stop")) {
        printf("Before running rsync, we need to shut down apache2 and smbd.\n");
        system("service apache2 stop");
        system("service smbd stop");
    } else if (!strcmp(argv[1], "start")) {
        printf("After running rsync, we need to start apache2 and smbd.\n");
        system("service apache2 start");
        system("service smbd start");
    } else {
        usage(argv[0]);
    }
    return 0;
}

Makefile:

all: services.c
    gcc -o services services.c
    chown root:tmv services
    chmod u+s services      # allow elevation to root
    chmod o-rx services     # only user tmv should execute

Here's what I get:

tmv@patience:~$ ./services start
Running as: root
After running rsync, we need to start apache2 and smbd.
 * Starting web server apache2                                           [ OK ] 
start: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

Running as root works fine:

# ./services start
Running as: root
After running rsync, we need to start apache2 and smbd.
 * Starting web server apache2                                           [ OK ] 
smbd start/running, process 8515

Any ideas why my ./services isn't working as expected when run as the user tmv? Do I need to configure some environment variables too?

I need a shell script which will retrieve the maximum memory consumption of a linux executable. The executable may spawn child processes using significant amounts of RAM which should be included in the total.

I've tried /usr/bin/time -f "%M" /path/to/executable, but this always yields 0 though using ps I can verify the process is indeed consuming significant RAM.

Why is time giving me 0 all the time, and how can I get the number I'm looking for?