Dedicated IP 'Server' using VPN

Long time listener, first time caller.

Background:
I have been blessed with an ISP that has a NAT across all of its products. This is probably an issue shared by many.
Anywho, I have decided to signup for a VPN service with a dedicated IP that, in theory, allows me to forward certain ports through the VPN - using OpenVPN.

The aim is to have a 'server' host a service locally which is accessible from the interwebs. The ports are irrelevant in this case as I have a hardened machine waiting to accept the transactions from the VPN. But ideally, I would like to close all but the ports that need.

I have the VPN up and running. I have MWAN3 working across two WAN 'modems' and the VPN seems to lay over 'WAN1'. I can ping across it, I can even set up a policy in MWAN3 to route certain traffic across the VPN and go via WAN1 or WAN 2 for the remainder.

What I am struggling with:
I can't seem to direct the VPN to the hardened machine. I have tried port forwarding and firewall zones and I can't seem to do what 'normally' can be done to route traffic from the internet to a single machine.

My questions:

  • given that the VPN is established at the router on the inside of the MWAN3 policy routing, how would port forwarding or routing be achieved to route traffic to the hardened machine?
  • does MWAN3 complicate the equation for inbound traffic and is it better to remove it from the equation?
  • is it even possible to route traffic through a VPN that is acting as an entry point somewhere out on the internet and direct it to a single machine using OpenWRT?
  • has anyone any material I can read that gets me to understand how to manipulate the VPN on this side of MWAN3 and how it could work with the tools built into OpenWRT given the 3d nature of the application?

LuCI openwrt-19.07 branch (git-21.238.28320-53f59d3)
OpenWrt 19.07.3 r11063-85e04e9f4
OpenVPn 2.4.11-1

I think you should disable and stop mwan3 at least temporarily for testing.
Not sure about commercial VPN providers, but it works if you use own VPN server on a VPS.

2 Likes

OpenWrt router should have a route to reach the server. If the packets from the tunnel use the IP of the server as destination, then you only need to allow that on the firewall. If the packets use destination address of OpenWrt, then a port forwarding is needed.

As mentioned earlier by vgaetera, it's better to disable it for as long as you test.

I am not sure I understand exactly the question.

This is very generic. Maybe you could give an example of what you are trying to achieve followed by the configuration that you have in place to be able to troubleshoot what goes wrong.

2 Likes

If I understood correctly you want to forward traffic from openvpn server to openvpn client. In order to establish that a ccd directory line needs to be added along with route to your local network via vpn_gateway and in the ccd directory you will need a client file with iroute statement for the client where you want the trafic to be forwarded. After you can establish the connection - with ICMP packets to your internal network, you can forward the ports you wish.

The client can perform masquerading and DNAT.
So, you don't need to directly access the LAN behind it.

Ok, so to take MWAN3 out of the mix and to make things a little easier for me and all, I have run up three VMs:

  1. An OpenWRT router with OpenVPN with the VPN connecting to VPN provider (with the dedicated IP);
    a) this has 3 interfaces: eth0 is a management interface (a feature of the image from OpenWRT), eth1 is 'WAN' and eth2 is the LAN interface.
    b) the WAN interface is bound to the physical network adapter of the PC and can 'see' the internet (and connect to the VPN).
    c) the LAN interface is a internal network of the VM software.
  2. A debian server with ports open - let's just say 993 (IMAP).
    a) this is connected to the LAN interface.
  3. A windows box connected to the LAN interface for me to configure the OpenWRT box and test things as needed.

Like I said in my previous post, I have VPN provider that has setup a 'wormhole' out on the interwebs that routes certain ports down the VPN to (hopefully) my router. The goal is to ensure the traffic meets the debian server on the LAN interface.

I haven't set anything more complex than:

  1. OpenVPN connection;
  2. An interface for the vpn (tun0) "ovpn_fw" => "lan" (Accept, Accept, Accept) w/ Masquerading
    a) Covered networks: "tun0)
    b) Allow forward to destination zones: "lan"
    c) Allow forward to from source zones: "lan"
  3. An interface "lan" => "wan" and "ovpn_fw" (Accept, Accept, Accept) w/ Masquerading;
  4. Port forwarding from both "wan" and "ovpn_fw" to "lan" and a specific IP (debian server above);

I am able to browse the internet from the windows box and update the debian from the debian mirror and wget files as needed - so a connection to the internet is fine and shows up as the dedicated IP address of the VPN (and not my modem's). I can even connect to several ports outbound (25, 465, 993, etc.).

I hope this give a little more context.

If you already see the forwarded traffic on your router, then it should reduced to a firewall configuration.

In an explicit setup where you have full VPN server access, this is what a typical configuration looks like.
This way, openvpn (the server), knows what client to route a subnet/host to. It will update the routing table on the server.

# server.conf
route 192.168.0.0 255.255.255.0
# (server ccd/client-name)
iroute 192.168.0.0 255.255.255.0

Where 192.168.0.0/24 is your LAN subnet (where your debian server would be).

Just did a tcpdump across tun0 and it appears that packets aren't coming through ports I need on the VPN. There are packets coming through, but they are not the ones I was told would be forwarded down the VPN.

I have escalated it to the VPN provider and left tcpdump running for them to throw a few test packets to the ports.

Thanks all for your help and thanks laingo for the comment "If you are already see the forwarded traffic" as it got me thinking if it's a routing issue at all.

Turns out that it was the VPN provider they "made some modifications" and it worked perfectly.

Now I have a solution for hosting services through a VPN when my ISP has a NAT in place. :slight_smile:

Again, thanks all for your input. It's been very helpful to keep heading in the right direction.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.