Community discussions

MikroTik App
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

default route prevents use of additional LTE passthrough WAN

Sun Jun 27, 2021 5:10 am

I have two WAN connections. One is fibre provided by PPPoE (ether1), the other DHCP (ether7) from a Mikrotik LTE dish configured for passthrough. These are setup with add-default-route=yes with distance 1 & 2 respectively for failover purposes which works.

I also have some PPTP VPN connections that serve as foreign WANs for testing and streaming, and I have mangle and route rules so I can route traffic from individual devices over these connections and that all works great.

However if I try to route traffic over the LTE connection with similar rules to the ones that work for the VPNs, nothing works. If I try /tool ping with the LTE interface selected (ether7) I just get timeout and host unreachable. Only if I remove the default route for the PPPoE connection do I then get anything from the LTE connection which is kinda useless. I want to be able to do some testing and streaming over LTE like the foreign VPNs in addition to having it for failover.

Ive tried all sorts of combinations of route rules and routing marks, and have so far not found a way to make use of the LTE connection simultaneously with the PPPoE connection What could be preventing the use of the LTE connection?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: default route prevents use of additional LTE passthrough WAN

Sun Jun 27, 2021 7:36 pm

The description is too generic, so the answer cannot be any better.

The only reason to come to my mind is that you initiate the test connections from the router itself, which means that the source address is chosen according to the default route via PPPoE, and when the packet gets a routing-mark in chain output of mangle, its source IP address doesn't automatically change to the one assigned to the LTE-facing interfacce so the LTE drops the packet. You have to use an action=src-nat or action=masquerade rule to fix that. Search for "routing adjustment" here on the forum for details.

If the above doesn't help, post the export of the actual configuration, following the hint in my automatic signature here below.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: default route prevents use of additional LTE passthrough WAN

Sun Jun 27, 2021 7:44 pm

For testing purposes, if you connect the LTE dish ethernet directly to your computer, can you reach the internet ?
If not, there is something wrong with your LTE configuration...

In /tool ping instead of selecting ether7 use the Routing Table field and specify the Route Table for the LTE interface, is it working ?
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 1:16 am

Thanks for the two reply's.

LTE connection works if connected directly to say laptop or desktop ethernet. Also as I mentioned when the default route is removed from the PPPoE connection traffic flows over LTE as expected.

When I use /tool ping for basic testing I use the interface field to select the LTE ether7 interface as source. I have also used the routing table field in the advanced tab to select the LTE route I setup.

I can't post my config as its too big with lots of customer identifiable info. But I tested this on hAP AC2, RB2011, RB3011 and hEX-PoE with no more than the default config with PPPoE added on ether1 with distance=1, and moved DHCP client to ether5 with distance=2, and of course removed ether5 from the bridge. I even used 2x LTE dish to put 2x DHCP based WANS in the mix and same results.

I think this can be reproduced with nearly any dual WAN combination where distance 1 & 2 or similar is used (Ive tried other values for distance).
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 1:24 am

I will see if I can post a cutdown config from one of my test sites.
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 2:10 am

Cut down config below from a test site, and live routing table print.
/interface bridge
add name=bridge protocol-mode=none
/interface vlan
add interface=ether1 name=vlan-lte-admin vlan-id=4
add interface=ether5 name=vlan-lte2-admin vlan-id=4
/interface list
add comment=defconf name=WANs
add comment=defconf name=LANs
add name=VPNs
/ip pool
add name=default-dhcp ranges=192.168.25.11-192.168.25.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge interface=vlan-lte-admin
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge disabled=yes interface=ether5
add bridge=bridge interface=vlan-lte2-admin
/interface list member
add comment=defconf interface=bridge list=LANs
add comment=defconf interface=ether1 list=WANs
add interface=pptp-out-PureVPN list=VPNs
add interface=pptp-out-PureVPN list=WANs
add interface=pptp-out-Office list=VPNs
add interface=ether5 list=WANs
/interface pptp-server server
set authentication=chap
/ip address
add address=192.168.25.1/24 comment=defconf interface=bridge network=\
    192.168.25.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1 use-peer-dns=no
