Community discussions

MikroTik App
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Oct 15, 2023 8:04 pm

Hi all,
I am sturgling with my setup which is as follows: I have 2 ISPs and both of them gave me home routers that are locked on 192.168.1.1

I want to implement some simple failover between my two ISPs (Orange and Starlink) using my Mikrotik. I though this would be as simple as putting the 2 routers in two different VRFs and let my Mikrotik router do the routing and NATing.
( LAN - 192.168.2.0/24 )---(ether3/4/5)---MK --(ether1)---- (VRF-ORANGE - 192.168.1.0/24 gw 192.168.1.1)
                                           |
                                            ---(ether2)-----(VRF-STARLINK - 192.168.1.0/24 gw 192.168.1.1)
Unfortunately the routing seems to works OK but the packets from the LAN to the VRFs are not NATed. Using the packet sniffing I can see packets in the VRF with the IPs from the LAN.

Here is my config (note I'm trying to have the vrf-orange working so most of the configuration for the other vrf is missing or disabled):

The IP of the Mikrotik in the LAN is 192.168.2.211, in the vrf-orange it's 192.168.1.211 and in the vrf-starlink it is 192.168.1.212
/ip vrf
add comment="vrf vers starlink" interfaces=ether2 name=vrf-starlink
add comment="vrf vers livebox" interfaces=ether1 name=vrf-orange

/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf disabled=yes interface=sfp1
add bridge=bridge disabled=yes interface=ether1
add bridge=bridge disabled=yes interface=ether2

/interface list member
add comment=defconf interface=bridge list=LAN
add interface=sfp1 list=WAN
add interface=ether1 list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN

/ip address
add address=192.168.1.211/24 comment=orange interface=ether1 network=192.168.1.0
add address=192.168.1.212/24 comment=starlink disabled=yes interface=ether2 network=192.168.1.0
add address=192.168.2.211/24 comment=bridge interface=bridge network=192.168.2.0

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-nat-state="" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN


/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf-orange pref-src="" routing-table=main suppress-hw-offload=no
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf-orange pref-src="" routing-table=vrf-orange suppress-hw-offload=no vrf-interface=ether1
Last edited by mtest001 on Wed Oct 18, 2023 2:55 pm, edited 2 times in total.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Cannot NAT traffic to VRF

Sun Oct 15, 2023 8:26 pm

Maybe You need to use mark-routing fw mangle rule OR routing->rule for outgoing traffic?
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Cannot NAT traffic to VRF

Tue Oct 17, 2023 10:55 pm

So I was able to simulate my setup in a virtual environment using the Mikrotik CHR ova and everything is working just fine. I was missing a return route from the ISP1 VRF to the main VRF and appart from this everything including the NAT worked pretty much on first try using a very simple masquerade rule.

I'm not on site to check my "production" setup and try to replicate he settings but at least now I know that with a minimalistic configuration things can work.
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Cannot NAT traffic to VRF

Wed Oct 18, 2023 12:35 pm

Good news. :)

If I may, I would appreciate if - when you have things set up, tested and working - you could share the "final" configuration.

As I see it too many threads start with a (complete but) not working configuration and end with a "Ok, I fixed that by simply changing my foonting turlingdromes then hooptiously drangled the kormzibs." :wink: which is not very useful for other newbies like myself attempting to learn/get inspiration.

jaclaz
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 IPS using gateways with same IP (was NAT traffic to VRF)

Wed Oct 18, 2023 2:47 pm

Thank you for your message.

I kept playing with my virtual lab environment and actually managed to find 2 working solutions, both to be tested and confirmed in real life. The first solution is my initial attempt using VRFs, the second solution is using point-to-point addresses and some proxy-arp tricks to fool the ISP gateways.


Solution 1 - VRFs

In this solution the LAN is in the network 192.168.2.0/24, and both ISPs' gateways are in the 192.168.1.0/24 in two separate VRFs. The Mikrotik addresses are 192.168.2.211 in the LAN (it is the default gateway of the hosts sitting on this LAN), 192.168.1.211 in VRF1 and 192.168.1.212 in VRF2 (could have been the same as in VRF1 but I decided to take a different address for clarity).
/ip vrf
add interfaces=ether1 name=vrf1
add interfaces=ether2 name=vrf2

