I have a working ipsec VPN with policies between two RB4011’s.
My problem is i fail to ping and have a web interface access to 2 out of 5 devices which is strange.
Headquarters IP 192.168.0.0/24
Branch IP 192.168.5.0/24
I can ping and have web access to the following 192.168.0.127, 192.168.0.142 and 192.168.0.223 but i fail to access 192.168.0.250 and 192.168.0.30 which are a PBX and an IP Printer.
192.168.0.127 is a CCTV system, 192.168.0.142 is an IP Phone and 192.168.0.223 a NAS device all accessible and working fine.
Saying that i feel like my routing is correct and my firewall is allowing all of the 0.0/24 range in.
The assets work fine on the local network if i Anydesk to a local machine there.
Also what i have noticed is that if i create a L2TP connection from my mobile phone to the headquarters via LTE everything is accessible from the phone as it should.
Without seeing your configuration, no ideas at all. See my automatic signature right below for anonymisation hints.
The only things which come to my mind without seeing the configuration are missing/wrong routes to 192.168.5.0/24 on the two devices (as the IP ranges for the L2TP clients and the IPSec tunnel clients are different), or firewall configuration on those devices themselves.
Is it a L2TP/IPsec tunnel or just an IPsec site to site tunnel ?
In case it is a IPsec tunnel, under IP Firewall NAT, on the 192.168.5.0/24 side, have you created a src nat rule with dst address 192.168.0.0/24 action accept and placed at the very top?
Same must be done to the other side but for the 192.168.5.0/24 subnet…
There are some improvents that you could make on your config, but besides that i cant really see a reason why you cant ping or access in particular your PBX and the Printer…
Are you sure those 2 devices have correctly configured as gateway the address 192.168.0.254 ?
Is you PBX accessible from outside your Network ?
With the same config on my previous house i could access them…in the new house i am now i can’t…
It is really weird.
I have also tried with a different provider besides OTE just in case this is a firewall or nat issue still the same thing happens and i want the access to the VoIP PBX to put a SiP phone where
i live cos of the quarantine.
I will check the gateway properties on these two devices but can’t do it now as i have no access to a local pc there and it is 50Km away.
Will let you know the results.
Any chance you could point me out as to what you think can be improved on my config?
Do you have static IP on your ISPs Routers and then with DMZ or port forward you send the traffic to the Mikrotiks ?
As for the improvements, i will start with the most important ones, your Firewall is not good at all…
Static IP on one side (HeadQuarters)
Dynamic IP on the other side that changes with a script (see my config above)
I didn’t do a DMZ - Maybe this is my mistake?
To overcome the suspected issue of a missing route to 192.168.5.0/24 (or the default route) on the two devices, you can use src-nat rules on the Mikrotik at the HQ:
These rules will make the traffic from the BO look like a locally originating one to the two devices.
If this doesn’t help, the issue is not the missing route.
If it does help, you can use it for management access to the devices, but connecting a VoIP phone from the branch network to the PBX may have problems due to the NAT, so it’s just a tool, not a solution.
Actually @sindy this is a workaround and not a solution since this problem occurs on specific devices…
Besides, the correct implementaion of an IPsec Tunnel does not need any routes at all!
I still believe it is a NAT problem…
Because, as both @Zacharias and me have suggested, these devices either miss a default route (to 0.0.0.0/0), or a specific route to a subnet which includes 192.168.5.0/24 exists on them via some other gateway than 192.168.0.254, or because their firewall blocks traffic from 192.168.5.0/24 (or a superset of it).
Off topic, what’s the original Greek word you translate as “asset”? I have never seen anyone to use this word to describe network devices (or “hosts”).
I fully agreed with you already before you wrote that, and here’s the proof:
But this tool (or workaround) gives the OP the chance to analyse the settings of the affected devices while in “corontine” and identify the root cause.
Also i missed the routes earlier, they are not needed at all… It is Wrong…
In IPsec, all we need is a default route in our routing table so that the packet during the Routing Deicision does not get discarded…
All the rest will hapen because of the IPsec Policy!!!