Community discussions

 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Static Default Route - I'm missing something

Sat May 05, 2018 12:09 am

So this is a follow on (but discrete) question from another thread - I think I'm missing something obvious.

1) I have 2 dynamic default routes on my Hex. (i) with a metric of 2 via the Eth1 WAN interface (ii) with a metric of 1 via an L2TP interface
2) I have srcnat masquerade NAT rules in place for both out interfaces (the defconf WAN and I added one for the L2TP)

As you would expect, everything goes over the L2TP tunnel, except when it drops - then everything following the direct route out of the WAN Eth1 connection. Exactly as I wanted it to.

Question: How can I identify specific clients (static IP's) to ALWAYS follow the less preferable default route of direct out of the WAN regardless if the L2TP is up or not.

I tried Using a mangle mark-routing 'BYPASSVPN' , and I created a new static default route for this routing mark - 0.0.0.0 with a gateway of Eth1.
It seems that with this in place, everything 'routes' like its supposed to , but if I run a traceroute it goes out the correct interface but never passes the next hop (which I think is the ISP gateway - but thats a guess).

Am I going about this the right way? or am I missing something do with the way the pre-routing mangle and the routing process is working when I specify the Eth1 as the gateway?
 
anav
Forum Guru
Forum Guru
Posts: 2900
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Static Default Route - I'm missing something  [SOLVED]

Sat May 05, 2018 12:52 am

Well it should work....
IP mangle.
new routing mark-bypassvpn source-address-list =(list created in IP firewall lists to identify which IPs) "bypasslist" chain=prerouting
IP route
destination=0.0.0.0/0 gateway=gateway_IPaddress_ISP1 mark route=bypassvpn

maybe try a two step mangle rule
First step marks new connections for those source LANIP addresses.
Second step route marks them.
and then make the necessary route rule........

Maybe this two step is unnecessary but maybe more efficient??
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 1:08 am

Question: How can I identify specific clients (static IP's) to ALWAYS follow the less preferable default route of direct out of the WAN regardless if the L2TP is up or not.
The question is whether you really need some clients to send packets to a given destination via the L2TP tunnel and some other clients to send them to the very same destination using the usual gateway or Eth1 instead. If yes, you do need the mangle rule as you have found out. If you just need an exception from the default route for that destination, for any client, just add a dedicated route there to the routing table, as a route with a more precisely defined dst-address (longer prefix, i.e. mask with more 1 bits) always beats a route with less precisely defined dst-address (shorter prefix, i.e. mask with less 1 bits).

It seems that with this in place, everything 'routes' like its supposed to, but if I run a traceroute it goes out the correct interface but never passes the next hop (which I think is the ISP gateway - but thats a guess).
Am I going about this the right way? or am I missing something do with the way the pre-routing mangle and the routing process is working when I specify the Eth1 as the gateway?
From where do you traceroute? From the client or from the Mikrotik?

If from the Mikrotik, bear in mind that for locally originated packets do not pass chain=prerouting; to mark them, you have to place the same marking rules to chain=output. See this picture for details. Don't miss the "routing adjustment" in the end of the Output chain.

If from the client, I don't have any answer.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 1:14 am

So I think anav pointed out the minor flaw in my plan - if I point the mark-routing static route at the ISP gateway via the ISP gateway IP address then everything works (thanks anav!!)

I was originally routing the static route at the Eth1 interface, on the understanding that the IP address at the other end might be dynamic. I dont suppose there's some smart way to say 'via whatever the gateway address is on Eth1' from another static route?
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 1:23 am

So I think anav pointed out the minor flaw in my plan - if I point the mark-routing static route at the ISP gateway via the ISP gateway IP address then everything works (thanks anav!!)
It wasn't clear to me from the wording that "gateway of Eth1" means "Eth1 as route's gateway".

I was originally routing the static route at the Eth1 interface, on the understanding that the IP address at the other end might be dynamic. I dont suppose there's some smart way to say 'via whatever the gateway address is on Eth1' from another static route?
There is but it seems that Mikrotik doesn't use it. It is called ICMP router discovery. This is what permits most linux machines to set an interface as a gateway of a route. In Mikrotik, you can use the interface as a gateway of a route only on point-to-point links such as tunnels.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 1:27 am

Got it - thanks for the clarification everyone! We're up and running (with a much simpler config!)
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 1:50 am

First step marks new connections for those source LANIP addresses.
Second step route marks them.
and then make the necessary route rule........

Maybe this two step is unnecessary but maybe more efficient??
@anav,
two step marking has two uses:
  • to evaluate complex sets of match conditions only once, when connection-marking the initial packet of the connection, and then route-marking every packet of the connection in a given direction up to the connection mark alone (including the first packet in most scenarios). This is the "efficiency" purpose.
  • to set routing marks for LAN->WAN packets properly for connections established in WAN->LAN direction, i.e. when your router is doing port forwarding from clients in the internet to some server in LAN and you need to send that server's responses back the right way and src-nated to the right public IP address.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 2:07 am

Follow up question Sindy. As I understand it , as soon as I touch policy based routing with a mark-routing mangle rule, I can’t use the fasttrack feature (hence I have that default firewall rule disabled).

Is there anyway I can still leverage fasttrack for the non-marked packets or am I just stuck with CPU handling of every packet to match the mangle rule on the prerouting?
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 12:09 pm

Follow up question Sindy. As I understand it , as soon as I touch policy based routing with a mark-routing mangle rule, I can’t use the fasttrack feature (hence I have that default firewall rule disabled).

Is there any way I can still leverage fasttrack for the non-marked packets or am I just stuck with CPU handling of every packet to match the mangle rule on the prerouting?
Sure there is. But to do that, it is not sufficient to use only routing marks, you have to use connection marking. And once you do, it is best to base routing marking on connection marking as well.

The action=fasttrack-connection rule in /ip firewall filter matches on both upload (LAN to WAN) and download (WAN to LAN) packets. So you have to mark the whole connection, i.e. all its packets in both directions, as you mangle its initial packet if you want to use non-default handling for that connection. Connections you don't mark when they begin will be handled the default way.

Therefore, start by identifying (using a qualified guess or mangle rule statistics depending on your particular case) the kind of traffic which has the highest volume. This is the kind of traffic you want to use default handling for, so that you wouldn't need to assign routing marks to it, so that you could use fasttracking for it. All other kinds of traffic will get some connection marks and, eventually, also routing marks based on them.

Then, you add a match condition connection-mark=no-mark to the condition list of the action=fasttrack-connection chain=forward connection-state=established,related rule in /ip firewall filter. Mission completed, only packets without any connection mark will now be fasttracked, so once you set up the connection marking rules properly, you can enable this action=fasttrack-connection rule.

Now the details.
  • You must assign (or not) the connection mark only when mangling the initial packet of each connection, so the action=mark-connection rules must conform to connection-state=new match condition; this can be ensured either by placing that condition into each rule or by preventing non-conformant packet from reaching that rule
  • for upload packets you need to add a routing mark also to the initial packet which has just been connection-marked. As you cannot assign both routing mark and connection mark using a single rule, the action=mark-connection rules must not stop the handling of the packet in prerouting, hence add passthrough=yes to them
  • you want to connection-mark each connection's initial packet only once, so if you use more than one non-default handling and hence need more than one connection mark, it is always better to put a connection-mark=no-mark match condition to all action=mark-connection rules except the first one to avoid hard to understand mistakes. Normally you are used to that if rule N matches on src-address=192.168.0.3, rule N+1 just below it may match on src-adddress=192.168.0.1-192.168.0.9 and it will never actually act on packet with source address 192.168.0.3 because rule N won't let the packet with that source address ever reach rule N+1. This usual behaviour doesn't work if rule N has passthrough=yes, which is necessary so that the packet could reach some later action=mark-routing rule.
To speed up the processing as much as possible also for packets which are not fasttracked, you need to process each packet by the least possible number of rules in mangle, which means that the action=mark-routing rules should be as close as possible to the beginning of the chain, but at the same time you need them after the action=mark-connection rules, which simply means you have to put them to the chain twice.

So it's time for an example. Assuming you have one default handling and two non-default ones, your mangle rules would like as follows:
/ip firewall mangle
add chain=prerouting connection-state=established,related connection-mark=no-mark action=accept # if a mid-connection packet has no connection mark, it needs the default handling
add chain=prerouting connection-state=established,related in-interface=your-wan # download packets MUST NOT be routing-marked
add chain=prerouting connection-mark=handling-A action=mark-routing new-routing-mark=handling-A # passthrough=no is a default behaviour but you can state it explicitly
add chain=prerouting connection-mark=handling-B action=mark-routing new-routing-mark=handling-B # same like above

#only initial packets of connections (plus some garbage) get here past the rules above
add chain=prerouting ...list of classifying match conditions for handling A... connection-state=new action=mark-connection new-connection-mark=handling-A passthrough=yes
add chain=prerouting ...list of classifying match conditions for handling B... connection-mark=no-mark connection-state=new action=mark-connection new-connection-mark=handling-B passthrough=yes

#initial packets of connections which evaded both the rules above get here with no connection mark; we just repeat the mark-routing rules above
add chain=prerouting connection-mark=handling-A action=mark-routing new-routing-mark=handling-A
add chain=prerouting connection-mark=handling-A action=mark-routing new-routing-mark=handling-B
NB: connection marks, routing marks and packet marks use separate name spaces, so connection mark XYZ has no relationship to routing mark XYZ unless a mangle rule assigns the latter based on the former.

EDIT to have everything in a single post: if the various handlings are used to control multi-WAN arrangements, and if the router itself or devices on its LAN should act as servers accessible by clients in the internet, it is necessary to assign connection marks also to initial packets coming in via the WAN interface, so that the response packets would be routed through the same WAN interface. The default handling may use one of the WAN interfaces as outbound route; in such a case, connections initiated by packets coming in via that WAN interface get no connection mark.
Last edited by sindy on Wed May 22, 2019 7:21 pm, edited 7 times in total.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 6:38 pm

Perfect. Thanks for the detailed response - I’ll try reworking the config today!


Sent from my iPhone using Tapatalk
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sat May 05, 2018 11:33 pm

So I think its 'sort of working' Sindy - all the fasttrack non-marked connections are working fine, but I'm still seeing some of the connections I expected to be marked as flowing through fasttrack without a connection mark.

The configuration is pretty simple in terms of the mangle - just one non-default handling, and by source IP address;
/ip firewall mangle 
add action=accept chain=prerouting comment="Process mid-connection with no connection mark" connection-mark=no-mark connection-state=established,related

add action=mark-routing chain=prerouting comment="MarkRouting BypassVPN Early" connection-mark=Bypass-VPNconn new-routing-mark=BYPASSVPNroute passthrough=no

add action=mark-connection chain=prerouting comment="Connection-Mark for Clients Bypassing the VPN" connection-state=new new-connection-mark=Bypass-VPNconn passthrough=yes src-address=192.168.118.132

add action=mark-routing chain=prerouting comment="MarkRouting BypassVPN Late" connection-mark=Bypass-VPNconn new-routing-mark=BYPASSVPNroute passthrough=no
So my interpretation is that any new connections from 192.168.113.132, will get a new connection mark which in turn will become a new routing mark. However, for some reason when I run like this, that client works for some sites and then fails on others. If I change it back to a simple mark-routing with the fasttrack disabled then it works. Weird. I might try some reboots in between config changes - it could be that I'm running on the latest RC version of routerOS I guess. More testing needed!! Thanks again.
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 12:29 am

So my interpretation is that any new connections from 192.168.113.132, will get a new connection mark which in turn will become a new routing mark. However, for some reason when I run like this, that client works for some sites and then fails on others. If I change it back to a simple mark-routing with the fasttrack disabled then it works. Weird. I might try some reboots in between config changes - it could be that I'm running on the latest RC version of routerOS I guess. More testing needed!! Thanks again.
May I see the complete /ip firewall export (with public addresses substituted ny something meaningful if needed)? The marking rules seem fine to me too.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 7:37 am

Here you go - thankyou again for taking the time to look this one over!

To clarify the setup I have an L2TP/IPSEC VPN interface which is my preferred default route when it is up and running, and if that interface drops it follows the default route direct via the ISP (so 2 dynamic default routes with the ISP learned one artificially set to distance:2). - hence the 2 masquerade rules.
What I'm trying to do with the connection-marking is fasttrack the majority of the traffic that goes over the default route (L2TP or direct, whichever is the currently preferred seems to be working great on that part- thanks!), but for a handful of specific clients I want them to follow this direct-to-ISP route all of the time , hence the connection and route marking of BYPASSVPN.

I did solve one riddle of why some sites appeared to work - yahoo.com / cnn.com / mikrotik.com etc - they all have IPv6 addresses which of course aren't relevant here!

Also after rebooting, I can confirm that the test client (192.168.118.143 here) no longer shows any connection that do not have the connection mark so it appears to be correctly identifying all new connections and marking them. From what I can see on the outbound connections, the masquerade is working too because the reply-to-address is the ISP-provided address:port for these connections, and not the L2TPendpoint:port (as it is for the VPN connected clients)
/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" dst-limit=30,30,dst-address/1m40s limit=30,30:packet protocol=icmp src-address=192.168.118.0/24
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-mark=no-mark 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=WAN

/ip firewall mangle
add action=accept chain=prerouting comment="Process mid connection with no connection mark" connection-mark=no-mark connection-state=established,related
add action=mark-routing chain=prerouting comment="MarkRouting BypassVPN Early" connection-mark=BYPASSVPN-conn new-routing-mark=BYPASSVPN-route passthrough=no
add action=mark-connection chain=prerouting comment="Connection-Mark for Clients Bypassing the VPN" connection-state=new disabled=yes new-connection-mark=BYPASSVPN-conn passthrough=yes src-address=\
192.168.118.143
add action=mark-routing chain=prerouting comment="MarkRouting BypassVPN Late" connection-mark=BYPASSVPN-conn new-routing-mark=BYPASSVPN-route passthrough=no

/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin NAT" disabled=yes dst-address=192.168.118.0/24 src-address=192.168.118.0/24
add action=masquerade chain=srcnat comment="defconf: masquerade for ISP routed traffic" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="srcnat for HideIPVPN routed traffic" out-interface=l2tp-out1


For clarity , here is the current routing table (top entry is for the BYPASSVPN-route routing-mark. Public addresses changed to .99;
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE

 0 A S  ;;; Static route via local ISP for BYPASSVPN-route

        0.0.0.0/0                          70.95.64.99                1
 1 ADS  0.0.0.0/0                          l2tp-out1                 1
 2  DS  0.0.0.0/0                          70.95.64.99                2
 3 ADC  10.0.0.2/32        10.7.4.199      l2tp-out1                 0
 4 ADC  70.95.64.0/19      70.95.93.199    ether1-EXTERNAL           0
 5 ADS  104.237.61.2/32                    70.95.64.99                0
 6 ADC  192.168.118.0/24   192.168.118.1   bridge-LAN                0
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 8:46 am

Well, I am a bit lost in all that information.

You say that in order to clean up the connection table, you have rebooted the router. Well, you could instead have removed the connections of the test client (and thus broken for the client so it would have had to re-establish them from scratch) using something like
/ip firewall connection remove [find src-address~"192.168.118.143"]
but that's not the point here.

Now after the reboot, you say that all connections from 192.168.118.143 are connection marked, but do you also say that nevertheless some of them (or maybe even all) get fasttracked?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 9:33 am

No , sorry for too much info ;-)
The connection marking is working correctly for all connections from the client. But despite the connection and routing apparently going through the correct srcnat and routing table entry, the client is unable to reach any external sites.

Back to your original comment, I suspect this is a firewall filter issue - I guess I have to eliminate them one by one.
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 10:05 am

Back to your original comment, I suspect this is a firewall filter issue - I guess I have to eliminate them one by one.
No, it's my fault.

When assigning routing marks in mangle, you must only mark upload packets. What happens now is that packets which come through WAN get a routing mark too, and the routing table BYPASSVPN-route doesn't contain the routes to local subnets, so the default route of that table sends the responses back to the WAN.

I was explaining this to someone here less than a week ago :-D

So I've edited my example in the post above to accept "established" and "related" download packets before reaching the connection mark -> routing mark translation rules.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 9:23 pm

Sindy - do you have an Amazon wish-list or something I can see? ;-) Can't thank you enough - I've been staring at this for a month now, and you've solved it in 2 posts. Thankyou again.

Everything is working exactly as planned - one last and final question... (I promise).
One of the main reasons for these clients bypassing the VPN is they establish some dynamic dstnat for remote access (here is a copy of what they typically do via uPNP);
 3  D ;;; upnp 192.168.118.99: WD2go
      chain=dstnat action=dst-nat to-addresses=192.168.118.99 to-ports=80 protocol=tcp dst-address=70.95.93.99 in-interface=ether1-EXTERNAL dst-port=9091 

 4  D ;;; upnp 192.168.118.99: WD2goSSL
      chain=dstnat action=dst-nat to-addresses=192.168.118.99 to-ports=443 protocol=tcp dst-address=70.95.93.99 in-interface=ether1-EXTERNAL dst-port=443 
Obviously in this case, the in-interface is external-Eth1- so do I just need a separate connection-mark for 'new' connections where the internal client address is the destination rather than the source? Or is there something I can easily do to the existing rules to accomodate any dstnat like the above.
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 9:55 pm

do you have an Amazon wish-list or something I can see?
Well, if you know what is necessary to do to force-synchronize an Oracle database cluster after it has diverged...

Obviously in this case, the in-interface is eternal - so do I just need a separate connection-mark for 'new' connections where the internal client address is the destination rather than the source? Or is there something I can easily do to the existing rules to accomodate any dstnat like the above.
Gadgets opening ports for http access from outside, hmmm :-) Are they at least decent enough to look like those big hollow wooden animals?