/ip addresses
add address=192.168.1.211/24 interface=ether1 network=192.168.1.0
add address=192.168.1.212/24 interface=ether2 network=192.168.1.0
add address=192.168.2.211/24 interface=ether3 network=192.168.2.0

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=masquerade chain=srcnat out-interface=ether2

/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf2 routing-table=main 
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf1 routing-table=main 
add dst-address=192.168.2.0/24 gateway=ether3 routing-table=vrf1
add dst-address=192.168.2.0/24 gateway=ether3 routing-table=vrf2


Solution 2 - Point-to-point Addresses and Proxy-arp

Here the requirement is to have the ISP gateways directly connected to the Mikrotik, i.e. no switch in between. We'll assign two point-to-point addresses on each one of the Mikrotik's interfaces connected to each gateway. We'll also enable proxy-arp on all the Mikrotik interfaces to basically transform the Mikrotik into a kind-of "layer 2 router". The beauty of this solution is that there is no NAT involved, which is a plus especially considering that there is already NATing performed by the ISP gateways (so solution 1 involve double-natting). In this solution the Mikrotik address on the LAN is 192.168.1.211, it is the default gateway of the hosts sitting on the LAN. This solution was inspired to me by this video: https://www.youtube.com/watch?v=YJxVm6jZYiU&t=2706s and this howto: https://sudonull.com/post/96901-Mikroti ... m-one-host.

/interface ethernet
set [ find default-name=ether1 ] arp=proxy-arp
set [ find default-name=ether2 ] arp=proxy-arp
set [ find default-name=ether3 ] arp=proxy-arp

/ip address
add address=192.168.1.2 interface=ether1 network=192.168.1.1
add address=192.168.1.3 interface=ether2 network=192.168.1.1
add address=192.168.1.211/24 interface=ether3 network=192.168.1.0

/ip arp
add address=192.168.1.1 interface=ether1 mac-address=[enter the MAC of the ISP1 router if]
add address=192.168.1.1 interface=ether2 mac-address=[enter the MAC of the ISP2 router if]

/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether2
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether1

And this is it. In both cases I have a preferred gateway. Here if this gateway goes down the fail-over to the other is automatic because the related route becomes inactive. There is no need to use the check-gateway keep-alive mechanism.

Next, I will test it in real world and confirm that everything works as expected. Note that the same setup can possibly by improved to achieve an active/active scenario and load-balancing of traffic.

Thank you.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Oct 18, 2023 3:11 pm

use action=srcnat instead of masquerade in Firewall->NAT (so connections can always resume).

source: https://wiki.mikrotik.com/wiki/Manual:I ... Masquerade
Last edited by volkirik on Wed Oct 18, 2023 4:41 pm, edited 1 time in total.
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Oct 18, 2023 4:15 pm

src-nat and masquerading are the same thing, in the first case you force the IP to use and in the second it is automatically assigned by the router.

The whole point of the setup is to be able to route to two gateways that have the same IP.

If there is a simpler way then I am interested to see it, can you share your conf ?
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Oct 18, 2023 4:30 pm

src-nat and masquerading are the same thing, in the first case you force the IP to use and in the second it is automatically assigned by the router.
wrong; please read wiki. masquerading is incompatible with failover. connections break. with src-nat action they resume.
Last edited by volkirik on Wed Oct 18, 2023 4:40 pm, edited 2 times in total.
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Oct 18, 2023 4:33 pm

Ok but... as indicated above (first line of my initial post) I cannot change the IP of the ISP's routers, that is the challenge here.

Of course if I could change the IPs I would not need any of that.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Tue Oct 24, 2023 11:39 am

You do not need to change addresses...

Just use src-nat action in src-nat chain and type source ip address of mikrotik router for NAT'ing.

Masquerade action is buggy.
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Cannot NAT traffic to VRF

Mon Oct 30, 2023 5:41 pm

If I may, I would appreciate if - when you have things set up, tested and working - you could share the "final" configuration.
So I'm happy to confirm that both solutions were tested "in the real world" and both work just fine.

The solution 2 with point-to-point links is much better in my case because there is not NAT involved. Interestingly I only needed to implement the proxy-ARP on the outgoing interface, contrary to what I saw when testing on my virtual environment. Maybe because CHR is not so good at emulating layer2.
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Cannot NAT traffic to VRF

