At my company, we just switched from an RB2011 to an RB4011.
The main network is 192.168.124.0/22. Most of the time 126.0/24 IP-s are given with DHCP, for LAN and VPN users as well, but there are a couple devices with fixed IP on 125.0/24 addresses, that are not given dinamically, but fixed, set in the devices.
In case of the previous router, when we connected to VPN, we could ping both 126.0/24 and 125.0/24 IPs, but now, we can’t ping them through VPN.
Running IP scan on the router finds all of them, and pinging from the router works.
I transfered the configuration using export, and then cutting up the exported .rsc for part-by-part, and imported them, into the new Router.
RouterOS version of old router was 6.42, the new is 6.43.10.
Ports 2-10 are in the same bridge, all PPP profiles are set to this bridge as well.
Where should I look? I’m sure it must be a network-IP issue, but not sure where to check it.
It’s the same as other lost packets cases. Packet must first arrive to router (which means that client has correct route), then it must pass through prerouting, forward and postrouting and leave through the correct interface towards destination. Then a response must take the same way back. And you can see all steps with strategically placed logging rules (or some with Tools->Torch). Find out where packet is lost (incoming request or response) and then it should be clear.
It could even be something other than router config, e.g. Windows computers can detect new network (because gateway mac address changed) and switch network profile from private to public and then their firewall may not allow incoming connections.
Hard to tell without more details but I can guess you would be able to access local IP throu VPN if LAN local interface ARP settings will be changed from “enable” to “proxy arp”.
My local IP subnet is 10.0.255.0/24. i have setup the L2TP VPN on my MT and within the profile of the L2TP to get a local IP address 10.10.10.1.and remote client 10.10.10.x/24 resp from the l2tp-pool.
i get the correct conection but i am not able to see the local subnet (which i need to see) 10.0.255.0/24. Do I need to do a routing? Something like
ip route add dst-address=10.10.10.0/24 gateway=10.0.255.0/24
If both subnets are on router, you don’t need to do anything with routing there, it happens automatically. But devices in LAN have to know where to find VPN subnet (it’s also automatic if this router is their default gateway). And VPN clients need to know where LAN subnet is.
Since the range from which you assign addresses to L2TP clients does not overlap your LAN subnet, it must be your firewall rules which prevent them from seeing each other. So check the firewall rules first, and if you cannot see anything there on your own, follow the hint in my automatic signature.
And of course @Sob’s suggestion above is also valid.
You can decide in which way to dig by running /tool sniffer quick ip-protocol=icmp while pinging from the VPN client to the LAN device and watching whether the echo requests leave the LAN interface towards the LAN host or not. If they do, the LAN host doesn’t react on them. If they don’t but you can see them coming in from the VPN interface, it’s your firewall rules. And if you can’t see them to even come in, routing or firewall rules on the VPN client are guilty.
SEE EDIT, and REMEDY below - Shortly after posted this I had the issue reoccuring. See below.
It seems that this was a NAT issue, and bad eyeballs. When the router config was installed fresh, the default NAT rule to mask VPN trafic was left in by mistake with source address being 192.168.89.1, which was of course incorrect.
Rewritten source address to 192.168.124.0/22 with masquarade, to properly NAT VPN trafic and this fixed it.
Immediatelly after added this rule, the pings started to arrive back to me and many things started working correctly.
To make sure this was the issue, I did disable it and tested, and when disabled pings did not arrived, but when reenabled, it was working again.
So fixed.
Thanks for all the ideas though.
EDIT: Immediatelly after I verified this, I felt confident enough to upgrade the firware to RouterOS 6.43.16 (latest long-term version).
After the upgrade this doesn’t work again. I’m really frustraited.
Pinging via VPN is not working. Pinging from router from Winbox also doesn’t work, only if I check the ARP Ping box. Then the ping goes through.
Brige is set to “proxy-arp”. REMEDY:
I tried and tested many things, with no success, until I hopped onto the Quick Set tab (I usually avoid this menu).
I noticed, that somehow, here the IP of the Router (Local Network - IP) is set to 192.168.124.0, which should not be. I set this on first config to 192.168.126.1, and should remain the same.
Changing 192.168.124.0 on the Quick Set screen to …126.1 immediatelly solved this issue!
I rebooted the router to see if rebooting changes something here, but luckily not, so I think the RouterOS upgrade change the setting here, which it SHOULD NOT
If you want I can try and reproduce the issue, with screenshots.
Those tools were pretty helpful. The issue was not too obvious. See my longer post above.
In short, after fixing it with the correct NAT rule, I upgraded the RouterOS, and found out that after the update the Router's own IP is changed, from 192.168.126.1 to 192.168.124.0.
Changing it back to 126.1 resolved my issue.
