Community discussions

 
uCZBpmK6pwoZg7LR
just joined
Topic Author
Posts: 15
Joined: Mon Jun 15, 2015 12:23 pm

Strange behaviour

Wed Oct 31, 2018 1:53 pm

/interface bridge
add admin-mac=B8:69:F4:7F:9B:C1 auto-mac=no name=bridgeLAN

/interface bridge port
add bridge=bridgeLAN interface=ether2LAN
add bridge=bridgeLAN interface=ether3LAN
add bridge=bridgeLAN interface=ether4LAN
add bridge=bridgeLAN interface=ether5LAN
add bridge=bridgeLAN interface=wlan1WIFI.2.4
add bridge=bridgeLAN interface=wlan2WIFI.5

/ip firewall filter
add action=accept chain=input in-interface=bridgeLAN
add action=drop chain=input log=yes log-prefix=DROP

/ip address
add address=10.111.112.1/24 interface=bridgeLAN network=10.111.112.0
From mikrotik console
 ping 10.111.112.1
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 10.111.112.1                                            timeout            
    1 10.111.112.1                                            timeout            
    sent=2 received=0 packet-loss=100%
Log output :
12:48:30 firewall,info DROP input: in:(unknown 1) out:(unknown 0), proto ICMP (type 8, code 0), 10.111.112.1->10.111.112.1, len 56 
12:48:31 firewall,info DROP input: in:(unknown 1) out:(unknown 0), proto ICMP (type 8, code 0), 10.111.112.1->10.111.112.1, len 56
Question : WHY ?????

Update 1:
 ping 10.111.112.1 interface=bridgeLAN 
  SEQ HOST                                     SIZE TTL TIME  STATUS             
    0 10.111.112.1                                            timeout            
    1 10.111.112.1                                            timeout            
    sent=2 received=0 packet-loss=100%
  
Route :
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
7 ADC 10.111.112.0/25 10.111.112.1 bridgeLAN 0

Update 2:
if to add in firewall
add action=accept chain=input log=yes log-prefix=LOCAL src-address-type=local
then it is start to work but this is not a solution . Still exist following questions :
1) Why it bind ip address to hidden loopback ?
2) How to remove ip address from hidden loopback and force bind to interface i choose ?

Update 3:
Such problem persist only on Hex and HAP series, On CCR and at least RB3011 everything working correct.
 
User avatar
xvo
Long time Member
Long time Member
Posts: 589
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Strange behaviour

Wed Oct 31, 2018 4:39 pm

Tried on hEX, hAP ac2, hAP mini - nothing like this.
 
nescafe2002
Long time Member
Long time Member
Posts: 624
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

Re: Strange behaviour

Wed Oct 31, 2018 4:51 pm

Cannot answer "why", but a solution is to use the default firewall.

It doesn't allow from lan explicitly, but drops everything from (not lan) in input chain and from wan in forward chain.

Perhaps to overcome this issue.
/ip firewall filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
/ip firewall filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat \
    in-interface-list=WAN comment="defconf:  drop all from WAN not DSTNATed"
 
User avatar
xvo
Long time Member
Long time Member
Posts: 589
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Strange behaviour

Wed Oct 31, 2018 5:13 pm

...and finally I got what are you trying to prove :)
No difference in behaviour between CCR and all others I mentioned above.
The answer is in your log: obviously, in such case there is no in-interface, so it doesn't match your first rule.
 
uCZBpmK6pwoZg7LR
just joined
Topic Author
Posts: 15
Joined: Mon Jun 15, 2015 12:23 pm

Re: Strange behaviour

Wed Oct 31, 2018 5:19 pm

Tried on hEX, hAP ac2, hAP mini - nothing like this.
Exactly HAP ac2 affected with version 6.43.4
and at least 5 different HEX lites with different versions of firmware have same issue.
Most probably something else inside mikrotik affect this .
 
uCZBpmK6pwoZg7LR
just joined
Topic Author
Posts: 15
Joined: Mon Jun 15, 2015 12:23 pm

Re: Strange behaviour

Wed Oct 31, 2018 5:23 pm

...and finally I got what are you trying to prove :)
No difference in behaviour between CCR and all others I mentioned above.
The answer is in your log: obviously, in such case there is no in-interface, so it doesn't match your first rule.
extraction from /interface print
 1  RS ether2LAN                           ether            1500  1598       9214 B8:69:F4:7F:9B:C1
 2   S ether3LAN                           ether            1500  1598       9214 B8:69:F4:7F:9B:C2
 3   S ether4LAN                           ether            1500  1598       9214 B8:69:F4:7F:9B:C3
 4   S ether5LAN                           ether            1500  1598       9214 B8:69:F4:7F:9B:C4
 5   S wlan1WIFI.2.4                       wlan             1500  1600       2290 B8:69:F4:7F:9B:C5
 6   S wlan2WIFI.5                         wlan             1500  1600       2290 B8:69:F4:7F:9B:C6
 7  R  bridgeLAN                           bridge           1500  1598            B8:69:F4:7F:9B:C1

/ip address print 
Flags: X - disabled, I - invalid, D - dynamic 
 #   ADDRESS            NETWORK         INTERFACE                                
 0   10.111.112.1/25    10.111.112.0    bridgeLAN   

What in-interface for traffic which go from bridgeLAN interface to bridgeLAN interface ?
Why if i do exactly same operation on CCR then ping works ?
 
User avatar
xvo
Long time Member
Long time Member
Posts: 589
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Strange behaviour

Wed Oct 31, 2018 5:44 pm

What in-interface for traffic which go from bridgeLAN interface to bridgeLAN interface ?
Why if i do exactly same operation on CCR then ping works ?
I doubt interfaces are used at all when you are pinging local addresses.
At least in-interface.
And you log entries clearly show that.

If you want to investigate further try creating a log rule in output chain, and then ping with and without interface setting.

I tried on CCR1009 and got the same result - no ping both with and without interface specified.

Who is online

Users browsing this forum: MSN [Bot] and 101 guests