Tue Oct 31, 2023 10:57 am

If I may, I would appreciate if - when you have things set up, tested and working - you could share the "final" configuration.
So I'm happy to confirm that both solutions were tested "in the real world" and both work just fine.
Good :) .

Can you share your complete final configuration(s) (of course anonymized/with IP changed if needed) as a reference?

I just managed (somehow) to install GNS3 and the CHR image on a spare Windows 7 machine (it has not been exactly easy thanks to the quirks in GNS3 versioning between program and server and the "smart" decision by the good python guys to break support for Windows 7 in Python 3.9) and would like to start playing with your approach.

Is the CHR 7.11.2 version the one you used?

As seen from the outside, your solution #1 (making use of vrf's) is more "logical", but the #2 using the proxy-arp seems simpler to implement.

Another question, you are implementing (if I get this right and my terminology is not completely off) a "simple" failover based on PCC (distance of the gateway), does it work if the internet (not the ISP router/modem) goes down?

Or there will be the need to add to it recursive checking or netwatch or some other more complex checking to trigger the failover in this case?

jaclaz
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sat Nov 04, 2023 5:28 pm

Here is my conf. You can disregard the firewall part that is identical to the default conf.

The important parts are:

/interface ethernet: to enable proxy-arp on the PTP interfaces
/interface bridge port: to add to the bridge only the LAN interfaces, and remove the WAN interfaces
/interface list member: to define which interfaces are WAN and which one are LAN (used by the firewall)
/ip address: where the PTP links are defined
/ip arp: to speficy the MAC addresses of the remote ends of the PTP links
# 2023-11-04 11:04:33 by RouterOS 7.11.2
# software id = RGXD-FX2Y
#
# model = RB760iGS
/interface bridge
add admin-mac=48:8F:5A:XX:XX:XX auto-mac=no comment=defconf name=bridge \
    protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] arp=proxy-arp
set [ find default-name=ether2 ] arp=proxy-arp
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=dhcp-192-168-1 ranges=192.168.1.100-192.168.1.199
/ip dhcp-server
add address-pool=dhcp-192-168-1 comment=dchp-server interface=bridge name=\
    dchp-server
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf disabled=yes interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=sfp1 list=WAN
add interface=ether1 list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
add interface=ether2 list=WAN
/ip address
add address=192.168.1.221 comment=orange interface=ether1 network=192.168.1.1
add address=192.168.1.222 comment=starlink interface=ether2 network=\
    192.168.1.1
add address=192.168.1.211/24 comment=bridge interface=bridge network=\
    192.168.1.0
/ip arp
add address=192.168.1.1 interface=ether1 mac-address=7C:C1:77:XX:XX:XX
add address=192.168.1.1 interface=ether2 mac-address=74:24:9F:XX:XX:XX
/ip dhcp-client
add comment=defconf interface=sfp1
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf dns-server=9.9.9.9 gateway=\
    192.168.1.211 netmask=24
/ip dns
set allow-remote-requests=yes servers=9.9.9.9
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-nat-state="" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip route
add disabled=no distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether1 \
    pref-src="" routing-table=*2 suppress-hw-offload=no vrf-interface=ether1
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether2
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/Paris
/system identity
set name=Shodan111
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool sniffer
set filter-interface=ether1 filter-ip-protocol=icmp
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Nov 05, 2023 3:51 pm

Here is my conf.
Thank you very much.
I will try to reproduce in GNS3 and study your example.

jaclaz
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Nov 05, 2023 7:34 pm

First few questions:

In your previous partial code for the solution2 (arp-proxy) you had:
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether2
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether1
that make a lot of sense.

In the last (complete) code you have:
/ip route
add disabled=no distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether1 \
    pref-src="" routing-table=*2 suppress-hw-offload=no vrf-interface=ether1
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1%ether2
Why the reference in one of the two routes to "vrf-interface=ether1"?
Is it a leftover of a previous attempt with vrf's and now it is meaningless?
How did the "routing-table=*2" come out?
And what does it actually mean (if anything at all)?

jaclaz
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Nov 06, 2023 10:02 am

Well spotted thanks I did not notice that difference. I'm guessing that indeed some of the information is there because of the first tests I made using VRF.

