Hello,
I’m using 2 modems with 2 sim
I want to use SIM1 for only open vpn - so when I try to make a connection using tcp port 1194 he will use it
and
SIM2 for only L2TP which is udp 1701
adn default sim (all other port) will be SIM1
I made the firewall mark
and also can I select in which port the router will go out?
meaning when he try to open the open-vpn I can see the port is 52078 , and after reboot it’s 52033 - can I make a “static” port for this 55555 (for example)?
Be more verbose about what means “doesn’t work”. If you want that only the required SIM is used and if it goes down, prevent the connection which should use it from using the other one, you have to add a route routing-mark=SIMx type=blackhole. The point is that if there is no active route matching the routing-mark, the unmarked routing table is used.
As for locking a client TCP connection to a single source port, it can be done using a big hammer but it is a bad idea as client side ports must not be reused for connection to the same server for about 2 minutes after the previous connection has ended. So you can use a src-nat rule with to-ports=55555, but if the first session established fails for some reason, you’ll have to disable the client for 3 minutes to let the server “recover” from the previous session and start accepting incoming connections from your.ip.add.re.ss:55555 again.
does it mean that if SIM2 is not online it will work from SIM1? and not get stuck ? ot will not work at all -
so all the L2TP connection (UDP 1701 ) will not work from this router?
I coudn’t understand
and about the outgoing port - I understadn why it’s a bad idea
Thanks ,
That’s because you haven’t specified what you expect from the setup. As you said you wanted to bind each VPN client to a single SIM, I was expecting you want to prevent each VPN client from using the other SIM if its preferred one fails, so I’ve told you how to implement this prevention. If you wanted something else, explain more precisely what behaviour you expect.
OK
I want to use
L2TP from SIM1
OpenVPN from SIM2
all other connection - will be close
and if SIM2 is not working - then the router will not have OpenVPN
the L2TP \ OPEN VPN are form the router only - not from a computer connected to it
Thanks .
You mean that the router itself can not connect anywhere else except to L2TP server via SIM1 and to OpenVPN server via SIM2, or that all LAN clients of the router will only connect to the world via the L2TP uplink of the router or the OpenVPN uplink of the router, but never directly without VPN?
So the reverse case is permitted? Is SIM1 is not working, the L2TP connection is allowed to use SIM2?
OK. So we are coming back to the original question - what exactly means “doesn’t work”? Your mangle rules with routes should normally be enough. My blackhole routes only extend that by preventing each VPN client from using the wrong SIM if the proper one is unavailable.
So what actually works different than expected? The VPN services do not come up, or they come up when the proper SIM is down?
I thought about it and I reset to defualt the router to start from a clean setup
and now it’s working
SIM1 is used for L2TP
SIM2 is used for OpenVPN
now my question is about the blackhole
do I need it?
I don’t want that if SIM1 is not connected it will be used for OPENVPN
this are the routes I ahve :
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A S 0.0.0.0/0 SIM1 1
1 A S 0.0.0.0/0 SIM2 1
2 A S 0.0.0.0/0 SIM1,SIM2 1
3 ADC 10.0.0.0/24 10.0.0.1 Bridge 0
4 ADC 10.112.112.126/32 10.16.15.198 SIM1 0
5 ADC 10.112.112.127/32 10.132.117.7 SIM2 0
Use /ip route print detail to show also the routing-mark attributes of the routes.
The sole purpose of the routes with type=blackhole distance=2 routing-mark=SIMx is to prevent the situation when the interface bound to SIMx goes down, so all routes via SIMx become inactive, so no route with routing-mark=SIMx will be active. For packets with a routing-mark for which no active route with that routing-mark exists, the routing uses the default routing table, which consists of routes with no routing-mark. If the blackhole route with the matching routing-mark is there, it becomes active when the “real” route goes down, so the fallback to default routing table doesn’t happen.
that mean that if the mark is not SIM1\SIM2 it will not go out to the internet , right?
so if I understand what you explain :
when I use blackhole - tham mean that everything that is mark as SIM1 will first try to go out using rule 0 (SIM1)
then will go to the blackhole rule , so he will not try to go using another SIM \ rule that have 0.0.0.0? - is this correct?
even if it’s only mark to use that connection with SIM2?
Wrong. Packets with no routing-mark assigned can use any SIM. Plus this way some packets (NOT connections) with no routing-mark will use SIM 1 and other ones will use SIM 2, but as each SIM has a different public IP after all the NATs, the connections will suffer from losses. This combined route is a result of both LTE interfaces adding a default route with the same gateway IP (which is actually not used for anything but causes this confusion) and the same value of distance. In NAT-less environments this would be just fine; with NAT, you have to set default-route-distance of one of the /interface lte apn to 2 to separate the two default routes. Or, if you don’t need to connect anywhere than the VPN servers, set add-default-route to no.
correct.
I don’t understand this additional question.
Packets marked with SIM1 are sent via an active route with connection mark SIM1, and out of those, the best matching dst-address (which in your case doesn’t matter as all your routes with routing-mark have the same dst-address, 0.0.0.0/0).
If SIM1 is down, all routes with that SIM as gateway become inactive, so routes with same dst-address and lowest value of distance in each table (identified by routing-mark) become active. In this case, it is the blackhole route for routing-mark=SIM1 and the route with gateway=SIM2 for no routing mark.
The same applies when you swap SIM1 and SIM2 in the above paragraph.
so just to be 100% :
After I mark the port and select which gateway to use - I make its distance 1 - so it’s the first one to use
then I make the same route rule but with distance 2 using blackhole
so if from some reason SIM1 in not active \ working - it will bot go out using another SIM
but then no connection was made from the openVPN\L2TP client . but when I enable the rule - they all came up (using the correct SIM)
As I understand - this rule give route to all other Un-Marks routing (all other ports I didn;t mark in the mangle?)
I’m working in NAT (the server is public IP )
did I miss understand you
You haven’t misunderstood me, but the way how mangling and policy routing works for locally originated packets is extremely complicated and anything but intuitive. I didn’t want to dive into it not to confuse you but it seems to be necessary.
For transit (forwarded) packets, routing-mark is normally assigned in chain=prerouting, so at the moment of route lookup, the routing-mark can already be taken into account.
For locally generated (output) packets, you can only assign the routing-mark in chain=output to which, however, the locally originated packet gets only after it has alrady been routed, as you can see at this page (see “router processes” at the rightmost side of Overall Packetflow Diagram, then scroll to Routing Diagram, and then scroll to Packet Flow Chains just below to get the complete information). So there is a step called “routing adjustment” which is another round of routing which is taken if a routing-mark has been assigned in chain=output.
So by removing the “routing-mark-less” route completely, the locally output packets cannot be routed anywhere in the first round of routing, which causes them to be dropped before even reaching the chain=output of /ip firewall mangle.
But that’s not all; all routes have a pref-src attribute which, unless you set it manually, is the local address of the router in the gateway’s subnet. The choice of source address of a locally originated packet is done according to this parameter during the first round of routing, and the “routing adjustment” step does not change it. So although it seems redundant at first glance, you need to configure an action=masquerade rule in chain=srcnat of /ip firewall nat for each out-interface you use for policy routing of locally output packets, as otherwise the PPP link behind the SIM will drop the packet, and if it eventually doesn’t, then the response packet will be sent to a wrong address and never reach you.
So you can use an /interface bridge, with no IP address and no physical interfaces attached, as a “routing-mark-less” default gateway (but don’t ask me what the pref-src will be in this case), and regardless whether you do or whether you keep the default routes added by /interface lte apn, you must add the two following rules unless you already have them: