Community discussions

 
mario01
just joined
Topic Author
Posts: 1
Joined: Sat Nov 09, 2019 5:25 pm

Access internal webserver over site2site-VPN tunnel

Sat Nov 09, 2019 7:23 pm

Hi,

I am working for hours on this problem and dont find a solution. I hope anybody can help.

I have multible sites with dynamic IPs (mikrotik routers), all connected to a central VPN-Server with a static IP (mikrotik chr on vps l2tp and ipsec combined). This solution works.
Every site connects directly to the internet for internet access. Only vpn traffic for access private lans runs over the vpn-tunnel.

My webserver runs on a virtual machine on site A in a private subnet. Now I want to access my website on this server over the static IP on my central site (VPS).
Important ist to use the static ip of the VPS. The traffic should run through the vpn tunnel or outside via nat from central site to the dynamic ip of site a. Both ways are possible.

NAT the traffic from static ip to dynamic ip is not really possible, because I can only use a static ip as destination.

I tried dst-nat from static IP central site to destination ip, but this doesnt work, because of the default route for public ips is the direkt Link of SiteA zu the internet.
I tried dst-nat from static IP with masquerade to the IP address of siteA l2tp tunnel and than dst-nat from IP siteA l2tp to the internal IP of the webserver, but it doesnd work.

Any ideas for me. In the attachment you can see the structure. Thanks

Mario
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 3906
Joined: Mon Dec 04, 2017 9:19 pm

Re: Access internal webserver over site2site-VPN tunnel

Sun Nov 10, 2019 2:37 pm

It is true that you can forward connection-establishing packets from clients in the internet, which come the static public IP of the CHR, a) to the current public IP of the router in front of your web server (so outside the tunnel) or b) to the server's private address (so inside the tunnel). But you also have to ensure that the responses to the clients will arrive from the public IP of the CHR, and this is impossible to achieve in case a).

The point is that the TCP session is identified by the quadruple of (client-side IP, client-side port, server-side IP, server-side port) and if the client receives the response from a different IP:port than to which it has sent the request, it will not recognize it as a response to the request and will drop it, and so will do any firewalls between the client and the internet. And in case a), the request from client will be redirected to the current public IP of the router in front of the server, but you cannot route the response through the CHR outside the tunnel without losing the actual address of the client (which is the destination address in the response packet, so once you rewrite it by CHR's address to force the packet through the CHR, the CHR has no way to restore it). And as more data is likely to flow from the server to the client, there is no point in routing the client requests outside the tunnel.

So it only makes sense to deal with case b). Your existing routing on the CHR knows the route to server's private address via the tunnel, so a dst-nat rule from CHR's public IP to the server's private one (and the firewall filter allowing the dst-nated packet to be forwarded) are all you need on the CHR.

On the server's router, however, you need to make sure that responses to connection requests coming via the VPN tunnel will be routed through the tunnel although the default route is through the regular WAN. This can only be achieved using connection-based policy routing which is explained in this post; start reading it from the last paragraph which will explain the link to your case. If it is not clear from there, komm zurück ;)

If you can afford to dedicate a local interface and a dedicated VPN tunnel for the access to the server from the internet, you can also replace the above approach by a VRF setup, where the dedicated VPN tunnel and the local interface dedicated for the server would share a common routing instance (a vrf-assigned routing-mark). In fact this approach may turn out equally complex as the above as soon as you start thinking about management access to the server, but the advantage of this approach is that you can use fasttracking on the server's router, so if it's throughput becomes the bottleneck, take this way.

EDIT: of course you can also simply src-nat the packets from the clients to the server at the CHR to force the responses back through the CHR, but this would mean that the server would see all client's connections as coming from the CHR itself which most people want to avoid, so I neglected this approach.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 97 guests