The official Mikrotik router thread

Leno said:
@Naks


You mentioned you tried the above but I always prefer to use interface/interface list insead of dst address, less work for the firewall and cleaner when your address changes

On your ip firewall filter rule I dont think the dst-address=192.168.88.248 should be used, since we drop all on the WAN side of the filter, the rule must match before the nat is applied so that would be the WAN ip needed, but in-interface-list is much easier

Can you see if the above rules help
Click to expand...

thanks, but same thing: I can see packets but no connection.

In the logs:

Code: 
dstnat: in:ether1 out:(unknown 0), src-mac X, proto TCP (SYN), PhoneIP:53594->RouterIP:9898, prio 5->0, len 60

forward: in:ether1 out:bridge, src-mac X, proto TCP (SYN), PhoneIP:53594->192.168.88.248:9898, NAT PhoneIP:53594->(RouterIP:9898->192.168.88.248:9898), prio 5->0, len 60
 
Naks said:
thanks, but same thing: I can see packets but no connection.

In the logs:

Code: 
dstnat: in:ether1 out:(unknown 0), src-mac X, proto TCP (SYN), PhoneIP:53594->RouterIP:9898, prio 5->0, len 60

forward: in:ether1 out:bridge, src-mac X, proto TCP (SYN), PhoneIP:53594->192.168.88.248:9898, NAT PhoneIP:53594->(RouterIP:9898->192.168.88.248:9898), prio 5->0, len 60
Click to expand...
It looks good from the logs, maybe try run a packet sniffer on your pc (tcpdump/wireshark)

Else we add a firewall rule to try log the responce from your pc, to try see the SYN/ACK sequence

/ip firewall filter
add action=accept chain=forward comment="Log response from PF" in-interface-list=LAN src-port=9191,9595,9898 protocol=tcp log=yes
Click to expand...

Edit: this log rule would have to be placed above the general forward accept established rule
 
Leno said:
Else we add a firewall rule to try log the responce from your pc, to try see the SYN/ACK sequence

Edit: this log rule would have to be placed above the general forward accept established rule
Click to expand...

Added this rule, where do I see the log?

Another weird thing I noticed just now - all my network shares are no longer accessible via IP, only via FQDN.
 
RouterOS 7.2.2 is here.

Warning to those using Wifiwave2:

WARNING: Some users report bricked devices after updating if wifiwave2 is installed

Thanks.

(@holvoetn It says this has been fixed on 7.3b37 and 7.2.2 should not be used if wifiwave2 is used)

What's new in 7.3beta37 (2022-Apr-25 15:29):
*) system - fixed RouterOS bootup when wifiwave2 package is installed (introduced in v7.3beta34);

Changelog:

What's new in 7.2.2 (2022-Apr-28 21:01):

*) bgp - added initial support for prefix limit;
*) bgp - improved stability when editing BGP template;
*) bonding - fixed LACP flapping for RB5009 and CCR2004-16G-2S+ devices;
*) ccr - added visible "passthrough" flag for interfaces on CCR2004-1G-2XS-PCIe;
*) ccr - usability and stability improvements for passthrough interfaces on CCR2004-1G-2XS-PCIe;
*) cd-install - allow selecting on which drive to install RouterOS;
*) conntrack - limited full Connection Tracking warning to 1 message per minute;
*) crs3xx - fixed storm rate on 1Gbps interfaces for CRS354 devices;
*) defconf - suggest user to set up new password;
*) dhcpv4-server - fixed minor logging typo;
*) fetch - improved full disk detection;
*) filesystem - fixed possible boot failure on RB850Gx2 and RB1100AHx2;
*) filesystem - improved long-term filesystem stability and data integrity;
*) gps - fixed minor value unit typo;
*) ipv6 - removed bogus commands from IPv6 neighbors menu;
*) l3hw - improved offloading for directly connected hosts on CRS305, CRS326-24G-2S+, CRS328, CRS318, CRS310;
*) l3hw - improved route table offloading for CRS317, CRS309, CRS312, CRS326-24S+2Q+, CRS354, CRS5xx, CCR2x16 devices;
*) leds - fixed ethernet LED behavior on wAP R ac;
*) leds - fixed wireless related LED behavior with WW2 package;
*) lte - added SMS sending support for MBIM protocol;
*) lte - added support for generic PXA1802 based modems;
*) lte - disabled wait for LTE auto attach;
*) lte - hide slave interfaces from export;
*) lte - improved stability when upgrading LTE firmware on Chateau 5G;
*) mlag - fixed MAC address moving between bridge ports;
*) mpls - do MPLS forwarding for nexthops without mappings;
*) mpls - fixed MPLS MTU and path MTU selection;
*) mpls - fixed MPLS forwarding after any interface configuration parameter is changed;
*) ospf - fixed GRE interface compatibility with OSPF;
*) ospf - improved stability when enabling or removing interface-template entries;
*) ovpn - fixed memory leak on TILE architecture;
*) ovpn - fixed packet processing on MT7621A;
*) ovpn - improved Windows client disconnect procedure in UDP mode;
*) ovpn - improved service stability when processing frequent disconnects in UDP mode;
*) ovpn - improved stability when forwarding traffic on TILE;
*) ping - fixed socket allocation after VRF change;
*) ppp - fixed "remote-ipv6-prefix" parameter unsetting;
*) ppp - fixed active sessions sometimes getting stuck;
*) ppp - fixed issue with multiple active sessions when "only-one" is enabled;
*) queues - improved stability in large list of queue scenarios;
*) rb5009 - fixed 10G linking issues with Intel X520, XXV710 NICs;
*) route - fixed "table" menu emptying after RouterOS upgrade;
*) route - fixed static routes in VRF becoming invalid after reboot;
*) route-filter - fixed community matchers;
*) rsvp-te - improved stability when "Resv" received for non-existing session;
*) supout - added RIP section;
*) system - fixed IP service initialization in VRF after system startup;
*) system - fixed rare partial loss of RouterOS configuration after package upgrade/downgrade/install/uninstall;
*) torch - properly capture all related IPv6 traffic;
*) upnp - improved stability when processing incomplete HTTP header;
*) vpls - fixed "pw-l2mtu" parameter usage;
*) vrf - fixed VRF leaking;
*) winbox - do not show "unknown" area under "Routing/OSPF/LSA" menu;
*) winbox - do not show type value for NXDOMAIN entries under "IP/DNS/Cache" menu;
*) winbox - made "Interface Templates" table sortable under "Routing/OSPF" menu;
*) winbox - properly clean up SFP module information after it is unplugged;
*) winbox - properly clean up disk after a failed file upload;
*) winbox - show PVID column by default under "Bridge" menu;
*) wireless - fixed EAP-TLS authentication;
*) wireless - fixed GUD version in 3gpp information;
*) ww2 - fixed VLAN tag handling;
*) x86 - improved support for i40e driver;
*) x86 - improved support for Intel E810 NIC;
 
