cucul
July 14, 2019, 10:54pm
1
I have the following situation shown in the figure:
When port forward is set in network 2 (with Mikrotik), I can see from the network 1 the pictures transmitted by the DVR2, but I can not see from the network 2 the pictures transmitted by the DVR1.
If I disable port forward from network 2, I can see from the network 2 the pictures transmitted by the DVR1, but evident, I can no longer see from the network 1 the pictures transmitted by the DVR2.
This problem has only occurred since I replaced the old router (Asus) with a Mikrotik.
Some suggestions for this troubleshooting ???
Thank you.
mkx
July 15, 2019, 6:09am
2
Post output from command /ip firewall nat export (run it from terminal window). I suspect your port forward setting might be a tad too greedy and steals all connections, not only those destined at Network2 …
cucul
July 15, 2019, 1:14pm
3
/ip firewall address-list
Thank you.
cucul
July 15, 2019, 1:19pm
4
…full version…
/interface bridge
Thank you.
mkx
July 15, 2019, 2:01pm
5
The IP addresses used in configuration, don’t correspond to IP addresses indicated on the chart (why did you bother writing them there if you didn’t want to show exact addresses anyway?), I’ll assume the addresses in the config export are correct.
So:
As I expected, the quoted rule is the problem: it grabs any connection, targeting tcp port 8000, and redirects it to LAN IP host 192.168.99.150. And it doesn’t matter if the connection comes from WAN via PPPoE targeting your public IP address … or coming from LAN targeting some remote internet host (your network #1 in this case).
Straight-forward fix would be to change the NAT rule to this one:
add action=dst-nat chain=dstnat comment=DVR_1 dst-port=8000 protocol=tcp
This way the NAT rule will only change destination address when connection requests come in through WAN interfaces.
Implementing it might break one functionality which you may be using or not: if you try to check DVR2 from a PC in the network 2 and you use WAN address of network 2 to connect, then before implementing the change I proposed works, but won’t work afterwards.
Clarification:now : from LAN PC with address 192.168.99.42 … connecting to 192.168.99.150 port 8000 … works now : from LAN PC with address 192.168.99.42 … connecting to 1.2.3.4 port 8000 … works after : from LAN PC with address 192.168.99.42 … connecting to 192.168.99.150 port 8000 … will work after : from LAN PC with address 192.168.99.42 … connecting to 1.2.3.4 port 8000 … will fail
If you need this kind of connectivity, then you’ll have to implement hair-pin NAT.
mkx
July 15, 2019, 2:10pm
6
There are some other minor errors in the configuation:
/ip address
The LAN address should really be bound to interface=bridge1 … sometimes this kind of error causes weird behaviour.
/ip dns
This setting instructs router to query itself for any FQDN<->IP mapping. Which won’t work well. You should add address of one (or two) DNS servers … either LAN-hosted (if you have some) or WAN server (ISP, Google, whatever).
In firewall filter section you have a few rules which have in-interface=ether1 … these are no good when your WAN access is over pppoe-out1 interface. You should rework those rules and use in-interface-list=WAN instead.
anav
July 15, 2019, 3:04pm
7
Well that was thorough, no crumbs for me. Off I go in search of for food. Excellent support as usual from Yoda
cucul
July 15, 2019, 5:10pm
8
Well, I have tried to implement the above instructions:
/interface bridgeadd action=dst-nat chain=dstnat comment=DVR_1 dst-port=8000 in-interface=
but port 8000 is closed and the DVR (192.168.99.150) from the Internet can not be accessed.
Something I did wrong … ???
Thank you.
mkx
July 16, 2019, 5:31am
9
Your WAN interface is not ether1 but rather pppoe-out1 (ether1 is only physical interface, carrying PPPoE traffic; the logical interface which carries WAN traffic, is pppoe-out1), so the NAT rule you have now
add action=dst-nat chain=dstnat comment=DVR_1 dst-port=8000 > in-interface=ether1 > protocol=tcp to-addresses=192.168.99.150 to-ports=8000
can’t work. As I wrote, change it to
add action=dst-nat chain=dstnat comment=DVR_1 dst-port=8000 > in-interface-list=WAN > protocol=tcp to-addresses=192.168.99.150 to-ports=8000
Another suggestion: firewall rules from latest export somehow work, but are not really safe … the chain=forward have some rules, but don’t really prevent any connections which are not mentioned in the rule list. Accepting DST-NATed connections is one example. I suggest to place these two rules at the end of rule list:
add action=accept chain=forward comment="allow dst-nat connections from WAN" connection-nat-state=dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="drop anything else from WAN" in-interface-list=WAN
And, for better performance (reduced CPU load), add this rule to the top (definitely it should be above similar rule, but with action=accept … which must remain there and enabled):
add action=fasttrack-connection chain=forward comment="defconf: fasttrack established,related" \
connection-state=established,related
Define rule and then move it to the top (drag and drop if using winbox or webfig, use command move if using CLI).
cucul
July 16, 2019, 6:12pm
10
It seems that all the problems have been solved.@mkx
