I have thhose 2 Mikrotiks, and IPsec running.
everything worked fine, unitl i changed ISP. They brought their own router, which they have put it to the bridge, and then i’ve connected my Mikrotik RB 4011
to PPOE and i have internet. Then i ‘ve configured Ipsec. Only thing that is not working is :
1.can’t open web-page from PC2 on the remote side server.(Veeam Enterprise console web-page i’ve checked that is working from pc on remote side)
2. cant’ ping from router R2 to R1
When i do traceroute on R2 to 192.168.97.254 (gateway) traffic goes to internet.— this part is confusing me.
Everything else is working, like RDP from one side to another, explorer, ping from pc1 to pc2 and vice versa, also ping from client side router also works.
More detail on what @pe1chl wrote:
On R2, the only /ip ipsec policy row says dst-address=192.168.97.0/24 … src-address=192.168.79.0/24 tunnel=yes
so only packets with source addresses from 192.168.79.0/24 are matched by that policy.
When the router itself sends a packet, it finds the route to destination, determines the gateway interface, and uses the address associated to that interface as a source one for the packet - unless a pref-src is set on the route, or unless you specify src-address when using commands like /tool traceroute, :ping, or /system ssh, or unless you use a src-nat rule.
=> it is normal that /tool traceroute 192.168.97.22 without specifying src-address=192.168.79.254 leads to getting the response from the WAN gateway.
Regarding the problem to open the web page at PC2, the first suspicion in these cases is always an MTU-related problem and PMTU discovery failing for some reason. The export from the client contains almost nothing, so hard to say whether it is breaking PMTUD or not.
Regarding the problem to open the web page at PC2, the first suspicion in these cases is always an MTU-related problem and PMTU discovery failing for some reason. The export from the client contains almost nothing, so hard to say whether it is breaking PMTUD or not.
[/quote]
Sending complete export from client. R1_client.rsc (4.1 KB)
There are several possibilities, e.g.: /interface bridge add name=br-blackhole
/ip route add dst-address=192.168.97.0/24 gateway=br-blackhole pref-src=192.168.79.254
Well, my preferred way of configuring it does not use such a direct IPsec tunnel but rather a GRE/IPsec tunnel between the routers.
When you add a GRE interface at each end and specify the public IP of the other end, and a IPsec secret (some random text) this automatically is created.
Then you set a /30 network on each end of the tunnel using IP->addresses (e.g. 10.0.0.1/30 on one side and 10.0.0.2/30 on the other side).
Now you can set a static route for 192.168.79.0/24 via 10.0.0.2 on one side and similar on the other.
You do not need to have tricky NAT-avoidance rules in this case, and it will likely just work for you.
The method I described automatically fixes that problem as well.
When it does not, set the MTU on the GRE tunnels to a lower value, e.g. 1400, instead of leaving it blank and using the automatic setting.
Just a remark… There is no advantage of a GRE tunnel as compared to an IPIP one, given that Mikrotik doesn’t use the optional ID field allowing to set up multiple tunnels between same endpoints, so what remains different as compared to IPIP is some weird handling by the firewall and some extra overhead bytes.
Other than that, your firewall on both routers is basically non-existent, which probably isn’t a big deal at the IPsec initiator as it is behind the ISP modem but the 4011 can be misused for DNS DDoS, also even Mikrotik recommends now not to keep Winbox accessible from the internet. So I’d recommend to have a look at how a firewall should look like. Your 4011 may have actually been infected by malware already, it’s incredibly quick to squat in if you give it a chance.
Here it is.
But if I may ask, isn’t this br-blackhole used only to redirect traffic to 79.0 gateway?
i only need to downsize MTU towards 192.168.97.0/24 network, correct me if i’m wrong.
Mangle rules are normally a workaround where you cannot make thw PMTUD work properly because most of the network is not under your administration, but yes, it will help here too.
Just bear in mind that MSS is 40 bytes less than MTU, and that the ping size in Windows is the size of the ICMP payload, i.e. 28 bytes less than MTU. So set the new-mss to 12 bytes less than what the maximum ping size.
or lunch…