I have since then removed the VRFs and this is probably why the "routing-table=*2".

Interestingly despite this my setup works as expected so I guess since the router cannot make any sens of the VRF related configuration it just assumed the route was to be added to the main table.
Last edited by mtest001 on Mon Nov 06, 2023 12:59 pm, edited 1 time in total.
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Nov 06, 2023 11:31 am

Good, thanks.

While playing in GNS3 I found out quickly that for experimenting it is better to delete the CHR virtual router and start with a new one, as there can be leftovers of previous tests that - even if not relevant (in the sense that they do not compromise the working of the new experiment) make some entries look "weird".

In the meantime I tested a configuration based on yours with VRF's and it seems to work just fine and it is in practice the only reference to VRF's I could find that I could also understand the working.
Next step will be to test a configuration based on your second solution, I will report if I can make it, thanks again.

jaclaz
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Nov 22, 2023 6:22 pm

Ok, I (sort of) managed to reproduce your second setup in GNS3 and the good news are that it (sort of) works.

I introduced two "very simple" routers between the "main" router (which I called "Router0_proxy_arp") and the "Cloud" of GNS3 (giving it "your" names of "Orange and "Starlink" and changed your 192.168.1.x addresses to 192.168.2.x.

Layout attached.

In this setup only the ether1 and ether2 of "Router0_proxy_arp" need to be set to arp=proxy-arp, AND the setup works just fine WITHOUT the two static arp entries you added in your original configuration, the arp entries are added dynamically.

Configuration of router "Orange" (as simple as it can be):
[admin@Orange] > /export
# 2023-11-22 15:40:23 by RouterOS 7.11.2
# software id =
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/disk
set slot1 slot=slot1 type=hardware
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/ip address
add address=192.168.1.254/24 interface=ether1 network=192.168.1.0
add address=192.168.2.1/24 interface=ether2 network=192.168.2.0
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add gateway=192.168.1.1
/system identity
set name=Orange
/system note
set show-at-login=no
Configuration of router "Starlink":
[admin@Starlink] > /export
# 2023-11-22 15:42:25 by RouterOS 7.11.2
# software id =
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/disk
set slot1 slot=slot1 type=hardware
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/ip address
add address=192.168.1.253/24 interface=ether1 network=192.168.1.0
add address=192.168.2.1/24 interface=ether2 network=192.168.2.0
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add gateway=192.168.1.1
/system identity
set name=Starlink
/system note
set show-at-login=no
Configuration of the "main" router "Router0_proxy_arp":
[admin@Router0_proxy_arp] > /export
# 2023-11-22 15:44:47 by RouterOS 7.11.2
# software id =
#
/interface bridge
add comment=defconf name=bridge protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] arp=proxy-arp disable-running-check=no
set [ find default-name=ether2 ] arp=proxy-arp disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/disk
set slot1 slot=slot1 type=hardware
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=ether1 list=WAN
add interface=ether2 list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
/ip address
add address=192.168.2.221 comment=orange interface=ether1 network=192.168.2.1
add address=192.168.2.222 comment=starlink interface=ether2 network=\
    192.168.2.1
add address=192.168.2.211/24 comment=bridge interface=bridge network=\
    192.168.2.0
/ip dhcp-client
add interface=ether1
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.2.1%ether1
add distance=2 gateway=192.168.2.1%ether2
/system identity
set name=Router0_proxy_arp
/system note
set show-at-login=no
Now, I can ping/trace 8.8.8.8 from the two virtual PC's, from the test router (besides of course from Orange, Starlink and Router0_proxy_arp), though I am still not sure about how/why exactly it works (but I can confirm that setting the ether 1/2 of Router0_proxy_arp to "enabled" connections are lost, so the proxy-arp is doing its magic :D ).

In "normal" operation, routes on Router0_proxy_arp are:
[admin@Router0_proxy_arp] /ip/arp> /ip route print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#      DST-ADDRESS     GATEWAY             DISTANCE
0  As  0.0.0.0/0       192.168.2.1%ether1         1
1   s  0.0.0.0/0       192.168.2.1%ether2         2
  DAc  192.168.2.0/24  bridge                     0
  DAc+ 192.168.2.1/32  ether2                     0
  DAc+ 192.168.2.1/32  ether1                     0
  
Switching off router "Orange" does not change routes.

