I think I solved it with your src-nat suggestion, not needing another route at all..
I made an address list with the three RFC1918 ranges,
Added a mangle rule to mark connections new connections not from the RFC1918 list
Added a src-nat rule at the top for the marked connections with a src-nat action to the IP I wanted.
Working on both routers, I think I’ll have to remember it on the edge-router to switch between cable and DSL.
Need to tweak the edge router to use the DHCP client IP, rather than the statically set one, masquerade perhaps, but I need to lookup how to enter it to use the correct interface.
Well, in this case, if adding the default route is permitted for the /interface l2tp-client, the behaviour above makes a perfect sense - the default gateway becomes the L2TP interface as soon as the L2TP tunnel gets up, the DDNS client finds the local address matching the default route’s gateway interface (the L2TP one) and sends an update request to the DDNS server via that gateway. As the VPN server does not assign the public IP to the Mikrotik end of the tunnel (as some other VPN servers do) but instead assigns a private IP to it an performs a src-nat to its own public address before routing the packet to the internet, it doesn’t matter what the Mikrotik sets as source address in the packet because the VPN server always overwrites that with its own public address.
Correct, but if it did as it was told and use the ether1’s DHCP as the source and ether1 as the outgoing interface, all would good.
Incoming traffic from the internet to the edge router, will connect and work. If it was following the route list, it wouldn’t work. (Why I set classless for the DHCP aquired route). I only needed to add the VPN server IP to the routing table for the DSL connection.
I will play with this more this evening.
Because I can have incoming connections to the DHCP IP on ether1, I want to use a monitoring service to monitor the VPN IPs and the DHCP IP to track outages. Determine which is failing during an outage. Use the Cloud DDNS client to update the IP.
But then it is a routing issue, not source address choice issue.
You may have missed that route choice is always the first thing the machine does, the source address choice only comes next. So you cannot say “use this source address” and expect that the machine will choose a route among those which have that address set as pref-src. So it is your routes’ configuration what must guarantee that the gateway provided by dhcp-client on ether1 will always be used for the DDNS update. I don’t know the purpose of the VPN tunnel, but if it is not intended to replace the default gateway whenever it comes up, either tell it not to add its own default route at all or at least tell it to add it with distance parameter value higher than the one provided by the ether1 dhcp-client’s default route so it will only be used if ether1 goes down.
Creating a dedicated route to the DDNS server may be a more complex task as it seems it can change from time to time.
Can of worms might be the right description.. haha
The VPN tunnel provides the static blocks for my primary router. I set classless and then the distance higher on the DHCP client so it has a route to the VPN server and then the VPN default route takes over..
You may have missed that route choice is always the first thing the machine does, the source address choice only comes next. So you cannot say “use this source address” and expect that the machine will choose a route among those which have that address set as pref-src.
What I really don’t understand is how incoming traffic to the DHCP IP ‘works’ when the active default route is the VPN. Plus if I change the source-IP, it does take the different route, so it isn’t just based on the routes.
Can of worms might be the right description.. haha
The VPN tunnel provides the static blocks for my primary router. I set classless and then the distance higher on the DHCP client so it has a route to the VPN server and then the VPN default route takes over..
This is exactly what I am doing with fetch is it not?
What I really don’t understand is how incoming traffic to the DHCP IP ‘works’ when the active default route is the VPN. Plus if I change the source-IP, it does take the different route, so it isn’t just based on the routes.
Of course it has rules, but it would be a lot easier if I knew what these rules were and why they only seem to be followed sometimes and not others.
I still can not figure out why I can establish connections to the DHCP provided IP from the wild internet when the default route is over the VPN connection. If I am following everything correctly, the responses should be sent over the VPN, dropping the connection. I thought I was decent at networking stuff, just the different brand configurations/implementations being the issue, but I am seriously at a loss on this one.
@CZFan, I’m afraid that responding from the same local IP address to which the request came (which definitely works) and choosing for the response the backward route via the same interface through which the request came in (which should not work automatically) are two different things.
@kevinds, can you post the result of /ip route print detail taken while the L2TP tunnel is up, of course after sanitizing it? I suspect that the system chooses from several routes with equal distance in a round-robin fashion so it sometimes works and sometimes doesn’t.
My bad Kevinds, I didnt realize it was not a real VPN LOL. The kind where you control both ends of the stick. Relying on a “retail” operation from another source may not be the best approach as you have no control over how they manipulate their infrastructure on a day to day basis. I am also not sure if third party vendors can be trusted with your top secret information .
In any case, a network discussion way above my pay grade.
I tried, but finding the right combination of network performance (latency and jitter), larger static IP blocks, transfer allowance, and affordability was a challenge. I had a dedicated server in LA for a bit that met most of the requirements except the jitter was unacceptable and made VoIP unusable…
The VPN isn’t for anonymity, it is for the static IP blocks… I’m open to other providers.
.