1

Goal: To replicate the functionality I have with StrongVPN on my own Debian VPS. With StrongVPN, seemingly, all ports on the public IP provided are forwarded to the client, meaning, e.g, ssh :22 from 'outside' connects to my router. Also upnp / NATPMP etc on my router's clients Just Work (skype, back to my mac). The caveat is that the server will need to 'keep' receiving traffic on certain ports (22, 80, etc) to maintain functionality, so these will need 'notched' out of any forwarding set up via IPtables.

Server: I have a VPS, latest Debian running OpenVPN and bind9. I have one NIC and one public IP. This server also runs apache, and I'll need access to it via ssh for configuration.

Client: a router running OpenWRT. I have this set up to use StrongVPN currently. I want to move to using my own VPS.

Required: help with generating a suitable set of rules for iptables.

I have a basic, working OpenVPN config established as below as well as the beginnings of the iptable rules.

client.conf:

remote 46.aaa.xxx.yyy 1194 udp
dev tun
ifconfig 172.19.233.2 172.19.233.1
secret static.key
redirect-gateway def1

server.conf:

dev tun
proto udp
port 1194
ifconfig 172.19.233.1 172.19.233.2
secret /etc/openvpn/static.key

ifconfig:

eth0      Link encap:Ethernet  HWaddr 52:XXXXXXXXXXXX
          inet addr:46.aaa.xxx.yyy  Bcast:46.aaa.xxx.xxx  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34338527 errors:0 dropped:20 overruns:0 frame:0
          TX packets:747507 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2697230329 (2.5 GiB)  TX bytes:577951758 (551.1 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:18947 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18947 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2143690 (2.0 MiB)  TX bytes:2143690 (2.0 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.19.233.1  P-t-P:172.19.233.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:164495 errors:0 dropped:0 overruns:0 frame:0
          TX packets:166083 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:54062402 (51.5 MiB)  TX bytes:162532235 (155.0 MiB)

iptables-save:

# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*nat
:PREROUTING ACCEPT [2:344]
:INPUT ACCEPT [1:172]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING ! -d 172.19.233.0/24 -s 172.19.233.0/24 -j MASQUERADE
COMMIT
# Completed on Mon Mar 30 21:47:41 2015
# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*raw
:PREROUTING ACCEPT [413:36237]
:OUTPUT ACCEPT [190:21548]
COMMIT
# Completed on Mon Mar 30 21:47:41 2015
# Generated by iptables-save v1.4.14 on Mon Mar 30 21:47:41 2015
*filter
:INPUT DROP [5239:662523]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [11365:1381174]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22,53,80,123,443,1194 -j ACCEPT
-A INPUT -p udp -m multiport --dports 53,123,1194 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A OUTPUT -o eth+ -j ACCEPT
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Mon Mar 30 21:47:41 2015

Update Instead of Masquerading, the following line helps with traffic out of the VPN to the internet:

iptables -t nat -A POSTROUTING ! -d 172.19.233.0/24 -j SNAT --to-source 46.aaa.xxx.yyy 

To get traffic to flow from the internet to the VPN client the below seems to work:

iptables -t nat -A PREROUTING -p tcp -m multiport ! --dports 22,53,80,123,443,1194 -j DNAT --to-destination 172.19.233.2
iptables -t nat -A PREROUTING -p udp -m multiport ! --dports 53,123,1194 -j DNAT --to-destination 172.19.233.2 

These lines mirror the ports accepted on INPUT in the filter table. Then changing the VPN client to listen on alternate ports for ssh / http etc means traffic to, e.g., 46.aaa.xxx.yyy:2222 passes through to the client.

But I'm not sure this is suitable for services such as Skype / BTMM that required certain ports open.

0
0

What you have looks fine. To make it more readable and maintainable I would create a chain for the DNAT to your client. It creates more rules, but it's a lot easier to read and add/remove/change ports in the future.

iptables -t nat -N DNAT_NET2VPN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 22 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 53 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 80 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 123 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 443 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p tcp --dport 1194 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p udp --dport 53 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p udp --dport 123 -j RETURN
iptables -t nat -A DNAT_NET2VPN -p udp --dport 1194 -j RETURN
iptables -t nat -A DNAT_NET2VPN -j DNAT --to-destination 172.19.233.2 
iptables -t nat -I PREROUTING -i eth0 -d 46.aaa.xxx.yyyy -j DNAT_NET2VPN

Ideally you would get a second IP from your hosting provider to use as the public source/destination for your VPN traffic, but with only 1 IP you're limited to splitting the port range like this.

1
  • Thanks - I'll try your suggested way of writing them. I think I have it working as required.
    – Tristan
    Apr 11 '15 at 9:16
0

The 3 rules required are:

iptables -t nat -A POSTROUTING -o eth0 -s 172.19.233.0/24 -j SNAT --to-source 46.aaa.xxx.bbb
iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport ! --dports 22,53,80,123,443,1194 -j DNAT --to-destination 172.19.233.2
iptables -t nat -A PREROUTING -i eth0 -p udp -m multiport ! --dports 53,123,1194 -j DNAT --to-destination 172.19.233.2 

The 1st rule is the main SNAT rule to change the source ip to that of the public IP.

The 2nd and 3rd rules notch out all the ports listed and prevent them being forwarded down the tunnel.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.