add default-route-distance=2 disabled=no interface=ether5 use-peer-dns=no \
    use-peer-ntp=no
/ip dhcp-server lease
add address=192.168.25.100 client-id=XX comment=\
    "MAC Mini" mac-address=XX server=defconf
add address=192.168.25.2 comment="LTE Dish" mac-address=48:8F:5A:XX:XX:XX
add address=192.168.25.3 comment="LTE Dish2" mac-address=48:8F:5A:XX:XX:XX
add address=192.168.25.249 client-id=XX mac-address=\
    XX server=defconf
add address=192.168.25.4 client-id=XX comment="cAP Audience" \
    mac-address=XX server=defconf
/ip dhcp-server network
add address=192.168.25.0/24 comment=defconf dns-server=192.168.25.1 gateway=\
    192.168.25.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip firewall address-list
add address=172.16.123.0/24 comment=NYSC list="Friendly Networks"
add address=10.0.123.0/24 list="Friendly Networks" comment="VPN Clients"
add list="Black List (Winbox)"
/ip firewall filter
add action=reject chain=input comment="Drop anyone in Black List (Winbox)." \
    connection-state="" in-interface-list=WANs log-prefix=\
    "BLOCKED_Black List (Winbox)" protocol=tcp reject-with=\
    icmp-network-unreachable src-address-list="Black List (Winbox)"
add action=reject chain=input comment="Drop anyone in Black List (Winbox)." \
    connection-state="" in-interface-list=WANs log-prefix=\
    "BLOCKED_Black List (Winbox)" protocol=udp reject-with=\
    icmp-host-unreachable src-address-list="Black List (Winbox)"
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=accept chain=input comment="Allow Winbox Connections" dst-port=\
    8291 in-interface-list=WANs protocol=tcp
add action=accept chain=input comment="Allow PPTP Connections" dst-port=1723 \
    in-interface-list=WANs protocol=tcp
add action=accept chain=input comment="Allow ANYTHING from Friendly Networks" \
    src-address-list="Friendly Networks"
add action=jump chain=input comment="Jump to Black List (Winbox) chain." \
    dst-port=8291,22,1723 in-interface-list=WANs jump-target=\
    "Black List (Winbox) Chain" protocol=tcp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LANs
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-mark=!DontFasttrack connection-state=established,related
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 all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WANs
add action=jump chain=input comment="Jump to Black List (GRE IPSEC) chain." \
    disabled=yes in-interface-list=WANs jump-target=\
    "Black List (Winbox) Chain" protocol=gre
add action=add-src-to-address-list address-list="Black List (Winbox)" \
    address-list-timeout=4w2d chain="Black List (Winbox) Chain" comment="Trans\
    fer repeated attempts from Black List (Winbox) Stage 3 to Black List (Winb\
    ox)." connection-state=new in-interface-list=WANs log=yes log-prefix=\
    "Add_Black List (Winbox)" src-address-list="Black List (Winbox) Stage 3"
add action=add-src-to-address-list address-list="Black List (Winbox) Stage 3" \
    address-list-timeout=1m chain="Black List (Winbox) Chain" comment=\
    "Add succesive attempts to Black List (Winbox) Stage 3." \
    connection-state=new in-interface-list=WANs log=yes log-prefix=\
    "Add_Black List (Winbox) S3" src-address-list=\
    "Black List (Winbox) Stage 2"
add action=add-src-to-address-list address-list="Black List (Winbox) Stage 2" \
    address-list-timeout=1m chain="Black List (Winbox) Chain" comment=\
    "Add succesive attempts to Black List (Winbox) Stage 2." \
    connection-state=new in-interface-list=WANs log=yes log-prefix=\
    "Add_Black List (Winbox) S2" src-address-list=\
    "Black List (Winbox) Stage 1"
add action=add-src-to-address-list address-list="Black List (Winbox) Stage 1" \
    address-list-timeout=1m chain="Black List (Winbox) Chain" comment=\
    "Add initial attempt to Black List (Winbox) Stage 1." connection-state=\
    new in-interface-list=WANs log=yes log-prefix=\
    "Add_Black List (Winbox) S1"
