Martin Melka's questions

I am trying to configure OpenVPN Access Server to route certain traffic through an IPSec tunnel established on the OpenVPN server. These are the addressing details:

• OpenVPN client IP range: 10.0.1.0/24
• OpenVPN server IP (where clients connect to): x.x.x.x
• IPSec tunnel peer: y.y.y.y
• IPSec tunnel subnets: (x.x.x.x) 10.0.1.0/24 <--> 172.30.239.0/25 (y.y.y.y)

The expected behavior from the point of the OpenVPN client is this:

• curl 172.30.239.75 -> traffic will go from the client to the OpenVPN server, be routed through the IPSec tunnel, and end up in the 172.30.239.0/25 network
• curl google.com -> traffic will go from the client to the OpenVPN server and to the public internet through its default gateway (not using the IPSec tunnel at all)

I thought this configuration would "just work", since the OpenVPN clients get their IP addresses assigned from the same subnet as the IPSec tunnel, but sadly that is not the case.

I am able to reach the far IPSec subnet directly from the OpenVPN server with e.g. curl 172.30.239.75, so the tunnel and some routing is working. But running the same request from an OpenVPN client just times out (tcpdump shows that the request arrives at the OpenVPN server but it ends there).

I am completely lost at what I should try next. Could you help me out? I am pretty new to this so detailed answers would be really appreciated! This question is related to this one I made earlier but that did not have enough details for the actual implementation.

Below I tried to collect relevant configuration but if there is anything else that would be important, please let me know.

I have not added any custom interfaces, routes nor iptables rules. All those that I tried either didn't have any effect or messed something up, so the output below is what was configured by OpenVPN and IPSec.

Interfaces

$ ifconfig (truncated)
as0t0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.0.1.1  netmask 255.255.255.128  destination 10.0.1.1

as0t1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.0.1.129  netmask 255.255.255.128  destination 10.0.1.129

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet x.x.x.x  netmask 255.255.252.0  broadcast x.x.x.x

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.7.177  netmask 255.255.252.0  broadcast 10.1.7.255

Routing

The [gw.gw.gw.gw] below is the IP address of the default gateway of the eth0 iface

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        10.1.4.1        255.0.0.0       UG    0      0        0 eth1
10.0.1.0        0.0.0.0         255.255.255.128 U     0      0        0 as0t0
10.0.1.128      0.0.0.0         255.255.255.128 U     0      0        0 as0t1
10.1.4.0        0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.169.254 10.1.4.1        255.255.255.255 UGH   0      0        0 eth1
x.x.x.0         0.0.0.0         255.255.252.0   U     0      0        0 eth0



$ ip route list table all
172.30.239.0/25 via [gw.gw.gw.gw] dev eth0 table 220 proto static src 10.0.1.1
default via [gw.gw.gw.gw] dev eth0
10.0.1.0/25 dev as0t0 proto kernel scope link src 10.0.1.1
10.0.1.128/25 dev as0t1 proto kernel scope link src 10.0.1.129
x.x.x.0/22 dev eth0 proto kernel scope link src x.x.x.x
broadcast 10.0.1.0 dev as0t0 table local proto kernel scope link src 10.0.1.1
local 10.0.1.1 dev as0t0 table local proto kernel scope host src 10.0.1.1
broadcast 10.0.1.127 dev as0t0 table local proto kernel scope link src 10.0.1.1
broadcast 10.0.1.128 dev as0t1 table local proto kernel scope link src 10.0.1.129
local 10.0.1.129 dev as0t1 table local proto kernel scope host src 10.0.1.129
broadcast 10.0.1.255 dev as0t1 table local proto kernel scope link src 10.0.1.129
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast x.x.x.0 dev eth0 table local proto kernel scope link src x.x.x.x
local x.x.x.x dev eth0 table local proto kernel scope host src x.x.x.x
broadcast 185.26.51.255 dev eth0 table local proto kernel scope link src x.x.x.x

iptables

