Community discussions

 
wireless6262
just joined
Topic Author
Posts: 5
Joined: Sat Dec 08, 2018 1:30 pm

ICMP Firewall Potential Bug

Fri Aug 23, 2019 6:22 pm

I am currently running RouterOS 6.45.1 and we seem to be having an issue with ICMP. When our firewall is enabled we can not ping or traceroute from external to our network to an IP on our network. We have firewall rules in place to allow the ICMP protocol, so it should work. If the external IP us on the all-access SAFE LIST then ping and traceroute works and also when we disable the entire firewall it works.

So it looks like it might be a potential bug in the RouterOS - anyone else having this issue?
 
Sob
Forum Guru
Forum Guru
Posts: 4806
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP Firewall Potential Bug

Fri Aug 23, 2019 11:27 pm

It's possible. But it's also possible that your firewall is not configured exactly as you think it is. But since nobody here knows what you have there...
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
sindy
Forum Guru
Forum Guru
Posts: 3959
Joined: Mon Dec 04, 2017 9:19 pm

Re: ICMP Firewall Potential Bug

Fri Aug 23, 2019 11:53 pm

In another words: post the complete export of your firewall rules if you want a relevant analysis rather than a guess.
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.
 
anav
Forum Guru
Forum Guru
Posts: 3120
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: ICMP Firewall Potential Bug

Sat Aug 24, 2019 12:03 am

Logic,
- firewall off: works
- firewall rule that allows external user: works
- otherwise blocked
what by magic???????

Answer, its your firewall st_p_d!

Clearly you have a rule that blocks external access to the router which is a good thing LOL, but if you have an allow ICMP rule I will guess its after the rule that blocks ICMP.
In any case, its just a wild-assed guess.

/export hide-sensitive file=yourconfig23Aug as noted by my esteemed colleagues ( the reciprocal may not be true LOL)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
wireless6262
just joined
Topic Author
Posts: 5
Joined: Sat Dec 08, 2018 1:30 pm

Re: ICMP Firewall Potential Bug

Mon Aug 26, 2019 12:02 pm

As requested:

/ip firewall address-list
add address=X.X.X.X comment="MS" list=SAFE_IP
add address=X.X.X.X/24 comment="DIRECT ACCESS PORT ETH 8" list=SAFE_IP
add address=X.X.X.X/24 comment=VPN list=SAFE_IP
add address=X.X.X.X comment="HW Office" list=SAFE_IP
/ip firewall filter
add action=drop chain=input comment="Drop Invalid Packets" connection-state=\
invalid
add action=accept chain=input comment=\
"Allow traffic from router if established or related" connection-state=\
established,related
add action=accept chain=input comment="Allow ICMP - all" connection-state=\
established,related,new ipv4-options=any protocol=icmp
add action=accept chain=input comment="Allow all if on SAFE_IP address list" \
src-address-list=SAFE_IP
add action=accept chain=input comment="Allow IKE for IPSEC" dst-port=500 \
protocol=udp
add action=accept chain=input comment="Allow IPSEC NAT-T" dst-port=4500 \
protocol=udp
add action=accept chain=input comment="Allow L2TP" dst-port=1701 protocol=udp
add action=accept chain=forward ipv4-options=any protocol=icmp
add action=accept chain=forward comment="Iona Server" dst-address=X.X.X.X \
dst-port=80,443,8443 protocol=tcp
add action=drop chain=input comment="Drop everything else"
add action=accept chain=input comment="Allow ping to X WAN" disabled=yes \
dst-address=X.X.X.X protocol=icmp
add action=accept chain=input comment="Allow ping to X WAN1" disabled=yes \
dst-address=X.X.X.X protocol=icmp
add action=accept chain=input comment="Allow ping to X WAN2" disabled=yes \
dst-address=X.X.X.X protocol=icmp
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=X.X.X.X dst-port=80,443,8443 \
protocol=tcp to-addresses=X.X.X.X
add action=masquerade chain=srcnat out-interface=sfp-sfpplus1
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether1
 