add action=return chain="Black List (Winbox) Chain" comment=\
    "Return From Black List (Winbox) chain."
/ip firewall mangle
add action=mark-connection chain=prerouting comment=\
    "MARK No-Fasttrack Connections" in-interface-list=VPNs \
    new-connection-mark=DontFasttrack passthrough=yes
add action=mark-connection chain=postrouting comment=\
    "MARK No-Fasttrack Connections" new-connection-mark=DontFasttrack \
    out-interface-list=VPNs passthrough=yes
add action=mark-routing chain=prerouting comment=\
    "Mark LAN Packets for Routing over PureVPN" disabled=yes \
    dst-address-type=!local new-routing-mark=to-VPN-WAN passthrough=yes \
    src-address=192.168.25.11-192.168.25.254
add action=mark-routing chain=prerouting comment=\
    "Mark MAC-MINI Packets for Routing over Office WAN" dst-address-type=\
    !local new-routing-mark=to-VPN-OFFICE passthrough=yes src-address=\
    192.168.25.100
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface=ether5
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface=ether1
# pptp-out-PureVPN not ready
add action=masquerade chain=srcnat out-interface=pptp-out-PureVPN
/ip route
add check-gateway=ping distance=1 gateway=pptp-out-PureVPN routing-mark=\
    to-VPN-WAN
add distance=1 gateway=pptp-out-Office routing-mark=to-VPN-OFFICE
add check-gateway=ping distance=1 gateway=ether5 routing-mark=to-WAN2
add check-gateway=ping distance=1 gateway=ether1 routing-mark=to-WAN1

/ip route> print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 0   S  dst-address=0.0.0.0/0 gateway=pptp-out-PureVPN gateway-status=pptp-out-PureVPN unreachable check-gateway=ping 
        distance=1 scope=30 target-scope=10 routing-mark=to-VPN-WAN 

 1 A S  dst-address=0.0.0.0/0 gateway=pptp-out-Office gateway-status=pptp-out-Office reachable distance=1 scope=30 
        target-scope=10 routing-mark=to-VPN-OFFICE 

 2 A S  dst-address=0.0.0.0/0 gateway=ether5 gateway-status=ether5 reachable check-gateway=ping distance=1 scope=30 
        target-scope=10 routing-mark=to-WAN2 

 3 A S  dst-address=0.0.0.0/0 gateway=ether1 gateway-status=ether1 reachable check-gateway=ping distance=1 scope=30 
        target-scope=10 routing-mark=to-WAN1 

 4 ADS  dst-address=0.0.0.0/0 gateway=94.XXX.XXX.76 gateway-status=94.XXX.XXX.76 reachable via  ether1 distance=1 scope=30 
        target-scope=10 vrf-interface=ether1 

 5  DS  dst-address=0.0.0.0/0 gateway=10.XXX.XXX.138 gateway-status=10.XXX.XXX.138 reachable via  ether5 distance=2 scope=30 
        target-scope=10 vrf-interface=ether5 

 
aesmith
Member Candidate
Member Candidate
Posts: 264
Joined: Wed Mar 27, 2019 6:43 pm

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 6:57 pm

One thing that strikes me is that your dynamic routes have explicit next-hop gateways, and your selective route just has the interface. For what it's worth for my test with marking I used an explicit next hop. XX.XX.XX.XX is the inside IP address of my DSL router.
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=8.8.4.4 new-routing-mark=FORCE-DSL passthrough=yes

/ip route
add check-gateway=ping comment="*** ADSL - PBR Test ***" distance=1 gateway=XX.XX.XX.XX routing-mark=FORCE-DSL

Your dynamic default LTE route is ..
 5  DS  dst-address=0.0.0.0/0 gateway=10.XXX.XXX.138 gateway-status=10.XXX.XXX.138 reachable via  ether5 distance=2 scope=30 
        target-scope=10 vrf-interface=ether5 

Whereas your over-ride for marked traffic ..
 2 A S  dst-address=0.0.0.0/0 gateway=ether5 gateway-status=ether5 reachable check-gateway=ping distance=1 scope=30 
        target-scope=10 routing-mark=to-WAN2 
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 9:14 pm

