Background<\/h2>\n\n\n\n
The implementation proved useful for me when I switched from my DSL ISP who happily had provided me with “real” (routable) IPv4 and IPv6 addresses to a new fiber-optics ISP that provides IPv6, but that uses CG-NAT on IPv4 so that no incoming IPv4 connections are possible from the internet. As I feared that my server at home would only be accessible from the internet via IPv6, I had to develop this counterstrategy.<\/p>\n\n\n\n
Preconditions<\/h2>\n\n\n\n
In order to use the approach described here, you should:<\/p>\n\n\n\n
- \n
- \u2026 have access to a Linux machine which is already properly configured for dual stack on its principal network interface (e.g., eth0<\/em>)<\/li>\n\n\n\n
- \u2026 additionally have access to a cloud-based Linux server which is already properly configured for dual stack on its principal network interface<\/li>\n\n\n\n
- … have access to a DNS resolver where you can enter an IPv4 and an IPv6 addresses for your SoHo server so that your domain resolves properly<\/li>\n\n\n\n
- \u2026 have the package openvpn<\/a> installed on both machines (preferably from a repository of your Linux distribution)<\/li>\n\n\n\n
- \u2026 know how to create client and server certificates for openvpn<\/a> [1<\/a>]<\/li>\n\n\n\n
- \u2026 have knowledge of routing concepts, networks, some understanding of shell scripts and configuration files<\/li>\n\n\n\n
- \u2026 know related system commands like sysctl<\/em><\/li>\n\n\n\n
- … familiarize yourself with [2<\/a>], [3<\/a>], [4<\/a>], [5<\/a>]<\/li>\n<\/ul>\n\n\n\n
Description and Usage<\/h2>\n\n\n\n
![\"Routing](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/Routing-via-a-VPS.png\")
Routing IPv4 traffic from the internet via a VPS back to a SoHo-based server<\/figcaption><\/figure>\n\n\n\n In this setup, we have a full-blown SoHo server (Server 1<\/strong>) which is hosting numerous services that we want to offer to the world. However, while the provider allocates an IPv6 \/64 subnet, he does not offer an IPv4 address that would be reachable from the internet. Rather than that, he employs Carrier-grade NAT<\/a> (CG-NAT) for IPv4. This is a typical setup for fiber-optics or cable providers or for mobile network providers. In some countries (which came late to the internet), IPv4 addresses are scarce in general, and so you might experience CG-NAT for all private internet connections.<\/p>\n\n\n\n
This is where Server 2<\/strong> comes into play. Server 2<\/strong> is a hosted shared server, it just needs a good internet connection and a fixed IPv4 address, but it does not need a lot of computational power. It will only be used to forward traffic to Server 1<\/strong>. In my case, I rented a small “VPS” server from Ionos<\/a> as I personally found their offer compelling [6<\/a>], but there are alternatives. My VPS has a dual-stack and a fixed IPv4 address and a fixed IPv6 \/64 subnet allocated. The IPv4 address of the VPS is 85.215.215.32<\/strong>, and we will use this IPv4 address as entry address for our SoHo server (Server 1<\/strong>) caipirinha.spdns.org<\/strong>.<\/p>\n\n\n\n
A new Routing Table<\/h3>\n\n\n\n
We want to separate the traffic that we receive and send out in return via the VPN network (192.168.20.0\/24<\/strong>) from the regular traffic that enters and leaves the server via the network 192.168.2.0\/24<\/strong>. Therefore, we set up a new routing table<\/a> as described in [7<\/a>] and name it “VPS”. In order to access it via its name, we modify \/etc\/iproute2\/rt_tables<\/strong>:<\/p>\n\n\n\n
#\n# reserved values\n#\n255 local\n254 main\n253 default\n0 unspec\n#\n# local\n#\n#1 inr.ruhep\n\n...\n201 VPS\n...<\/code><\/pre>\n\n\n\nSetting up a permanent VPN<\/h3>\n\n\n\n
First, we need to set up a permanent VPN connection from Server 1 to Server 2. Server 1 <\/strong>will be the VPN client, and Server 2 will be the VPN server. I chose this direction because in that approach, Server 1 may even be connected to the internet via a mobile only connection CG-NAT both on IPv4 and IPv6. In my approach, I use the network 192.168.20.0\/24 for the VPN connection; Server 1 gets the address 192.168.20.3 and Server 2 gets the address 192.168.20.1.<\/p>\n\n\n\n
Server 2: The VPN Server<\/h4>\n\n\n\n
On Server 2, we set up a VPN server listening on port 9010 (UDP), using dev tun3<\/em>. The configuration file is shown below. In my case, Server 2 is an Ubuntu-based server, and so it is recommended to adjust the settings in the configuration file \/etc\/default\/openvpn<\/strong> which governs the behavior of openvpn connections on Ubuntu. I modified this configuration file so that only one openvpn service is started. This is done via the configuration option<\/p>\n\n\n\n
AUTOSTART=\"server-9010\"<\/code><\/pre>\n\n\n\nFor the configuration of the server side, I meanwhile include the CA certificate, the server certificate and the private key in one configuration file. I find that more convenient, but it certainly may have disadvantages, The key message is that it is possible to do so. My own certificates and private keys have been substituted by “…” here, of course.<\/p>\n\n\n\n
# Konfigurationsdatei f\u00fcr den openVPN-Server auf IONOS VPS (UDP:9010)\n\nclient-config-dir \/etc\/openvpn\/server\/conf-9010\ncrl-verify \/etc\/openvpn\/server\/crl.pem\ndev tun3\ndh \/etc\/openvpn\/server\/dh.pem\nhand-window 90\nifconfig 192.168.20.1 255.255.255.0\nifconfig-pool 192.168.20.2 192.168.20.254 255.255.255.0\nifconfig-ipv6 fd01:0:0:14::1 2a01:239:24e:1800::1\nifconfig-ipv6-pool fd01:0:0:14::2\/112\nifconfig-pool-persist \/etc\/openvpn\/server\/ip-pool-9010.txt\nkeepalive 20 80\nlog \/var\/log\/openvpn\/server-9010.log\nmode server\npersist-key\npersist-tun\nport 9010\nproto udp6\nreneg-sec 86400\nscript-security 2\nstatus \/var\/run\/openvpn\/status-9010\ntls-server\ntopology subnet\nverb 1\nwritepid \/var\/run\/openvpn\/server-9010.pid\n\n# Topologie des VPN und Default-Gateway\npush \"topology subnet\"\npush \"tun-ipv6\"\n\n<ca>\n-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n<\/ca>\n\n<cert>\n-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n<\/cert>\n\n<key>\n-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n<\/key><\/code><\/pre>\n\n\n\nWe also must take care that our client always gets the IP address 192.168.20.3 as we originally envisioned. This is done with the client-specific configuration file \/etc\/openvpn\/server\/conf-9010\/caipirinha_client<\/strong>:<\/p>\n\n\n\n
# Spezielle Konfigurationsdatei f\u00fcr den Server caipirinha.spdns.org als Client\n#\n\nifconfig-push 192.168.20.3 255.255.255.0\nifconfig-ipv6-push fd01:0:0:14::3\/111 fd01:0:0:14::1<\/code><\/pre>\n\n\n\nThe client-specific configuration file additionally also allocates the static IPv6 address fd01:0:0:14::3 to our client. Finally, the service can then be started with:<\/p>\n\n\n\n
systemctl start openvpn@server-9010.service<\/code><\/pre>\n\n\n\nServer 1: The VPN Client<\/h4>\n\n\n\n
On Server 1, we set up a VPN client using dev tun3<\/em>. The local port shall always be 5475 (arbitrarily chosen but fixed so that we can track the connection easily if necessary). Server 2 is addressed via its public IPv6 address (2a01:239:24e:1800::1), but we could also have used its public IPv4 address (85.215.215.32). I chose the IPv6 address because the IPv4 connection would run via the provider gateway, and that might slow down the connection or make it less reliable.<\/p>\n\n\n\n
# Konfigurationsdatei f\u00fcr den openVPN-Client auf caipirinha.spdns.org zum IONOS-Server\n\nclient\ndev tun3\nexplicit-exit-notify\nhand-window 90\nkeepalive 10 60\nlog \/var\/log\/openvpn_ionos_vpn.log\nlport 5475\npersist-key\npersist-tun\nproto udp\nremote 2a01:239:24e:1800::1 9010\nremote-cert-tls server\nremote-random\nreneg-sec 86400\nroute-nopull\nscript-security 2\nstatus \/var\/run\/openvpn\/status_ionos_vpn\nup \/etc\/openvpn\/start_piavpn.sh\nverb 1\n\n<ca>\n-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n<\/ca>\n\n<cert>\n-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n<\/cert>\n\n<key>\n-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n<\/key><\/code><\/pre>\n\n\n\nOne peculiarity is the referenced script \/etc\/openvpn\/start_piavpn.sh<\/strong><\/strong>. At the start of the VPN connection, this script populates the routing table VPS:<\/p>\n\n\n\n
#!\/bin\/bash\n#\n# This script requires the tool \"ipcalc\" which needs to be installed on the target system.\n\n# Set the correct PATH environment\nPATH='\/sbin:\/usr\/sbin:\/bin:\/usr\/bin'\n\nVPN_DEV=$1\nVPN_SRC=$4\nVPN_MSK=$5\n\nVPN_GW=$(ipcalc ${VPN_SRC}\/${VPN_MSK} | sed -n 's\/^HostMin:\\s*\\([0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\).*\/\\1\/p')\nVPN_NET=$(ipcalc ${VPN_SRC}\/${VPN_MSK} | sed -n 's\/^Network:\\s*\\([0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\.[0-9]\\{1,3\\}\\\/[0-9]\\{1,2\\}\\).*\/\\1\/p')\n\ncase \"${VPN_DEV}\" in\n \"tun0\") ROUTING_TABLE='Portugal';;\n \"tun1\") ROUTING_TABLE='Brasilien';;\n \"tun2\") ROUTING_TABLE='Singapur';;\n \"tun3\") ROUTING_TABLE='VPS';;\n \"tun8\") ROUTING_TABLE='China';;\nesac\n\n...\n\nip route add ${VPN_NET} dev ${VPN_DEV} proto static scope link src ${VPN_SRC} table ${ROUTING_TABLE}\nip route replace default dev ${VPN_DEV} via ${VPN_GW} table ${ROUTING_TABLE}<\/code><\/pre>\n\n\n\nWhen the VPN connection is stopped, then the VPN network and the default route are automatically deleted from the routing table VPS as the VPN network collapses. While the VPN connection is up, we can view the routing table<\/a> VPS with:<\/p>\n\n\n\n
caipirinha:~ # ip route list table VPS\ndefault via 192.168.20.1 dev tun3\n192.168.20.0\/24 dev tun3 proto static scope link src 192.168.20.3<\/code><\/pre>\n\n\n\nFinally, the client can be started with:<\/p>\n\n\n\n
systemctl start openvpn@client_ionos_vps.service<\/code><\/pre>\n\n\n\nOf course, the actual name after “openvpn@” in this command depends on how you named the respective client configuration file.<\/p>\n\n\n\n
Channeling the Traffic<\/h3>\n\n\n\n
Now, we must make sure that traffic that is received by Server 2<\/strong> and that shall be forwarded to Server 1<\/strong> is channeled in an appropriate way through the VPN connection. We need to execute some commands on both servers. [3<\/a>], [4<\/a>] explain how that can be achieved.<\/p>\n\n\n\n
Server 2: Forward the traffic<\/h4>\n\n\n\n
We need to enable IPv4 routing and simply forward connections to those ports where we offer our service on Server 1. This is done by:<\/p>\n\n\n\n
sysctl -w net.ipv4.ip_forward=1\n\niptables -t nat -A PREROUTING -p tcp -m multiport --dports 20,21,25,80,443,465,587,873,993,3000,4078:4088,8009,8080:8082 -j DNAT --to-destination 192.168.20.3\niptables -t nat -A PREROUTING -p udp -m multiport --dports 1194,2372:2380,4396,44576 -j DNAT --to-destination 192.168.20.3<\/code><\/pre>\n\n\n\nWe need two iptables<\/strong> commands, one for TCP connections and one for UDP connections. Both are located in the PREROUTING<\/strong> chain. As we can see, we can combine various ports and even port ranges that shall be forwarded in one command, that is very handy. Of course, you should only forward the ports that correspond to services on Server 1 that you want to offer to the world. It is also possible to offer the services on different ports on Server 2, so that http is listening on port 81 TCP rather than on 80 TCP although in my opinion, that does not make much sense.<\/p>\n\n\n\n
Let us assume that a client initiates a connection to Server 2<\/strong> on port 80 (http). The first iptables command changes the destination IP from the IP address of Server 2 (85.215.215.32<\/strong>) to the IP address 192.168.20.3<\/strong> which is the VPN client on Server 1. As we have enabled routing on Server 2, the packet is routed from ens6<\/em> to tun3<\/em> and leaves Server 2 via the VPN connection to Server 1. <\/p>\n\n\n\n
Server 1: Accept the traffic in Routing Table VPS<\/h4>\n\n\n\n
Server 1 receives the traffic and needs to channel it via routing table VPS. This is done with the command:<\/p>\n\n\n\n
ip rule add from 192.168.20.3 priority 1000 table VPS<\/code><\/pre>\n\n\n\nThe beauty of this command is that the outgoing traffic will also use table VPS and therefore leave Server 1 not via the default interface eth0<\/em> to the SoHo router, but via tun3<\/em> back to Server 2 (see [4<\/a>], [8<\/a>]). We can identify the traffic that we receive from Server 2<\/strong> at Server 1<\/strong> with the conntrack<\/em> command:<\/p>\n\n\n\n
caipirinha:~ # conntrack -L | fgrep \"192.168.20\"\ntcp 6 117 TIME_WAIT src=109.250.125.241 dst=192.168.20.3 sport=55370 dport=80 src=192.168.20.3 dst=109.250.125.241 sport=80 dport=55370 [ASSURED] mark=0 use=1\ntcp 6 117 TIME_WAIT src=109.250.125.241 dst=192.168.20.3 sport=55366 dport=80 src=192.168.20.3 dst=109.250.125.241 sport=80 dport=55366 [ASSURED] mark=0 use=1\ntcp 6 117 TIME_WAIT src=109.250.125.241 dst=192.168.20.3 sport=55368 dport=80 src=192.168.20.3 dst=109.250.125.241 sport=80 dport=55368 [ASSURED] mark=0 use=1<\/code><\/pre>\n\n\n\nIn that case, we have observed a https request (dport=80) from the source IP 109.250.125.241 which has been tunneled via our VPN from Server 2<\/strong> to Server 1<\/strong>. The client (represented by a mobile phone in the image above) has basically access Server 2 along the red arrow drawn in the image. The benefit of the concept described here is also that the source address (here: 109.250.125.241) is not concealed and therefore, filtering can be done on Server 1 with iptables as if Server 1 was accessed directly. Furthermore, the correct client IP address is in the respective log files.<\/p>\n\n\n\n
Other approaches which use SNAT<\/strong> on Server 2 would conceal the source address of the client and therefore, such filtering would have to occur on Server 2 already. The logs on Server 1 however would contain 192.168.20.1 as sole source address for all incoming connections which is why such an approach is not suitable.<\/p>\n\n\n\n
Updating the DNS Server<\/h3>\n\n\n\n
Now we should spend some thoughts on the domain name resolution of Server 1. In my case, I already had a script that communicated any change of the IP address of Server 1 provoked by the ISP almost on a daily basis to a Dynamic DNS<\/a> (DDNS) provider which so far has done the name resolution for clients that want to access Server 1. I use my own script, but most DDNS providers also offer pre-written scripts for certain architectures or routers.<\/p>\n\n\n\n
In our concept though, we must communicate the IPv6<\/strong> address of Server 1<\/strong> and the IPv4<\/strong> address of Server 2<\/strong> to our DDNS service. As Server 2 has a static IPv4 address, adapting any script should be easy. Alternatively, one could limit the script to only update the IPv6 address of Server 1 and enter the static IPv4 address via the web-based user interface of the DDNS hoster.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
This blog post shows how we can channel back traffic via a small internet-based server to a powerful server that is connected via CG-NAT and that may therefore not be accessible directly from the internet. With the approach described here, Server 1 can even be located in a mobile network or inside a firewalled environment as long as the firewall permits outgoing openvpn connections.<\/p>\n\n\n\n
Sources<\/h2>\n\n\n\n
- \n
- [1<\/a>] = Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients<\/a><\/li>\n\n\n\n
- [2<\/a>] = Setting up Dual Stack VPNs<\/a><\/li>\n\n\n\n
- [3<\/a>] = iptables – Port forwarding over OpenVpn<\/a><\/li>\n\n\n\n
- [4<\/a>] = Routing for multiple uplinks\/providers<\/a><\/li>\n\n\n\n
- [5<\/a>] = Predictable Network Interface Names<\/a><\/li>\n\n\n\n
- [6<\/a>] = vServer G\u00fcnstig Mieten \u00bb VPS ab 1\u20ac \/ M.<\/a><\/li>\n\n\n\n
- [7<\/a>] = Setting up Client VPNs, Policy Routing<\/a><\/li>\n\n\n\n
- [8<\/a>] = Two Default Gateways on One System<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
Executive Summary This blog post explains how a small internet-based shared server (“vServer”, “VPS”) can be used to tunnel connections from the internet back to a SoHo-based router that does not have a publicly routable IPv4 internet address, maybe because the internet service provider (ISP) uses Carrier-grade NAT (CG-NAT) and only offers “real” IPv4 addresses […]<\/p>\n","protected":false},"author":1,"featured_media":1511,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[109,110,111,97,101],"class_list":["post-1500","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it","tag-cg-nat","tag-ipv4","tag-ipv6","tag-openvpn","tag-policyrouting"],"_links":{"self":[{"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1500","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1500"}],"version-history":[{"count":10,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1500\/revisions"}],"predecessor-version":[{"id":1522,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1500\/revisions\/1522"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=\/wp\/v2\/media\/1511"}],"wp:attachment":[{"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1500"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1500"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/caipirinha.spdns.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1500"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- [2<\/a>] = Setting up Dual Stack VPNs<\/a><\/li>\n\n\n\n