Forward Traffic from Public IP to Wireguard client behind NAT and Preserve IP

Wiregurad allows us to create virtual network interfaces between nodes that are in separate networks. This feature can be used to expose a server behind NAT with a Public IP address.

The main advantage of the method described in this post is that it preserves clients IP address, so the home server sees the real IP address of clients and can process them (e.g. block them in a firewall).

There are several posts on the internet on this topic however they are not complete, for example the method described in this post does not preserve IP address of clients and shows the wireguard server's IP address in requests instead.

I had an asterisk server at home on raspberry pi, and wanted to make it accessible via internet however the internet solution that was used there did not provide a public IP address. It's possible to create a SSH tunnel and forward ports using a VPS in a datacenter however  it would not preserve clients IP address. I wanted to see the real address of clients so that fail2ban can block bruteforce attacks against the asterisk server.

Steps:

VPS Server:
1. Enable net.ipv4.ip_forward on the VPS

2. Wireguard config on the VPS server is simple and does not have anything special:

[Interface]
Address = 10.0.1.1
ListenPort = <Wireguard Listen Port>
PrivateKey = <Wireguard VPS Server Private Key>

# Home
[Peer]
PublicKey = <Wireguard on Home server Public Key>
AllowedIPs = 10.0.1.2/32

where 10.0.1.1 is the local IP address of wireguard on VPS server and 10.0.1.2 is the local IP address of wireguard on Home server behind NAT.

3. Now, to forward Traffic to the VPS server, you need to use the following rules in IP tables : 

# To allow Forwarding IPs in IPtables: 

iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT

iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT

# This rule can be used if it is not needed tp preserve clients IP

# iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

# This rule is needed to provide internet to Home server when preserving clients IP

iptables -t nat -A POSTROUTING -s '10.0.1.0/24' -o eth0 -j MASQUERADE

# Forward TCP / UDP ports here to the server home

# TCP Public:8080 -> Home:443

iptables -t nat -A PREROUTING -p tcp -d VPS.Public.IP.Address --dport 8080 -j DNAT --to-destination 10.0.1.2:443

# TCP Public:8822 -> Home:22

iptables -t nat -A PREROUTING -p tcp -d VPS.Public.IP.Address --dport 8822 -j DNAT --to-destination 10.0.1.2:22

# UDP Public:5060 -> Home:5060

iptables -t nat -A PREROUTING -p udp -d VPS.Public.IP.Address --dport 5060 -j DNAT --to-destination 10.0.1.2:5060

# UDP Range Public:11000-11200 -> Home:11000-11200

iptables -t nat -A PREROUTING -p udp -d VPS.Public.IP.Address --dport 11000:11200 -j DNAT --to-destination 10.0.1.2:11000-11200

Home server in NAT: 

Wireguard config on the Home server is a bit more tricky. 

[Interface]
PrivateKey = <Wireguard on Home server Private Key>
Address = 10.0.1.2

[Peer]
PublicKey = <Wireguard VPS Server Public Key>

# This rule will not preserve clients IP 
# AllowedIPs = 10.0.1.1/24
# This rule will preserve clients IP:
# This is a Sample range, you need to use the script provided below to 
# exclude you VPS IP / Local NAT IP from 0.0.0.0/0 range, then use it here
AllowedIPs = 128.0.0.0/1, 64.0.0.0/2, 32.0.0.0/3, 16.0.0.0/4, 0.0.0.0/5, 12.0.0.0/6, 10.0.0.0/7, 9.0.0.0/8, 8.128.0.0/9, 8.64.0.0/10, 8.32.0.0/11, 8.16.0.0/12, 8.0.0.0/13, 8.12.0.0/14, 8.10.0.0/15, 8.9.0.0/16, 8.8.128.0/17, 8.8.64.0/18, 8.8.32.0/19, 8.8.16.0/20, 8.8.0.0/21, 8.8.12.0/22, 8.8.10.0/23, 8.8.9.0/24, 8.8.8.128/25, 8.8.8.64/26, 8.8.8.32/27, 8.8.8.16/28, 8.8.8.0/29, 8.8.8.12/30, 8.8.8.10/31, 8.8.8.9/32
Endpoint = <VPS PUBLIC IP>:<Wireguard Listen Port>
PersistentKeepalive = 25 

AllowedIPs is the tricky part here. 

One can use AllowedIPs = 10.0.1.1/24 here with iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE  rule in iptables of the VPS, this will let the home server to be accessible through the forwarded ports, however the home server will not see the real IP address of clients, and will  see all requests coming from 10.0.1.1, the IP address of wireguard VPS instead.

To let the home server accessible through the Public IP address of VPS and make it see the real IP address of clients, it is required to route packets that arrive to server home to come back through wireguard. So basically we need to add all IP ranges to AllowedIPs Except VPS IP address and other local network addresses that we dont want to go through wireguard.

It is not possible to use AllowedIPs = 0.0.0.0/0 directly, as wireguard will not be able to connect to our VPS IP address then. We also don't want our Local NAT IP range to go through Wireguard.  So we use the following Shell script to exclude our VPS IP/Local IP range from 0.0.0.0/0 range :