Interface name as Gateway is not used for nexthop lookup...
https://wiki.mikrotik.com/wiki/Manual:I ... hop_lookup

You can use interface name as gateway in ppp Tunnels/ Interfaces...

So, use the IP address as Gateway for your LTE Interface and you can use a Script on your DHCP client to change the IP address on your Route Table in case it changes... Do not use check-gateway for the LTE...
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jun 28, 2021 11:35 pm

Thanks for detailed replies.

I think I understand the point about named interfaces not being used in lookups.

Marked routing aside where I've used named interface, if you look at the live routing table output at the bottom, the last two entries are default routes with the IP addresses of ether1 & ether5. Are these not enough to find next hops?

Route next hops does show both gateway IPs, so it should be working?
 
aesmith
Member Candidate
Member Candidate
Posts: 264
Joined: Wed Mar 27, 2019 6:43 pm

Re: default route prevents use of additional LTE passthrough WAN

Wed Jun 30, 2021 6:52 pm

It can't find a next-hop just by interface name, unless it's a point to point interface where there can only be one device connected. Like PPP or a tunnel. Where it's an Ethernet interface there could be any number of other devices, so it needs to know which one to use as the next hop. But I see the issue if the address is passed through from your LTE provider and subject to change.
 
aesmith
Member Candidate
Member Candidate
Posts: 264
Joined: Wed Mar 27, 2019 6:43 pm

Re: default route prevents use of additional LTE passthrough WAN

Thu Jul 01, 2021 1:47 pm

Thinking again about this, I can't see any particular reason to have your LTE router passing through. What I think I'd do unless it interferes with something in particular is ..
1. Reconfigure LTE router not to pass through
2. Static IP addressing on the link between LTE and main router
3. Remove NAT from main router for this path (NAT and firewall on LTE)
4. Static route on LTE router for your inside network(s)

This is in fact what I do, I have RB4011 as main router and wireless, then it has a routed link to an SXT LTE router, and another to a DSL router. The RB4011 doesn't do NAT for either of those routes.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: default route prevents use of additional LTE passthrough WAN

Fri Jul 02, 2021 9:26 pm

Actually i believe its better to use passthrough because everything stays in one place, firewall, Nat etc...
In most of my setups i do use pasthrough along with VLANs for management puproses of the LTE Device...
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Sat Jul 03, 2021 2:01 am

I can see cases for both setups, probably passthrough has a performance hit based on one of the Mikrotik videos I watched he talked about removing the address to increase performance - "Make your LTE interfaces shine" - a video that starts out very promising but then he never explains it fully leaving you high and dry. Personally I dont want to have to manage two firewalls but I may have to if I cant find an elegant solution.

After trying various things and response from Mikrotik I can confirm that @Zacharius was correct - you can only have one active default route and my force routes (route-mark) rules with interface names don't work for ethernet based interfaces because as was pointed out named interfaces aren't used in lookups because unlike ppp and tunnels, there can be many possible hosts that could be gateway so an IP is needed - although I thing this is a pretty lame limitation given that the router knows full well the connection between interface, dhcp-client, and gateway IP assigned.

When I temporarily added force routes using the gateway address things worked as expected. But here's something I wish Mikroitk would address, that of updating the gateway address when its changed by dhcp-renew or similar. And this is frequently the case for LTE connections. Its annoying because this is basic dual wan functionality to want to have failover and possibility to use 2nd wan for some devices or certain traffic.

So now I need to figure out a script to go in the dhcp-client that updates the force routes with the gateway address. Hmmm...
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: default route prevents use of additional LTE passthrough WAN

Wed Jul 07, 2021 4:30 pm

If you search in the forum you will find a script to use in the DHCP client so that the Gateway address in the Routing Table is automatically renewed upon an address change...
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: default route prevents use of additional LTE passthrough WAN

Wed Jul 07, 2021 4:59 pm

Someone call me? :P


The start point for do a well job is to use routing things to do routing things.
Do not use routing-mark on mangle for routing, not everytime work as expected,
Is like using "vlan" interfaces and bridge all togheter for use vlan, instead to configure directly vlan on bridge/switch...