Disabling the link in GNS3 between Router0_proxy_arp and "Orange" switches routes very fast to:

[admin@Router0_proxy_arp] /ip/arp> /ip route print
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#      DST-ADDRESS     GATEWAY             DISTANCE
0  IsH 0.0.0.0/0       192.168.2.1%ether1         1
1  As  0.0.0.0/0       192.168.2.1%ether2         2
  DAc  192.168.2.0/24  bridge                     0
  DAc  192.168.2.1/32  ether2                     0
  DIcH 192.168.2.1/32  ether1                     0
(which is the expected result)

As well, resuming the link in GNS3 changes them back very quickly.
Same happens if I disable and re-enable ether1 on Router0_proxy_arp.
If I disable the ether2 on router "Orange" as well routes do not change.

So - at least in the GNS3 simulation - the failover function is working "strangely".

I will see if I succeed in experimenting with some "more advanced" failover methods.
You do not have the required permissions to view the files attached to this post.
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Thu Nov 23, 2023 10:56 am

Congrats for the setup.

I have a similar experience in my simulated environment, where switching off one of the two border router did not trigger the change in the routing table. I think this is because those virtual environment cannot really replicate the layer 1 as it would be in real life.

You setup looks fine to me.
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Thu Nov 23, 2023 11:36 am

Yep, I too believe this behaviour to be a glitch in the simulation/emulation software.

There is (unfortunately) nothing to congratulate me for, right now all the merits are yours, I only transposed your setup, and I am still struggling to understand how/why it works.

To be honest (I am doing all this via telnet/putty on command line) the command line environment is much better (relatively easy to work with) than what I had expected, though it lacks (IMHO) some coherence in the paths/commands, as a newbie it seems to me like being somehow abstracted from the logic (which is fine, since the logic is complex, often vague and the documentation is either missing, unclear or spread into countless articles in the wiki or rare complete examples on the forum or on semi-random crappy youtube videos or blog articles). it reminds me somewhat of the time I had to deal with learning how to make bootable .iso's with mkisofs, since that tool is also Linux originated probably it is "normal".

I am still in the phase where I throw everything I can think of on the wall and see what sticks to it, when something works I am not sure to understand how/why it works and when something doesn't I have lots of difficulties in understanding how/why it doesn't.

But I am making (slowly) some progresses and I owe a lot to you, so thanks again :) .
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Thu Nov 23, 2023 4:09 pm

