I have a Mikrotik 2011UiAS running as the primary router for my home network.
One of the physical ports is defined as the exit node to the internet provider,
the others are bridged and connected to the devices of my local network.
I have already set up a small server, running an open-vpn client which works
well. Every connected device is able to use that tunnel while the server’s ip
is configured as the default gateway. The vpn server is a local computer
connected to the lan bridge.
Now, since one week, I am trying to configure the router as a transparent
“default gateway forwarder”. When I tell the DHCP clients to use the vpn
gateway as the default gateway, they are able - again - to use this tunnel,
but:
I want the clients to send all their requests to the router, 192.168.88.1.
And in the next step the router to forward all that packets to the local
vpn gateway, 192.168.88.100. This action should be transparent for
the clients.
At the moment, playing with src-nat and dst-nat and wireshark, the
clients are getting ICMP-Redirects from the router and then they
retransmit their packets to the vpn gateway (which they should not!):
What’s wrong with using DHCP to give VPN server as gateway to clients? It’s simple and clean way.
If you really want the traffic to go (uselessly) through router, you can disable sending of redirects:
/ip settings set send-redirects=no
And then make sure router forwards traffic to VPN server. It will, automatically, unless there’s some firewall rule(s) that would block it. It includes dropping connection-state=invalid packets in forward chain. You can’t have that, because it does not work with asymmetric routing (that’s what you’d create).
I don’t see address list LOCAL (probably a list of local addresses/subnets) and routing table OpenVPN (should contain route to 0.0.0.0/0 via 192.168.88.100), but it looks like something that should work. One more problem could be if connections from router used IP address other than 192.168.88.1 (e.g. because of some srcnat rule). Check what exactly happens. Traceroute, packet sniffer (Tools->Torch), …
By using the tools/torch utility I found out that the packets are sent to the local vpn gateway BUT these packets
from the router have its public source ip address. So the gateway receives the packets and there are also packets
coming back but these are addressed to the public ip address from port ETH1. Thats means they cannot be
forwarded from the vpn gateway to the router.
It looks like the public address is chosen as source before you tell it to use different route. I guess it makes sense, it has to choose some address and based on the destination, the public one would be right choice, because it would normally use the main default route. It can’t know that you’ll later send it somewhere else.
You can add another masquerade rule for out-interface= dst-address=!192.168.88.0/24 and it should do the trick. Just in case it does not, replace masquerade with src-nat and to-addresses=192.168.88.1.
I’m wondering myself if there’s better solution. If your public address is static, you can use src-nat with this specific address instead of masquerade and then set pref-src=192.168.88.1 for main default route and I think it will work. I’d like something even better, but I don’t see anything. It would have to be some kind of pre-output processing or something.