iptables-save
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*nat
:PREROUTING ACCEPT [655:63952]
:INPUT ACCEPT [82:5300]
:OUTPUT ACCEPT [72:5613]
:POSTROUTING ACCEPT [72:5613]
:AS0_NAT - [0:0]
:AS0_NAT_POST_REL_EST - [0:0]
:AS0_NAT_PRE - [0:0]
:AS0_NAT_PRE_REL_EST - [0:0]
:AS0_NAT_TEST - [0:0]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j AS0_NAT_PRE_REL_EST
-A POSTROUTING -m state --state RELATED,ESTABLISHED -j AS0_NAT_POST_REL_EST
-A POSTROUTING -m mark --mark 0x2000000/0x2000000 -j AS0_NAT_PRE
-A AS0_NAT -o eth0 -j SNAT --to-source x.x.x.x
-A AS0_NAT -o eth1 -j SNAT --to-source 10.1.7.177
-A AS0_NAT -j ACCEPT
-A AS0_NAT_POST_REL_EST -j ACCEPT
-A AS0_NAT_PRE -m mark --mark 0x8000000/0x8000000 -j AS0_NAT
-A AS0_NAT_PRE -d 169.254.0.0/16 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 192.168.0.0/16 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 172.16.0.0/12 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 10.0.0.0/8 -j AS0_NAT_TEST
-A AS0_NAT_PRE -j AS0_NAT
-A AS0_NAT_PRE_REL_EST -j ACCEPT
-A AS0_NAT_TEST -o as0t+ -j ACCEPT
-A AS0_NAT_TEST -m mark --mark 0x4000000/0x4000000 -j ACCEPT
-A AS0_NAT_TEST -d 10.0.1.0/24 -j ACCEPT
-A AS0_NAT_TEST -j AS0_NAT
COMMIT
# Completed on Thu May 27 23:20:08 2021
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*mangle
:PREROUTING ACCEPT [48:3312]
:INPUT ACCEPT [19672:4609821]
:FORWARD ACCEPT [32480:9628950]
:OUTPUT ACCEPT [18602:11259270]
:POSTROUTING ACCEPT [51071:20887532]
:AS0_MANGLE_PRE_REL_EST - [0:0]
:AS0_MANGLE_TUN - [0:0]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j AS0_MANGLE_PRE_REL_EST
-A PREROUTING -i as0t+ -j AS0_MANGLE_TUN
-A AS0_MANGLE_PRE_REL_EST -j ACCEPT
-A AS0_MANGLE_TUN -j MARK --set-xmark 0x2000000/0xffffffff
-A AS0_MANGLE_TUN -j ACCEPT
COMMIT
# Completed on Thu May 27 23:20:08 2021
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*filter
:INPUT ACCEPT [12:660]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [18526:11256230]
:AS0_ACCEPT - [0:0]
:AS0_IN - [0:0]
:AS0_IN_NAT - [0:0]
:AS0_IN_POST - [0:0]
:AS0_IN_PRE - [0:0]
:AS0_IN_ROUTE - [0:0]
:AS0_OUT - [0:0]
:AS0_OUT_LOCAL - [0:0]
:AS0_OUT_POST - [0:0]
:AS0_OUT_S2C - [0:0]
:AS0_WEBACCEPT - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j AS0_ACCEPT
-A INPUT -i lo -j AS0_ACCEPT
-A INPUT -m mark --mark 0x2000000/0x2000000 -j AS0_IN_PRE
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j AS0_ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j AS0_ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j AS0_WEBACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 943 -j AS0_WEBACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j AS0_ACCEPT
-A FORWARD -m mark --mark 0x2000000/0x2000000 -j AS0_IN_PRE
-A FORWARD -o as0t+ -j AS0_OUT_S2C
-A OUTPUT -o as0t+ -j AS0_OUT_LOCAL
-A AS0_ACCEPT -j ACCEPT
-A AS0_IN -d 10.0.1.1/32 -j ACCEPT
-A AS0_IN -j AS0_IN_POST
-A AS0_IN_NAT -j MARK --set-xmark 0x8000000/0x8000000
-A AS0_IN_NAT -j ACCEPT
-A AS0_IN_POST -d 10.0.1.0/24 -j ACCEPT
-A AS0_IN_POST -o as0t+ -j AS0_OUT
-A AS0_IN_POST -j DROP
-A AS0_IN_PRE -d 169.254.0.0/16 -j AS0_IN
-A AS0_IN_PRE -d 192.168.0.0/16 -j AS0_IN
-A AS0_IN_PRE -d 172.16.0.0/12 -j AS0_IN
-A AS0_IN_PRE -d 10.0.0.0/8 -j AS0_IN
-A AS0_IN_PRE -j ACCEPT
-A AS0_IN_ROUTE -j MARK --set-xmark 0x4000000/0x4000000
-A AS0_IN_ROUTE -j ACCEPT
-A AS0_OUT -j AS0_OUT_POST
-A AS0_OUT_LOCAL -p icmp -m icmp --icmp-type 5 -j DROP
-A AS0_OUT_LOCAL -j ACCEPT
-A AS0_OUT_POST -j DROP
-A AS0_OUT_S2C -s 10.0.1.0/24 -j ACCEPT
-A AS0_OUT_S2C -j AS0_OUT
-A AS0_WEBACCEPT -j ACCEPT
COMMIT
# Completed on Thu May 27 23:20:08 2021