If some address must use one route table than another, you must use... route rules!

For example:
DO NOT FORGET pref-src!
/ip route
add check-gateway=ping distance=10 gateway=100.8.2.1 pref-src=100.8.2.2
add check-gateway=ping distance=20 gateway=10.88.1.1 pref-src=10.88.1.2 routing-mark=ADSL

instead to do this:
/ip firewall mangle
add action=mark-routing chain=prerouting src-address=192.168.88.0/24 new-routing-mark=LTE passthrough=yes
add action=mark-routing chain=prerouting dst-address=192.168.88.0/24 new-routing-mark=LTE passthrough=yes

do this:
/ip route rule
add src-address=192.168.88.0/24 action=lookup-only-in-table table=LTE
add dst-address=192.168.88.0/24 action=lookup-only-in-table table=LTE

Each thing on his right place.
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Fri Jul 16, 2021 4:51 am

So Im just revisiting this. I was able to setup dhcp scripts to insert the current gateways in the marked routes, and also connection marks and routing marks for inbound connections, and that all works.

The primary LTE1 gives a real WAN IP so I can access the system via that, but LTE2 provider gives NATd address so inbound doesn't work but that's ok. I have an outbound VPN to my home network and access the LAN over that.

The problem Ive got now - which is why Im trying to do this - is that I'm trying to force the outbound PPTP VPN to use LTE2 connection so that if the LTE1 connections dies I don't loose access. Actually I need this so Mikrotik can debug the LTE1 device.

Ive got mangle rules that identify gre and 1723 traffic to my home IP (static) and mark for routing over LTE2. But it doesn't work. I can see in the firewall connections table that the connection is originating from LTE1 address.Although weirdly it shows Reply Dst Address as the LTE2 address, but Src Address as LTE1.
/ip firewall mangle
add action=mark-routing chain=output comment="Mark VPN Packets for routing over backup LTE2" dst-address=homeip dst-port=1723 new-routing-mark=to-WAN2 passthrough=no \
    protocol=tcp
add action=mark-routing chain=output comment="Mark VPN Packets for routing over backup LTE2" dst-address=homeip new-routing-mark=to-WAN2 passthrough=no protocol=gre
If I initiate ping with the different routing marks I get replies with round trip times as expected of the two different LTE connections (one cell-tower is much further away). But the PPTP connection always leaves via LTE1. So either the marked routes dont work or the VPN marking is incorrect.

Ive read lots of forum threads covering dual wans, load balancing etc and even some MUM videos dealing with it. I really cant see what I'm doing wrong. I get the feeling that its not so easy to route outbound traffic from the router itself, as it is to route LAN clients.
 
Zacharias
Forum Guru
Forum Guru
Posts: 3459
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: default route prevents use of additional LTE passthrough WAN

Sun Jul 18, 2021 9:19 pm

On your first rule set passthrough=yes

Also, what comes from your first WAN connection should leave from that first WAN Interface and what comes from your second WAN should leave as well from the Second one...

So, do you mark those connection on the output chain ?
Example:
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1     
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2
Source: https://wiki.mikrotik.com/wiki/Manual:PCC

Also, check here:https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS#PacketFlowinRouterOS-Output

If you dont specify correclty the output chain, the connection ( or the reply )will leave through your Main Routing Table...
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 1:20 am

Thanks, I have got WAN input/output marking in place as below and it works.

add action=mark-connection chain=input comment="Mark WAN1 Input Connections" connection-mark=no-mark in-interface-list=WAN1 new-connection-mark=WAN1->ROS passthrough=\
    yes
add action=mark-connection chain=input comment="Mark WAN2 Input Connections" connection-mark=no-mark in-interface-list=WAN2 new-connection-mark=WAN2->ROS passthrough=\
    yes
add action=mark-routing chain=output comment="Mark WAN1->ROS Connections for RETURN route" connection-mark=WAN1->ROS new-routing-mark=to-WAN1 passthrough=yes
add action=mark-routing chain=output comment="Mark WAN2->ROS Connections for RETURN route" connection-mark=WAN2->ROS new-routing-mark=to-WAN2 passthrough=yes
add action=mark-routing chain=output comment="Mark VPN Packets for routing over backup LTE2" dst-address=homeip dst-port=1723 log=yes log-prefix=PPTP-Mark \
    new-routing-mark=to-WAN2 passthrough=yes protocol=tcp