Sob
Forum Guru
Forum Guru
Posts: 4806
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP Firewall Potential Bug

Mon Aug 26, 2019 3:34 pm

You want this instead of your rule:
/ip firewall filter
add action=accept chain=input comment="Allow ICMP - all" protocol=icmp
No need to watch for connection-state, because at position where the rule is, everything is either new or untracked, all other states are already handled by previous rules. And ipv4-options doesn't look like anything you need (I had to look at manual, to know what it does).

Also, since default action is accept, your forward chain currently doesn't do anything, everything is allowed.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
wireless6262
just joined
Topic Author
Posts: 5
Joined: Sat Dec 08, 2018 1:30 pm

Re: ICMP Firewall Potential Bug

Mon Aug 26, 2019 7:43 pm

Thats great! I have replaced my rule with your rule and ping is now working from IP addresses external to the network and also IPs that are not on the SAFE LIST, which is great!

However, traceroute still seems to be an issue and reaches the hop before my router then timeouts - is there something else i need to add for traceroute into the network to work?
 
mkx
Forum Guru
Forum Guru
Posts: 3185
Joined: Thu Mar 03, 2016 10:23 pm

Re: ICMP Firewall Potential Bug

Mon Aug 26, 2019 8:27 pm

Different traceroute programmes use different packet types. Some use same ICMP packets (windows does it IIRC), some use some UDP (linux does it).
BR,
Metod
 
wireless6262
just joined
Topic Author
Posts: 5
Joined: Sat Dec 08, 2018 1:30 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 12:03 am

What is my solution to allow traceroutes into my network?
 
Sob
Forum Guru
Forum Guru
Posts: 4806
Joined: Mon Apr 20, 2009 9:11 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 12:19 am

Your whole forward chain is:
/ip firewall filter
add action=accept chain=forward ipv4-options=any protocol=icmp
add action=accept chain=forward comment="Iona Server" dst-address=X.X.X.X dst-port=80,443,8443 protocol=tcp
add action=accept chain=forward <-- implicit default action (not shown as part of config)
You can get rid of ipv4-options=any like with input, but it doesn't really matter, because router already does not block anything, and you can't make it any more open than this.

For anyone not seeing what happens on your router, it's difficult to tell what's wrong. If I was you, I'd do a test from some external device. Look for packets from and to its address and maybe you'll see something useful.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
mkx
Forum Guru
Forum Guru
Posts: 3185
Joined: Thu Mar 03, 2016 10:23 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 9:21 am

What is my solution to allow traceroutes into my network?

If the traceroute uses UDP packets, it mostly selects a random destination UDP port and you can't really do anything to make it work if you don't want to open up just everything.