I also tried not having the OpenVPN client IP subnet and IPSec tunnel subnet overlap, but I could not figure out a way to set up the routing in this case either. That setup is definitely an option though, if that way would be better.

I'm trying to get some sort of time synchronization configured for a Ubuntu server. The server is behind a cloud-provider-stateless firewall. Through some trial and error I found out that in order for ntp to work, I have to open the incoming UDP port 123.

Then I read that using systemd-timesyncd is preferred nowadays, so I tried switching over to that. But that did not work. The service log was full of

systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com).
systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com).

Only after I also whitelisted the ephemeral UDP ports 32768–65535 in the firewall did this start to work:

systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

Is opening that range of ports really necessary to operate systemd-timesync?

Edit in response to @Jesus-Loves-You's response below. The higher ports should not be necessary, but in my case, for some reason, they clearly are. See the log of the systemd-timesync service (annotated by me with #):

# Before I enabled the 32786+ ports
May 21 11:49:21 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.198:123 (ntp.ubuntu.com).

# After I enabled the ports
May 21 11:49:06 myhost systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

# After I disabled them again. Note that there are no log entries inbetween for almost
# three days. This, imo, pretty much proves that the ports are required.
May 24 09:29:34 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com).

Further information about the port:

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:42212           0.0.0.0:*                           2656121/systemd-tim

Looks like 42212 is the port where the service expects the communication to happen. But after a couple of minutes, when the next polling occurs:

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:37240           0.0.0.0:*                           2656121/systemd-tim

Now the port changed. And after a couple of minutes it changed again to 51120. So from that I conclude that the service really tries to communicate on random ports each time it attempts the sync.

A small company I work at is getting rid of an office soon and it has fallen onto me to migrate the currently on-prem-hosted VPN (just a Zyxel Zywall 110 device) into a cloud-based VM. I am not that experienced in networking (backend-dev-turned-ops) so I would like to validate if the following approach will work.

I have a dedicated VM where I've set up OpenVPN Access Server and the basics are working well, people can connect, all good.

There is one catch though, the current VPN forwards a certain IP range through a "tunnel" into a partner company's internal network. It looks like this:

if dest_addr in '172.30.239.0/25':
    route through gw 194.xxx.xxx.xxx
else:
    route through gw 0.0.0.0

As an example, when connected to the VPN, my traffic would be routed as such:

dest 1.2.3.4       => me -> VPN server -> its internet gateway -*-> 1.2.3.4
dest 172.30.239.10 => me -> VPN server -> partner network gateway (194.xxx.xxx.xxx) -(internal network routing)-> 172.30.239.10

