Hi,
I had to solve a problem on a site where the only WAN access is done throught a LTE connection.
I don’t know if this is the case everywhere, but my provider puts me behind a router with a private IP so I cannot have any incoming connection.
However, I have an HTTP server on this site and I have to provide an access to it from Internet.
I’ve configured a VPN connection from the Mikrotik router to a Linux server on another site with a fiber Internet access, and set up some iptables rules (PREROUTING and POSTROUTING) on that Linux server to redirect the required streams throught the VPN connection.
On the RouterOS side, I’ve created a NAT rule to forward the packets to the HTTP server (all ports are forwarded: I might add other services in the future).
/ip firewall nat
add action=dst-nat chain=dstnat in-interface=ovpn-sw1 protocol=tcp \
to-addresses=192.168.0.136
But this is not enough: the packets coming from the VPN to the HTTP server still have the original source IP, so when the HTTP server replies the packet is routed to the WAN/LTE interface.
The only solution I managed to get working was to add a routing mark on the packets coming from port 80 of the HTTP server and to add a static route for these packets.
/ip firewall mangle
add action=mark-routing chain=prerouting log-prefix=SW1 new-routing-mark=go_SW1 passthrough=no protocol=tcp src-address=192.168.0.136 src-port=80
/ip route
add distance=1 gateway=ovpn-sw1 routing-mark=go_SW1
This is working well, however I’m not really satisfied about this solution because all the packets coming from port 80 of the HTTP server are routed to the VPN, regardless of the real origin of the request.
So my question is: Is there any way to configure some kind of ‘masquerade’ on the packets coming from the VPN?
The idea would be to replace the source IP of the rx packets with the IP of the Linux server side of the VPN, and to revert back to the original IP as the destination of the tx packets.
Please forgive me if my question exposes a misconception of how a router works, I have to admit that I am not a network specialist.