To the question, as you've guessed, it is enough to mark the connections with the same connection-mark if their initial packets come in via the respective WAN port. Just add the rule below right before or right after the other action=mark-connection one.
add action=mark-connection chain=prerouting comment="Connection-Mark for Clients Bypassing the VPN" connection-state=new new-connection-mark=Bypass-VPNconn passthrough=no in-interface=ether1-EXTERNAL
This time it is the passthrough=no which prevents these packets from getting a routing mark.

Of course the decision whether to permit these connections or not is up to the /ip firewall filter.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Pericynthion
newbie
Topic Author
Posts: 37
Joined: Tue Jan 02, 2018 8:54 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 10:30 pm

Well, if you know what is necessary to do to force-synchronize an Oracle database cluster after it has diverged...
Depends - is it a RAC cluster thats divided, or has Data Guard gone rogue..
.
Gadgets opening ports for http access from outside, hmmm :-) Are they at least decent enough to look like those big hollow wooden animals?
All low risk stuff - I'm trying to become more automated operations driven, so I can live without manually managing port-forwards for a living
.
To the question, as you've guessed, it is enough to mark the connections with the same connection-mark if their initial packets come in via the respective WAN port. Just add the rule below right before or right after the other
Thanks again - I feel like I've actually achieved something today!
 
