Hi!
I have this configuration:
R_01 as DHCP server 172.16.1.0./25
R_09 as client 172.16.1.108 and as Router DHCP server 172.16.22.0/25
An ipsec tunnel between the R_01 172.16.1.0/25 and the VM in a private network 172.16.10.128/25 GW 172.16.10.129
SO
I can ping a device in the 172.16.22.0/25 with a VM in the 172.16.10.128/25 (so routes are correct)
I can´t ping the VM with the devices in the 172.16.22.0/25
What I need to make ping in a VM to the 172.16.22.0/22 ?
Thanks
Not enough information, but it sounds like a firewall issue, where firewall rules on R_09 or on R_01 do not allow connections from 172.16.22.0/22 to 172.16.10.0/25 to establish.
this is the filter rules of the R01
[Router_01@R_01] /ip/firewall> filter print
Flags: X - disabled, I - invalid; D - dynamic
0 chain=input action=accept src-address=172.16.10.128/25 dst-address=172.16.1.0/25 log=no log-prefix=“”
1 chain=input action=accept src-address=172.16.1.0/25 dst-address=172.16.10.128/25 log=no log-prefix=“”
2 chain=forward action=accept src-address=172.16.1.0/25 dst-address=172.16.10.128/25 src-address-list=“” log=no
log-prefix=“”
3 chain=forward action=accept src-address=172.16.10.128/25 dst-address=172.16.1.0/25 log=no log-prefix=“”
If these are the only filter rules, it is equal to no rules at all, as the default handling in Mikrotik firewall is “accept”. So whatever doesn’t match to any rule is accepted.
But the issue may be caused also by rules in /ip firewall raw, /ip firewall nat, or even /ip firewall mangle. I’d suggest that you follow the hint in my automatic signature below for both R_01 and R_09.
If you have RouterOS 7.x, don’t use hide-sensitive, as in ROS 7 it became the default behaviour (overridden by show-sensitive) and the old keyword is not recognized.
Thank you!
The Cloud subnet it’s 172.16.10.129/25 all machines has the route persistent 172.16.1.0/25 > 172.16.10.129 / 172.16.22.0/25 > 172.16.10.129
The Main Router01 172.16.1.0/25
The Router 10 it’s 172.16.22.0/25
Config_FW_R10_r1.txt (4.3 KB)
I have misunderstood your original post and thought the IPsec tunnels was between R_01 and R_09 (R_10), whereas in fact the tunnel is between R_01 and the VM in 172.16.10.128/25 (but in the export, the policy with dst-address=172.16.10.128/25 src-address=172.16.22.0/25 is disabled, why?).
Since nothing in the firewall rules you’ve posted prevents initiation of new connections from 172.16.22.0/25 to 172.16.10.128/25, the only remaining place where it may be blocked is the firewall (iptables, nft(ables), …) on the VM peer of the IPsec.
Hi!
dst-address=172.16.10.128/25 src-address=172.16.22.0/25 is disabled, why?).
in this moment the configuration it’s in test, so now I activate it and the same result.
i think like you, the problem it’s in the ip tables of the firewall in the other side (VM’s) than I can´t configure…
Many thanks
can’t configure as in “I don’t have administrative access to the VM” or as in “I don’t know how to configure iptables”?
I haven’t got the access and the privileges to configure it.
Thanks
They tell me that i need to configure a second policies with a phase2 between the 172.16.22.0/25 and 172.16.10.128/25 in the router1.
When I set up, I loose the conectivity with the Vm’s.
It’s correct to make a second IPsec policy?
Many thanks
If you want the traffic between 172.16.10.128/25 and 172.16.22.0/25 to run IPsec-encrypted between the VM and R_01, then indeed a corresponding policy for Phase 2 must exist. I was asking why it was disabled in your configuration export, and your answer was
So I’ve concluded you normally did have that policy enabled.
Now you say
So what else has changed that before, enabling the policy has changed nothing, and now it causes “loss of connectivity”? The existence of the policy only affects traffic between 172.16.10.128/25 and 172.16.22.0/25, so adding it should not cause a loss of connectivity between 172.16.10.128/25 and any other subnet than 172.16.22.0/25.
If the policy was not there at either side (neither R_01 nor VM) before, it means that the traffic between 172.16.10.128/25 and 172.16.22.0/25 was flowing unencrypted, using normal routing. Once you add the policy only at R_01 but not at the VM, that traffic stops flowing because traffic matching a traffic selector of an existing policy is always intercepted by the policy, and if no security association is available for that policy, the intercepted traffic is dropped. Also received traffic that reverse-matches an existing policy but did not come via a corresponding security association is dropped.