add action=mark-routing chain=output comment="Mark VPN Packets for routing over backup LTE2" dst-address=homeip log-prefix=GRE-Mark new-routing-mark=to-WAN2 \
    passthrough=no protocol=gre


Also my marked routes:
add distance=1 gateway=10.213.xx.17 pref-src=10.213.xx.18 routing-mark=to-WAN2
add distance=1 gateway=10.177.xx.6 pref-src=92.40.xx.126 routing-mark=to-WAN1

And resulting routing table:
#      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
0 A S     0.0.0.0/0          10.213.xx.18    10.213.xx.17              1
1 A S     0.0.0.0/0          92.40.xx.126    10.177.xx.6                1
2 ADS   0.0.0.0/0                                   10.177.xx.6                1
3   DS   0.0.0.0/0                                   10.213.xx.17              2
4 ADC  10.177.xx.6/32      92.40.xx.126    vlan-lte-wan1             0
5 ADC  10.213.xx.16/30    10.213.xx.18    vlan-lte-wan2             0
6 ADC  192.168.25.0/24    192.168.25.1    bridge                    0

 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 5:56 am

Better to do routing things on routing than on firewall...

Use routes / rules instead routing mark, when possible.

You know how?

For Example
/ip route rule
add action=lookup-only-in-table src-address=<WAN1-IP> table=to-WAN1
add action=lookup-only-in-table dst-address=<WAN1-IP> table=to-WAN1

add action=lookup-only-in-table src-address=<WAN2-IP> table=to-WAN2
add action=lookup-only-in-table dst-address=<WAN2-IP> table=to-WAN2

add action=lookup-only-in-table src-address=<LAN-POOL-IP-TO-WAN1> table=to-WAN1
add action=lookup-only-in-table dst-address=<LAN-POOL-IP-TO-WAN1> table=to-WAN1

add action=lookup-only-in-table src-address=<LAN-POOL-IP-TO-WAN2> table=to-WAN2
add action=lookup-only-in-table dst-address=<LAN-POOL-IP-TO-WAN2> table=to-WAN2
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 5:14 pm

Thanks @rextended. I saw that you mentioned this before, but I don't understand how this helps me achieve forcing router originated PPTP connections to a specific IP out of a specific WAN? Can you be more detailed. In other places on the forum folk have repeatedly stated that using /route rules causes problem. Could you explain line by line how the config you posted works and how I might apply it to my specific need? I used mangle and route-mark because it appears the only way to identify router outbound PPTP.

By the way the setup I have works perfectly for LAN clients, I can switch individual LAN clients to either WAN simply by enabling or disabling Mangle rules.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 5:22 pm

Notice for be clear: I do not use 7 beta

My is just a hint, obviously.

I use everytime the "rule", but sometime for granularity must be force to still use mangle
All can be a personal choice, until the traffic is low...

See this example for pptp:
/ip route rule
add action=lookup-only-in-table interface=<pptp-something> table=which_table_i_want_pptp_to_use
But obviously the routing tableS must be all correctly filled.
Last edited by rextended on Mon Jul 19, 2021 6:09 pm, edited 1 time in total.
 
User avatar
Ferrograph
Member Candidate
Member Candidate
Topic Author
Posts: 154
Joined: Wed Mar 07, 2012 4:05 am

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 6:05 pm

@rextended I tried adding the rule you suggest but this did not cause the outbound connection to be made from WAN2. The PPTP client did still connect to the remote end but became non-functional.

I dont think a rule specifying a PPTP client interface has any effect on where the router pptp-client makes the outbound connection.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: default route prevents use of additional LTE passthrough WAN

Mon Jul 19, 2021 6:09 pm

Without working directly on machine, by forum all is useless...
Are just examples.

Who is online

Users browsing this forum: abdulschizo, Ahrefs [Bot] and 82 guests