sindy
Forum Guru
Forum Guru
Posts: 3760
Joined: Mon Dec 04, 2017 9:19 pm

Re: Static Default Route - I'm missing something

Sun May 06, 2018 10:45 pm

Depends - is it a RAC cluster thats divided, or has Data Guard gone rogue..
I suppose a Data Guard, one Primary and one Standby with all those flashbacks, managed recovery, "restore" and "recover" commands in RMAN which have to be done both (and restore succeeds but recovery fails), and it was enough to shut down everything and then start it again to end up with an "unresolvable gap" and "restore required" (after shutting down the application first so the database didn't actually get updated). For me everything there is new and different from other database engines I've seen so far, so maybe it is all clear and best of breed but I'm totally lost in that and it drives me mad. I will not lose any actual data now, only time, if I reinstall everything from scratch, but I'm afraid what would I do should something similar eventually happen later.

But something is telling me this is not the right channel do discuss this :-)
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1301
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Static Default Route - I'm missing something

Mon May 07, 2018 12:48 am

Depends - is it a RAC cluster thats divided, or has Data Guard gone rogue..
... but I'm totally lost in that and it drives me mad....

Wow, so you are human after all :D
MTCNA, MTCTCE, MTCRE & MTCINE
 
mkx
Forum Guru
Forum Guru
Posts: 2590
Joined: Thu Mar 03, 2016 10:23 pm

Re: Static Default Route - I'm missing something

Mon May 07, 2018 11:36 am

Depends - is it a RAC cluster thats divided, or has Data Guard gone rogue..
... but I'm totally lost in that and it drives me mad....
Wow, so you are human after all :D
My bet is on highly advanced AI :lol:

Other than that ... hats off, sindy!
BR,
Metod

Who is online

Users browsing this forum: Google [Bot] and 49 guests