Where the connection from our router to the partner company's VPN GW is done via IKEv1 with pre-shared key (judging from the router's web UI, as that's all the "documentation" I have).

Some ascii art depicting the setup below. I am replacing Router with a VM.

            +-----------------+           [     Partner infra, this has to stay the same     ]
            | Router          |           194.xxx.xxx.xxx            e.g. 172.30.239.75
            | --------------- |   IKEv1   +-------------+       +-------------------------+
User -----> | 172.30.239.0/25-| --------> | VPN gateway |-----> | Internal network server |
            |     default     |           +-------------+       +-------------------------+
            |        |        |
            +--------+--------+
                     |
                     |
                 internet

The OpenVPN Access Server does not support anything like this by itself (or I haven't been able to find that config), so I thought I could do it on the VM level. If I connect the OS to the VPN gateway with something like Strongswan and configure appropriate routing in iptables, could this work? Would the traffic of users connected to the OpenVPN server going to the 172.30.239.0/25 range get routed through to the Strongswan's connection, or is this approach fundamentally wrong? What are my options?

Thanks!

I want to achieve a simple thing - proxy mydomain.com/plex/* into localhost:32400/*. I already have a different proxying rule in place that works fine, but this I cannot get to work.

My sites-enabled config:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias *.example.com

    ProxyRequests Off
    ProxyPreserveHost On

    <Location "/myapp"> ### This works fine, reverse-proxies to a Tomcat server
        ProxyPass http://localhost:8080/myapp
        ProxyPassReverse http://example.com/myapp
    </Location>

    <Location "/plex"> ### This does not work
        ProxyPass http://localhost:32400
        ProxyPassReverse http://example.com/plex
    </Location>

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
</VirtualHost>

Expected: If I open URL http://example.com/plex/web/index.html, it should be proxied on the server into http://localhost:32400/web/index.html - and that page should be fetched. (opening that localhost address from the server works fine.

What I get: unfortunately all I get is 404 Not Found.

I have found some guides on setting up reverse proxy for Plex (which is what I am trying to do), but they dealt with https, subdomains and others. All I want is a very simple redirection between a location and a port.

Thanks for any help

I need to set up a local LDAP proxy cache which connects to our central Active Directory server. OpenLDAP Proxy Cache looks just like the thing. But following the manpages as closely as possible, I am not able to get it working.

I am able to proxy requests through localhost to the remote server, but they are not cached (or the cache not retrieved, at least).

The steps I made:

• Installed openldap-servers and openldap-clients packages
• Created a slapd.conf config file (details below)
• Created a directory for the proxy database and copied the default DB_CONFIG file there (details below)
• Ran slapd -d -1 command to start the server
• Queried the server using this command: ldapwhoami -vvv -h localhost -D "CN=Melka Martin,OU=(...),DC=int,DC=ourdomain,DC=com" -x -w <password>

The result is success. But sniffing network trafic shows the query is pooled from the central LDAP server.

The slapd output is pretty verbose, but it does at one point state

QUERY NOT ANSWERABLE
QUERY CACHEABLE

Alas, if it does get cached, it is never answered. Any ideas what can be wrong?

"cn=admin,dc=int,dc=ourdomain,dc=com" is the DN of an admin user in the remote LDAP server. <something> is his password.

slapd.conf

database        ldap
suffix          "dc=int,dc=ourdomain,dc=com"
rootdn          "cn=admin,dc=int,dc=ourdomain,dc=com"
rootpw          <something>
uri             ldap://dc-04.int.ourdomain.com:389

overlay pcache
pcache         hdb 100000 1 1000 100
pcacheAttrset  0 *
pcacheTemplate (sn=) 0 3600
pcacheBind (sn=) 0 3600 sub dc=int,dc=ourdomain,dc=com

cachesize 200
directory /var/lib/ldap
index       objectClass eq
index       cn eq,sub

DB_CONFIG

# $OpenLDAP$

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152

The verbose log output: http://pastebin.com/9s8HMg7d