Naks said:
That rule was already there by default, but for the WAN.
Click to expand...
Yes, but you are forwarding traffic to the LAN, so you should have one for LAN as well. You could limit it to specific IP etc, but for now try it.
 
Last edited:
Naks said:
All my tests are from my phone, on MTN 4G.
Click to expand...
Ok, do you have a router before the Mikrotik, or are you dialed up directly on the Mikrotik? Trying to understand your network configuration.

I've got the following:

Public accessible IP on the LTE side.
LTE Router (port 443) -> Mikrotik -> Network Server (port 44301)

Code: 
/ip firewall nat
add action=masquerade chain=srcnat \
    ipsec-policy=out,none out-interface-list=LAN
add action=dst-nat chain=dstnat comment="Nginx Proxy Manager" \
    dst-address-list=router dst-port=443 log=yes protocol=tcp to-addresses=\
    192.168.1.4 to-ports=44301

/ip firewall address-list
add address=192.168.1.3 list=router
add address=192.168.9.2 list=router

/ip dns static
add address=192.168.1.3 regexp=*.mydomain.co.za

192.168.1.3, 192.168.9.2 = Mikrotik
192.168.1.4 = network server

I've mitigated the need for Hairpin NAT by adding static DNS pointing to my Mikrotik on the local network. The masquerade for LAN is needed for local forwarding.
 
Last edited:
B-127 said:
Ok, do you have a router before the Mikrotik, or are you dialed up directly on the Mikrotik? Trying to understand your network configuration.

I've got the following:

Public accessible IP on the LTE side.
LTE Router (port 443) -> Mikrotik -> Network Server (port 44301)
Click to expand...

Nothing before the Mikrotik.

Fibre > Mikrotik > Switch > LAN Devices
 
Naks said:
Nothing before the Mikrotik.

Fibre > Mikrotik > Switch > LAN Devices
Click to expand...
Ok.
How about adding this:

Code: 
/ip firewall filter
add action=accept chain=input dst-port=9191,9595,989 protocol=tcp

Before the "defconf: drop all not coming from LAN" rule.
 
B-127 said:
Ok.
How about adding this:
Code: 
/ip firewall filter
add action=accept chain=input dst-port=9191,9595,989 protocol=tcp
Before the "defconf: drop all not coming from LAN" rule.
Click to expand...

Nope, that made it worse - no packets came through.

There's already a general rule for all port forwarding:
Code: 
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat connection-state=new in-interface-list=WAN \
    log=yes
 
Naks said:
Nope, that made it worse - no packets came through.

There's already a general rule for all port forwarding:
Code: 
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat connection-state=new in-interface-list=WAN \
    log=yes
Click to expand...
Are you getting any "Connection Refused" messages when trying from your mobile?
 
B-127 said:
Yes, but you are forwarding traffic to the LAN, so you should have one for LAN as well. You could limit it to specific IP etc, but for now try it.
Click to expand...
You dont need masquerade rules for incoming , thats what dst-nat does

He was already masquerading on traffic leaving the WAN, you dont want to masquerade traffic incoming on LAN as you may have 2 seperate LAN networks which would then make problems

Edit: Of course ignoring hair pin nat but I dont think he is wanting this
 
@Naks Im not sure what else to suggest, even more as you said it was working with your DLINK, and the rules are pretty straight forward

One last ditch test, can you try test from a non Cell / mobile data client
Sometimes mobile networks mess with the TTL etc to monitor/mess with tethering etc
 
Leno said:
You dont need masquerade rules for incoming , thats what dst-nat does

He was already masquerading on traffic leaving the WAN, you dont want to masquerade traffic incoming on LAN as you may have 2 seperate LAN networks which would then make problems

Edit: Of course ignoring hair pin nat but I dont think he is wanting this
Click to expand...
My setup is slightly different where I need this rule for local port forwarding.
 
B-127 said:
Are you getting any "Connection Refused" messages when trying from your mobile?
Click to expand...
75fdc3cfcaabb62bca61dfef4ca5dc11.jpg
 
Naks said:
75fdc3cfcaabb62bca61dfef4ca5dc11.jpg
Click to expand...
Aha - connection aborted, something is messing with the SYN ACK or something, very weird

The packet trace you pasted yesterday did show the router forwarding the traffic and the pc replying, odd!
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X