For the sake of completeness, I am posting the configuration and layout in GNS3 of my working implementation of your first solution (the one using VRF's).
Router0_Vrf:
[admin@Router0_VRF] > export
# 2023-11-23 13:41:52 by RouterOS 7.11.2
# software id =
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no
set [ find default-name=ether3 ] disable-running-check=no
set [ find default-name=ether4 ] disable-running-check=no
set [ find default-name=ether5 ] disable-running-check=no
set [ find default-name=ether6 ] disable-running-check=no
set [ find default-name=ether7 ] disable-running-check=no
set [ find default-name=ether8 ] disable-running-check=no
/disk
set slot1 slot=slot1 type=hardware
set slot2 slot=slot2 type=hardware
set slot3 slot=slot3 type=hardware
set slot4 slot=slot4 type=hardware
set slot5 slot=slot5 type=hardware
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip vrf
add interfaces=ether2 name=vrf2
add interfaces=ether1 name=vrf1
/port
set 0 name=serial0
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add interface=ether1 list=WAN
add interface=ether2 list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
/ip address
add address=192.168.1.254/24 interface=ether1 network=192.168.1.0
add address=192.168.1.253/24 interface=ether2 network=192.168.1.0
add address=192.168.2.1/24 interface=ether3 network=192.168.2.0
add address=10.0.0.1/24 interface=ether4 network=10.0.0.0
/ip firewall nat
add action=masquerade chain=srcnat disabled=yes out-interface=ether1
add action=masquerade chain=srcnat disabled=yes out-interface=ether2
add action=src-nat chain=srcnat out-interface=ether1 src-address=\
    192.168.2.0/24 to-addresses=192.168.1.254
add action=src-nat chain=srcnat out-interface=ether2 src-address=\
    192.168.2.0/24 to-addresses=192.168.1.253
add action=src-nat chain=srcnat out-interface=ether1 src-address=10.0.0.0/24 \
    to-addresses=192.168.1.254
add action=src-nat chain=srcnat out-interface=ether2 src-address=10.0.0.0/24 \
    to-addresses=192.168.1.253
/ip route
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf2 routing-table=\
    main
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.1.1@vrf1 routing-table=\
    main
add dst-address=192.168.2.0/24 gateway=ether3 routing-table=vrf1
add dst-address=192.168.2.0/24 gateway=ether3 routing-table=vrf2
add dst-address=10.0.0.0/24 gateway=ether4 routing-table=vrf1
add dst-address=10.0.0.0/24 gateway=ether4 routing-table=vrf2
/system identity
set name=Router0_VRF
/system note
set show-at-login=no
I am (slowly) finding ways/conventions to better visualize the logic/addresses (maybe it is just me but within five minutes of playing with addresses and routes I lose the context), this helps, maybe it is useful for other people.

I am starting to think in North/South layout, North is Internet (or the cloud or "outside") South is user device's/PC's (or "inside").
Gateway (or "next hop") when possible is x.y.z.1 (i.e. lowest address of a /24 subnet)
"Outbound" port connected to the Gateway when possible is x.y.z.254 (i.e. highest address of a /24 subnet or the highest available address in that subnet).
This way the outbound flow is South to North and going through "decreasing" addresses.

A "queer" thing I noticed is that in default /ip route print:
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY           DISTANCE
0  As 0.0.0.0/0       192.168.1.1@vrf1         1
1   s 0.0.0.0/0       192.168.1.1@vrf2         2
  DAc 10.0.0.0/24     ether4                   0
  DAc 192.168.2.0/24  ether3                   0
2  As 10.0.0.0/24     ether4                   1
  DAc 192.168.1.0/24  ether1@vrf1              0
3  As 192.168.2.0/24  ether3                   1
4  As 10.0.0.0/24     ether4                   1
  DAc 192.168.1.0/24  ether2@vrf2              0
5  As 192.168.2.0/24  ether3                   1

there is no way to understand which routes "belong" to which table, so, using vrf's one needs:
/ip route print where routing-table=main
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY           DISTANCE
0  As 0.0.0.0/0       192.168.1.1@vrf1         1
1   s 0.0.0.0/0       192.168.1.1@vrf2         2
  DAc 10.0.0.0/24     ether4                   0
  DAc 192.168.2.0/24  ether3                   0
/ip route print where routing-table=vrf1
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY      DISTANCE
2  As 10.0.0.0/24     ether4              1
  DAc 192.168.1.0/24  ether1@vrf1         0
3  As 192.168.2.0/24  ether3              1
/ip route print where routing-table=vrf2
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY      DISTANCE
4  As 10.0.0.0/24     ether4              1
  DAc 192.168.1.0/24  ether2@vrf2         0
5  As 192.168.2.0/24  ether3              1
You do not have the required permissions to view the files attached to this post.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Nov 27, 2023 9:58 am

In the examples above it seems the WAN interfaces IP addresses are static. Can this implementation work if the WAN IPs can change at the whim of my ISP's DHCP server? My goals is to have 2 VLANs use one of the WAN circuits, and the other VLANs to use the other, but within my LAN I need to allow access between all the VLANs.

At the moment, I have the following from the ISP (in case what they assign me matters)

port: wan1 IP Addr: xxx.xxx.140.100/18 Network: xxx.xxx.128.0 Gateway: xxx.xxx.128.1
port: wan2 IP Addr: xxx.xxx.170.200/18 Network: xxx.xxx.128.0 Gateway: xxx.xxx.128.1
 
mtest001
newbie
Topic Author
Posts: 28
Joined: Mon Oct 18, 2021 12:49 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sat Dec 02, 2023 11:35 pm

I think the fact that WAN IP may change does not make any difference here.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Dec 03, 2023 2:04 am

Then I understand less than I thought. These two lines are an example where it seems to hardcode the wan IP addresses, unless I am mistaken.
add action=src-nat chain=srcnat out-interface=ether2 src-address=\
    192.168.2.0/24 to-addresses=192.168.1.253
add action=src-nat chain=srcnat out-interface=ether1 src-address=10.0.0.0/24 \
    to-addresses=192.168.1.254
 
rplant
Member Candidate
Member Candidate
Posts: 268
Joined: Fri Sep 29, 2017 11:42 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Dec 03, 2023 3:23 am

action=src-nat does require an address (unlike masquerade)

You can put something along the lines of the following into your dhcp client configuration
(below is for changing items in the routing table based on the contents of the comment for the rule, modify as required for NAT entries)
/ip dhcp-client
add default-route-distance=3 interface=ether2 script="/ip route\r\
    \n:if (\$bound = 1) do={\r\
    \n  set [find where comment~\"altgw\"]  gateway=\$\"gateway-address\"\r\
    \n}"

In winbox DHCP client script.

/ip route
:if ($bound = 1) do={
  set [find where comment~"altgw"]  gateway=$"gateway-address"
}    
    
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Dec 03, 2023 8:24 am

action=src-nat does require an address (unlike masquerade)

You can put something along the lines of the following into your dhcp client configuration
(below is for changing items in the routing table based on the contents of the comment for the rule, modify as required for NAT entries)
/ip dhcp-client
add default-route-distance=3 interface=ether2 script="/ip route\r\
    \n:if (\$bound = 1) do={\r\
    \n  set [find where comment~\"altgw\"]  gateway=\$\"gateway-address\"\r\
    \n}"

In winbox DHCP client script.

/ip route
:if ($bound = 1) do={
  set [find where comment~"altgw"]  gateway=$"gateway-address"
}    
    
Thanks. I think I understand what that is doing. I didn't know the routeros scripting could do stuff like that. I'll try and marry the two together and see how much of a mess I can make of it.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Dec 03, 2023 12:24 pm

OK, this is way beyond my capabilities. I'm stopping before I blow everything up and maybe try again when I understand more.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18705
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Sun Dec 03, 2023 6:54 pm

Have you considered NOT using the starlink router and connect CGNAT direct to your router?
Your gateway in this case will be 100.64.0.1 ............ or something like that.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 12:25 am

Have you considered NOT using the starlink router and connect CGNAT direct to your router?
Your gateway in this case will be 100.64.0.1 ............ or something like that.

No, I haven't because I am a beginner at Mikrotik and I really don't know what you mean. I have a hAP-AX2 and 2 x 1GB WAN connections that have the same gateway address. That's all I can tell you. I just googled CGNAT to see what it is and I don't know if that's what I am dealing with or not.

This is what my WAN ports look like. The redacted octets are the same in all 4 address.
WAN12.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18705
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 2:35 am

What are you talking about? The original OP stated he was getting the same IP gateway from two ISPs starlink and something else, aka gateway=192.168.1.1

What does that have to do with you having two 1gig connections?
Are you saying you are using two ISP supplied modem routers in front of you and each uses 192.168.1.1 as the local LAN.
You can only forward ports but not change the LAN structure?
ISP refuses to enter the router and change the LAN structure on your behalf??
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 3:17 am

What are you talking about?

I assumed you were talking to me. There was no quote and the OP wasn't part of the latest conversation

The original OP stated he was getting the same IP gateway from two ISPs starlink and something else, aka gateway=192.168.1.1

What does that have to do with you having two 1gig connections?

When I started a thread to look for help with my issue, I was pointed to this thread by you. I assumed that this would address my issue. viewtopic.php?p=1038012#p1037984

Are you saying you are using two ISP supplied modem routers in front of you and each uses 192.168.1.1 as the local LAN.
You can only forward ports but not change the LAN structure?
ISP refuses to enter the router and change the LAN structure on your behalf??

No. I have 1 x ISP supplied ONT. It has two ethernet ports coming out, both are 1 Gb circuits. These I have connected to ether1 and ether2 on the hjPA-AX2. As per the jpg I posted, the two WAN circuits are on the same /18 network and as such they have different IPs, ISP DHCP provided, but have the same gateway.

Because they have the same gateway address, most of the Dual WAN tutorials and how-tos I have read don't seem to work because they assume different gateway addresses. That's why I started a new thread asking for some guidance.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18705
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 4:53 am

Ahh okay one modem two WAN IPs, same gateway address............ Okay that makes sense, my bad.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 7:06 am

No drama, all good.

So can I assume this isn't the thread that can help me with my use case?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18705
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 1:44 pm

Well I dont understand this o ne...........
but within my LAN I need to allow access between all the VLANs.

Can you elaborate? If they all need access to each other why have separate vlans?

Can you confirm these are dynamic IPs that change BUT the gateway never changes??
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 3:18 pm

Well I dont understand this o ne...........
but within my LAN I need to allow access between all the VLANs.

Can you elaborate? If they all need access to each other why have separate vlans?

I'll tighten them up eventually. iOT will be tightened. Kids VLAN will have a rule to disable the internet at certain hours, etc. I can remove that comment if it's too confusing

Can you confirm these are dynamic IPs that change BUT the gateway never changes??

Not that I have noticed. But when I ask the ISP, called to ask if I can get an IP with a different gateway, I get stunned silence and they won't let me get to someone who would know the answer.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18705
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Mon Dec 04, 2023 3:33 pm

Well if they are static Ips, then that would be easier to deal with, you should confirm with your ISP that they are static!
Confirm you are paying for two separate 1 gig connections? and on each one you can get 1 gig at the same time......
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Tue Dec 05, 2023 3:04 pm

Then I understand less than I thought. These two lines are an example where it seems to hardcode the wan IP addresses, unless I am mistaken.
In those two lines the hardcoded part is only the address attributed to the router WAN interface, unless the subnet changes those addresses can be fixed, but anyway the whole snippet include (disabled) two (more generic) masquerade rules that you can enable if you want to (disabling the src-nat ones):

/ip firewall nat
add action=masquerade chain=srcnat disabled=yes out-interface=ether1
add action=masquerade chain=srcnat disabled=yes out-interface=ether2
add action=src-nat chain=srcnat out-interface=ether1 src-address=\
    192.168.2.0/24 to-addresses=192.168.1.254
add action=src-nat chain=srcnat out-interface=ether2 src-address=\
    192.168.2.0/24 to-addresses=192.168.1.253
add action=src-nat chain=srcnat out-interface=ether1 src-address=10.0.0.0/24 \
    to-addresses=192.168.1.254
add action=src-nat chain=srcnat out-interface=ether2 src-address=10.0.0.0/24 \
    to-addresses=192.168.1.253
I still have to understand why exactly, but 99.99% of examples use "masquerade" (seemingly the reason is that it is more suitable for dynamic connections, though I believe that the "side effect" of having no need for specifying the to-addresses parameter, i.e. the fact that it is a simpler, easier to implement, command is the real reason), anyway if you try to use it, another member will soon post about src-nat being more suitable for static connections.

At the end of the day I don't think there are so big differences in practice, at least in simple setups such as these ones. surely the src-nat is more "exact", while the "masquerade" is more "flexible", but the latter may well (as member volkirik posted above) be buggy in some cases.
 
User avatar
dalben
Frequent Visitor
Frequent Visitor
Posts: 64
Joined: Fri Oct 06, 2023 2:17 am

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Wed Dec 06, 2023 6:04 am

Well if they are static Ips, then that would be easier to deal with, you should confirm with your ISP that they are static!
Confirm you are paying for two separate 1 gig connections? and on each one you can get 1 gig at the same time......
They aren't static. That much I know as I just need to disable WAN2 for a couple of hours, then enable it again to get a different IP.

Yes. I have 2 x 1GB. Yes, each one I get 1Gb at the same time.

I will move this discussion back to viewtopic.php?p=1038012, my original post before I was sent here. What I have is different to this post and I don't want to confuse anyone.
 
jaclaz
Member
Member
Posts: 420
Joined: Tue Oct 03, 2023 4:21 pm

Re: Failover between 2 ISPs using gateways with same IP (was NAT traffic to VRF)

Fri Dec 22, 2023 11:34 pm

Only to keep things as together as possibile, using the 2 (actually 3) vrf's on the WAN side I had issues with DNS resolving and - consequently - with NTP synchronization.
Since I wasn't able to find a solution/workaround (very likely they exist, but I couldn't find them) I tried reversing the approach, using a single vrf on the LAN side, putting the three same IP outbound interfaces on the "main" router using the % addressing.
I posted the setup on my "caveman' thread here:
viewtopic.php?t=200213#p1043616
It seems to be working just fine in GNS3 but I still have to test it in the real world.

Who is online

Users browsing this forum: button, miku, rplant and 26 guests