If traceroute uses TCP packets (there's a tcptraceroute in linux), then it will display the whole path like this:
 # tcptraceroute www.cnn.com 443
Selected device eno1.42, address 192.168.42.10, port 35079 for outgoing packets
Tracing the path to www.cnn.com (151.101.13.67) on TCP port 443 (https), 30 hops max
 1  [redacted hop A]
 2  [redacted hop B]
 3  [redacted hop C]
 4  80.156.163.65  16.739 ms  16.738 ms  16.834 ms
 5  80.157.130.14  16.511 ms  16.283 ms  16.339 ms
 6  151.101.13.67 [open]  16.544 ms  16.534 ms  16.327 ms

and compare it to UDP traceroute:
# traceroute www.cnn.com
traceroute to turner-tls.map.fastly.net (151.101.13.67), 64 hops max
  1   [redacted hop A]
  2   [redacted hop B]
  3   [redacted hop C] 
  4   80.156.163.65  16.902ms  16.807ms  17.045ms 
  5   *  *  *
It doesn't show any hop further. So it seems that node at hop #5 is filtering traffic (either statefull firewall or, more likely, stateless firewall).

And compare it to ICMP traceroute:
# traceroute -I www.cnn.com
traceroute to turner-tls.map.fastly.net (151.101.13.67), 64 hops max
  1   [redacted hop A] 
  2   [redacted hop B] 
  3   [redacted hop C] 
  4   80.156.163.65  16.688ms  16.709ms  16.480ms 
  5   80.157.130.14  17.749ms  16.279ms  16.305ms 
  6   151.101.13.67  16.651ms  16.269ms  16.282ms

When you traceroute a firewalled and NATed address, then UDP traceroute will stop at firewall's address ... either without a reply if firewall filter rule uses action=drop or with reply (but with flag H! meaning probes are hitting firewall) if firewall filter rule uses action=reject. ICMP traceroute will behave similarly. TCP traceroute, however, will pass the firewall if the dst-port is forwarded and traceroute will show replies seemingly coming from same address:
# tcptraceroute <firewalled FQDN> 443
Selected device eno1.42, address 192.168.42.10, port 35079 for outgoing packets
Tracing the path to <firewalled FQDN> (<redacted DST address>) on TCP port 443 (https), 30 hops max
 1  [redacted hop A] 
 2  [redacted hop B] 
 3  [redacted hop C] 
 4  88.200.2.182  4.978 ms  2.097 ms  0.482 ms
 5  91.220.194.114  0.974 ms  0.903 ms  1.868 ms
 6  <redacted intermediate hop>  2.376 ms  1.508 ms  2.288 ms
 7  <redacted DST address> 1.286 ms  1.336 ms  1.234 ms
 8  <redacted DST address> [open]  1.515 ms  1.990 ms  2.154 ms
Note the last hop, which returns from same IP address as hop earlier, but says [open] because it's hitting the actual server (behind NAT firewall) which is replying on port 443 ...
BR,
Metod
 
wireless6262
just joined
Topic Author
Posts: 5
Joined: Sat Dec 08, 2018 1:30 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 12:48 pm

What would carrier's usually do for this type of thing? This is our new border router before our transit.
 
mkx
Forum Guru
Forum Guru
Posts: 3185
Joined: Thu Mar 03, 2016 10:23 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 1:55 pm

What would carrier's usually do for this type of thing? This is our new border router before our transit.

As a non-ISP person, I'd say ISP/carrier should not firewall much (if any at all) ... not on it's border router anyways. Either leave it to customers or do it at access routers ... unless you detect some DDOS attack in which case you'd want to block it on the border router. Or unless you do CGNAT, in which case you probably should do the filtering near the NAT-performing device(s).
BR,
Metod
 
deltamc2000
just joined
Posts: 3
Joined: Thu Dec 08, 2011 1:51 pm

Re: ICMP Firewall Potential Bug

Tue Aug 27, 2019 3:04 pm

Well folks, I am in engineer that was configuring the Mikrotik in the DC (just like the other 100's I have done in the last ten years).

@Sob, the connection state and IPv4 options had been set by in in an attempt to figure out WTF was going on, simple firewall input chain, allow ICMP, it would seem that "what ever" was causing the issue had cleared up by the time my esteemed colleague added the allow ICMP rule in, which in fact, what had been placed in the input chain in the first place.

As said, traceroute continued to be a problem but pinging worked, well this morning, traceroute is fine for /30 link pair, IP on that interface which is dst-nat to a server and a /32 from that prefix I slapped on for fun.
Strange huh?

The prefix had been previously advertised by the upstream and now that config changed so that the /22 could be announced by the customer, my bet is on something lingering with upstream provide (who is still the transit).

Hence, this is strange as f***, maybe even a bug, clearly not....

@anav, shame on you.... for a forum guru you think its okay to say:Answer, its your firewall st_p_d!

Well, WRONG st_p_d!, it was not the firewall nor was it the allow rule! Think before you type. :-/

Who is online

Users browsing this forum: No registered users and 122 guests