I have a mikrotik RB-750GL with this scenario:
- ISP A
-ISP B
- LAN 192.168.3.0/24
- DMZ 10.0.0.0/20
- VPN PPTP ( 172.10.0.0/24)
It´s working fine, routing both ISPs to LAN and DMZ and I have also a VPN Server running.
I am able to connect to mikrotik and ping only mikrotik IPs.
I am able to ping: 172.10.0.1, 192.168.3.1 and 10.0.0.1 ( MKs IPs)
What I need to enable to ping machines behind mikrotik?
I have a masquerade rule there.
I mean, Do I need to explicit in/out interface?
I want to reach 192.168.3.0/24 from 172.10.0.0/24
thanks
It sounds like your forwarding rules are blocking traffic.
Pings to the Mikrotik on any interface (even a different one than you’re connected to) will use the INPUT chain to filter this traffic. Traffic to any other addresses which flows through the Mikrotik will use the FORWARD chain. Make sure the forward chain isn’t blocking the traffic.
Right.
I had some chain FORWARD rules.
I disabled them but I am still cannot ping LAN machines from VPN.
admin@FW Dexter] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; default configuration
chain=input action=accept protocol=icmp
1 ;;; default configuration
chain=input action=accept connection-state=established
2 ;;; default configuration
chain=input action=accept connection-state=related
3 X ;;; ACEITAR PPTP
chain=input action=accept protocol=gre in-interface=1_BRIP
4 X ;;; SSH E VPN
chain=input action=accept protocol=tcp in-interface=1_BRIP
dst-port=22,1723,8080
5 X ;;; default configuration
chain=input action=drop in-interface=1_BRIP
6 ;;; default configuration
chain=forward action=accept connection-state=established
I am using mikrotik´s default configuration.
It was supposed to allow established and ralated chain input/forward.
Yes, but a connection has to become established before that rule will match. (This doesn’t mean VPN established - this means every single socket that hosts open/close to the Internet through your router)
Now, with the rules you’ve shown, everything should be allowed anyway - there is only one forward chain rule → allow established. No other rules means that all new connections will be accepted as well (and then become established)
NAT really shouldn’t matter one way or the other as long as the hosts in every network on the Mikrotik are configured to use the Mikrotik as their default gateway…
A quick and dirty check would be to make rule #1 of srcnat chain → no criteria, action = masquerade
Then any user will appear to be the Mikrotik after their packets pass through it. If you still can’t ping stuff, there might be more filter rules than we’re seeing here in the forward chain, or else somehow “forward IP” has been unchecked in your system settings.
[admin@FW Dexter] /ip firewall filter> export
apr/22/2015 11:42:10 by RouterOS 5.25
software id = FPZS-PB2N
/ip firewall filter
add action=accept chain=input comment="default configuration" disabled=no protocol=icmp
add action=accept chain=input comment="default configuration" connection-state=established disabled=no
add action=accept chain=input comment="default configuration" connection-state=related disabled=no
add action=accept chain=forward comment="default configuration" connection-state=established disabled=no
add action=accept chain=forward comment="default configuration" connection-state=related disabled=no
[admin@FW Dexter] /ip firewall filter>
[admin@FW Dexter] /ip firewall nat> export
apr/22/2015 11:43:15 by RouterOS 5.25
software id = FPZS-PB2N
/ip firewall nat
add action=masquerade chain=srcnat comment=NAT disabled=no to-addresses=0.0.0.0
add action=dst-nat chain=dstnat comment="RDR CAMERAS BRIP" disabled=yes dst-address=177.71.76.166 dst-port=8080 protocol=tcp to-addresses=192.168.3.15 to-p
add action=dst-nat chain=dstnat comment="RDR CAMERAS ZAMIX" disabled=no dst-address=189.84.181.238 dst-port=8080 protocol=tcp to-addresses=192.168.3.15 to-
8080
add action=dst-nat chain=dstnat comment="RDR2 CAMERAS ZAMIX" disabled=no dst-address=189.84.181.238 dst-port=37777 protocol=tcp to-addresses=192.168.3.15 t
37777
[admin@FW Dexter] /ip firewall nat>
[admin@FW Dexter] /ip firewall mangle> export
apr/22/2015 11:43:34 by RouterOS 5.25
software id = FPZS-PB2N
/ip firewall mangle
add action=mark-routing chain=prerouting comment=DEXTER disabled=no new-routing-mark=DEXTER passthrough=no src-address=192.168.3.0/24
add action=mark-routing chain=prerouting comment=HOSPEDES disabled=no new-routing-mark=HOSPEDES passthrough=no src-address=10.0.0.0/20
[admin@FW Dexter] /ip firewall mangle>
Well, there ya go - route marking.
By default, all of the connected routes are in the main routing table.
Any traffic which is being route-marked onto a different routing table will only be able to see routes with the same route mark. So in other words, you’ll need to add local routes for your route-marked tables.
eg: if 192.168.3.0/24 is connected to ether3, then you’ll need to add a route dst=192.168.3.0/24 gateway=ether3 route-mark=DEXTER
You’ll need ANOTHER one for the HOSPEDES routing table.
OK, i got it.
Could you please help me to create SPECIFIC rules to this scenario.
I want to reach 192.168.3.0/24(LAN) from 172.10.0.0/24 (VPN).
Is there a reason you’re using route marking?
Unless you have a specific reason, I would get rid of that - it makes things complicated, especially if you’re a beginner.
Just use the filter table to block traffic paths that you don’t want. The router already wants to forward packets to everywhere it knows about. The extra rules are breaking it.
I used routing mark due to multiples gateways failover.
Are you load balancing, or doing simple failover?
If just simple failover, then you don’t need route marking.
(your rules in mangle don’t appear to be doing any load balancing)
I have a scheduler and some scripts to choose which gateway will be used.
192.168.3.0/24 uses ISP B
10.0.0.0/20 uses ISP A.
Scheduler and scripts is used to change routes when one or other fails.
ok - when you have a host on the VPN, look in the routing table and see how the 172.10.0.0/24 network route appears.
Copy this route and put packet-mark = DEXTER
Basically, hosts with 192.168.3.0/24 are being routed on a “private” routing table called DEXTER.
If 172.10.0.0/24 is not in that routing table, then the hosts won’t be able to go the correct way.
Done and it worked.
Is there a way to do a generic rule to allow all VPN clients to reach 192.168.3.0/24 network?
It would work by default. Using mangle rules and routing tables makes things more complicated…
I think the best thing for you to do is modify your mangle rule just a tad -
/ip firewall mangle
add action=mark-routing chain=prerouting comment=DEXTER disabled=no new-routing-mark=DEXTER passthrough=no src-address=192.168.3.0/24
add action=mark-routing chain=prerouting comment=HOSPEDES disabled=no new-routing-mark=HOSPEDES passthrough=no src-address=10.0.0.0/20
modify the first rule and add the criteria: dst-address=!172.10.0.0/24
This will stop packets from the 192.168.3.0 network from being placed in the DEXTER routing table if the destination IP is a VPN client.
You will then be able to delete the extra IP route you added earlier.
Modification done but I can still only pings mikrotik ips.
;(