#!/bin/bash
echo "enter the broader range e.g. 176.0.0.0/4"
read r1
echo "enter the exclude ip e.g. 18.20.18.8/32"
read r2
pshell=`cat <<EOF
import ipaddress
n1 = ipaddress.ip_network('$r1')
n2 = ipaddress.ip_network('$r2')
l = list(n1.address_exclude(n2))
print(l)`

python3 -c "$pshell" | sed -e "s,IPv4Network(',,g" | sed -e "s,'),,g" | sed -e "s,\[,,g" | sed -e "s,\],,g"

It requires ipaddress python3 package to work.

VoIP / SIP Settings on different versions of Android

Android phones come with a native VoIP client that works great. The settings are placed in different paths though, in this post I'll list the path to the setting on different versions of Android:

Android 4.2.2 (Jelly Bean) - (Huawei Y330):
Dialer App -> Settings -> Internet Call

Android 5.0 (Lollipop) -  Asus Fonepad 7 FE171CG:
Settings -> Call Settings -> Phone account settings

Android 5.1.1 ((Lollipop)  - Huawei Redmi 3:
Phone App -> Settings -> Advanced Settings -> SIP Settings

Android 9 (Pie) - Mi A3 / A1:
Phone App -> Settings -> Calling Accounts

How to configure VoIP on GreenPacket DT-350

آموزش راه اندازی تلفن اینترنتی VoIP بر روی مودم TD-LTE DT-350 ایرانسل

Irancell TD-LTE TD-350 modem offers a hardware VoIP client and one can connect a phone to the RJ45 port on the modem to use this feature. However, VoIP settings are disabled by default and it is not possible to enable it using the admin user since this user is an Enduser and not a Superuser.

 

Thanks to this post, it is possible to find the superuser defined for Greenpacket modems. Irancell has set the username for superuser on its modems to administrator and the password is also administrator: 

User: administrator

Pass: administrator

This user has privileges to manage many more settings including VoIP settings :

And Voila! It works pretty well!

Lantronix KVM Java error FIX: Use Latronix native client instead

Latronix KVM provides HTML5 console however its not possible to mount images there so you would need to set to Java console. I was getting the following error each time I tried to run their Java console:

"unsigned application requesting unrestricted access to system"

I tested Java 1.8, 1.7, 1.6, 1.5 and 1.4 and all failed to run spider.jnlp file of Latronix KVM and returned the above error. There was a fix suggested to run it using Java however it did not work for me either.

I managed to mount ISO image to the VM by using Latronix KVM client software SpiderView which can be downloaded on their website.

How install Xfce4 and RealVNC on Centos 7

Xfce is a lightweight desktop environment and it's a good choice as a GUI for servers running Centos 7 . It can be installed by using the following command :

yum groupinstall "Xfce" -y

However Xfce does not start properly with RealVNC on Centos 7. The following commands are needed to fix the problem according to RealVNC website :

Create a file called /etc/vnc/xstartup.custom and make it executable (chmod +x) with the following content :

#!/bin/sh
DESKTOP_SESSION=xfce
export DESKTOP_SESSION
startxfce4
vncserver-virtual -kill $DISPLAY


Create another file called /etc/vnc/config.custom and add the following commands :

-extension RENDER


and finally use this guide to fix "xfce GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: User of caller and user of subject differs." error on xfce startup.

How to Proxy SSL IMAP/POP3/SMTP using HAProxy and Dovecot+Postfix

This post shows how to configure a mail proxy server to connect clients in an intranet to an external mail server. I will use SSL offloading method since the mail proxy server is owned by the same company that's running the main mail server therefore decrypting the data on the proxy server and encrypting them again is not a security concern.

HAProxy - Dovecot configuration

I use HAProxy on the VPS Proxy server to proxy SSL IMAP/POP3/SMTP protocols to the main mail server. The main server is using Dovecot/Postfix to run email service.

First, install HAProxy on the VPS proxy server, generate a valid SSL for its hostname and configure haproxy to proxy IMAP/POP3/SMTP SSL ports to the main mail server :

listen main-pop3
  bind :995 ssl crt /etc/letsencrypt/live/HOSTNAME/fullchainkey.pem no-sslv3
  mode tcp
  balance first
  stick store-request src
  stick-table type ip size 200k expire 15m
  server s1 MAINHOST.FQDN:10110 send-proxy-v2 ssl verify required ca-file ca-certificates.crt

listen main-imap
  bind :993 ssl crt /etc/letsencrypt/live/HOSTNAME/fullchainkey.pem no-sslv3
  mode tcp
  balance first
  stick store-request src
  stick-table type ip size 200k expire 15m
  server s1 MAINHOST.FQDN:10143 send-proxy-v2 ssl verify required ca-file ca-certificates.crt

listen main-smtp
  bind :465 ssl crt /etc/letsencrypt/live/HOSTNAME/fullchainkey.pem no-sslv3
  mode tcp
  stick store-request src
  stick-table type ip size 200k expire 15m
  server s1 MAINHOST.FQDN:10465 send-proxy-v2 ssl verify required ca-file ca-certificates.crt

/etc/letsencrypt/live/HOSTNAME/fullchainkey.pem is a valid certificate generated for the VPS Proxy hostname and it should contain both private key and certificate.

MAINHOST.FQDN is the full hostname of the main mail server, and haproxy is connecting to it securely (send-proxy-v2 ssl) and verifying its SSL against ca-certificates.crt file.

Now, on the main mail server side, we need to configure dovecot to listed on the custom ports for haproxy (10110, 10143, 10465) . Dovecot added support for haproxy since version 2.2.19. We open separate ports for haproxy and enable haproxy in the listeners which will allow dovecot to get the correct data of clients from haproxy server. Add the following code to /etc/dovecot/conf.d/haproxy.conf on the main mail server:

haproxy_trusted_networks = VPS.PROXY.IP/32

service pop3-login {

   inet_listener pop3_haproxy {

     port = 10110

     haproxy = yes

     ssl = yes

   }

}

service imap-login {

  inet_listener imap_haproxy {

    port = 10143

    haproxy = yes

    ssl = yes

  }

}

service submission-login {

  inet_listener submission {

    port = 10465

    haproxy = yes

    ssl = yes

  }

}

submission_relay_host = localhost

submission_relay_port = 25

submission_relay_trusted = yes
submission_client_workarounds = whitespace-before-path

Note that we are not sending queries from haproxy directly to postfix, instead we use submission listener of dovecot to authenticate clients in a similar way as imap/pop3 protocols. To enable submission service, you need to add submission in the list of protocols in dovecot.conf file : 

protocols = imap pop3 submission

Dovecot receives emails on port 10465 from haproxy, authenticate clients using its configured settings, and then send them to submission_relay_host which is postfix in this case. Postfix is running on the same machine as dovecot on port 25. We need to configure postfix to accept XCLIENT data that dovecot sends to it. (Xclient contains data of client that haproxy sends to dovecot). We set dovecot to send the real data of client to postfix by setting submission_relay_trusted = yes in its config file. We also need to set postfix to accept this data from dovecot by adding the following line to /etc/postfix/main.cf file : 

smtpd_authorized_xclient_hosts = 127.0.0.1

Now, clients in a restricted network can connect securely to the VPS proxy server. This Proxy server receives data from clients and sends them securely to the main mail server.

The line submission_client_workarounds = whitespace-before-path is required in configuration of dovecot submission for Microsoft outlook to work properly. I was getting the following error in Microsoft outlook 2016 before setting this variable :

Sending reported error (0x800CCC78): Cannot send the message. Verify the e-mail address in your account properties. The server responded: 501 5.5.4 Invalid FROM: Unexpected whitespace before path

Postfix smtp_fallback_relay and HAProxy smtp relay in action

It's possible to use HAProxy to add a SMTP relay for a domain mail service which can be used to add a secondary mx record for a domain name to enable its clients in a restricted network reach the mail server :

Clients in a restricted network -> HA Proxy VPS (second priority mx record) -> Main server

HAProxy - Postfix configuration

You'll need to get a VPS with internet access in the restricted network and install HAProxy on it. Then configure HAProxy on the vps to forward SMTP port 25 to the main server : 

frontend ft_smtp

  bind 0.0.0.0:25

  mode tcp

  timeout client 1m

  log global

  option tcplog

  default_backend bk_postfix

backend bk_postfix

  mode tcp

  log global

  option tcplog

  timeout server 1m

  timeout connect 5s

  server postfix YOUR_MAIN_IP_ADDRESS:2525 send-proxy

Now on the postfix of the main server edit the main.cf and set the upstream proxy for postscreen to haproxy: 

postscreen_upstream_proxy_protocol = haproxy

and finally enable smtpd and postscreen in master.cf :

2525    inet  n       -       n       -       1       postscreen

smtpd     pass  -       -       n       -       -       smtpd

One can add a new mx record with a lower priority to the domain with the IP address of the HAProxy server so that clients that aren't able to reach the main mail server can access it through the HAProxy server.

But how can these clients receive emails from the main mail server? Postfix on the main server can't reach these clients directly, so one can use smtp_fallback_relay feature in postfix to reach them through the same VPS that's running HAProxy.

To do so add the IP address of the vps that's running HAProxy as a SMTP Fallback relay to the main.cf file of the main mail server : 

fallback_relay = [YOUR_VPS_FQDN]:5870

You'll need to also add the IP address of your VPS to the SPF records of the main domain.

Now on the vps server, install postfix and set it to run as a relay. Add the IP address of the main mail server to mynetworks in main.cf file of the vps, to allow it to use this vps as a relay mail server. 

 Ensure that the hostname of the vps matches with the PTR record of YOUR_VPS_IP_ADDRESS and the value in /etc/mailname of the vps.

Edit the master.cf file of the postfix on the vps server and add the port you set in fallback_relay there : 

5870    inet  n       -       y       -       -       smtpd

That's it. With this configuration, clients first try to reach the main mx records and they try the second mx record if the first one was inaccessible. Also the server tries to reach mail servers directly and it tries the relay smtp server if they were unreachable.