I have problem with Mikrotik hEX S RB760iGS RouterOS 6.44.3. IPSec/L2TP VPN (Windows to Router).
All working I have access to internel network and over the IPSec/L2TP VPN tunnel internet,
but if I want access to router (with internal IP) itself using winbox or webpage that connection hang some 30 sec.
Over PPTP VPN that working.
I use that similar IPSec/L2TP VPN config to RB750G r3 and CRS125-24G and all working like works the way it should.
Are there any ideas on how to get RB760iGS working properly?
VPN to internal network and thru VPN Tunnel to internet working fine, but if I want access to router then winbox logs in at first and then runs for about 30 sec.
Log don’t say anything. Only winbox login and if timeout reaching then logout.
Maybe IPsec hardware encryption support is different between RB760iGS and RB750Gr3.
“similar” and “like” are not the same thing as “exactly the same”, so I suspect a typo in the particular config on the hEX.
Hardware acceleration of IPsec is not relevant, if the problem was there, nothing would be working, whereas you say that only access to the router itself via the tunnel is an issue.
Still can’t work as it should, this RB760iGS has some ipsec difference with RB750G3.
Access to the router itself via the tunnel hang.
The configuration is attached
A few things I can see there but I cannot say any of them would be clearly responsible for the issue:
your IP address 192.168.160.1/24 is attached to ether2 although ether2 is a member port of bridge bridge1; this is incorrect and causes unreliable behaviour. You should set the value of parameter interface of that /ip address to bridge1.
you have both an /ip dhcp-server and /ip dhcp-client attached to the same interface (bridge1), that is not a good idea in general, I guess ROS detects it and gives priority to server but I’m not sure about this; in any case, disable the client
your /ip firewall filter rule action=accept chain=forward comment=“default configuration” connection-state=new shadows all the following rules in chain=forward because it permits establishing of any new transit connection in either direction (you can check by watching statistics of the subsequent rules in chain=forward, they never count).
Given the last point above, and given that the chain=input looks clean to me, I suspect that due to some misconfiguration at the L2TP client side, the packets which arrive through the L2TP tunnel from the client come with a different source address than the one reserved to the client from the /ip pool name=l2tp because the client overrides it, so they match the condition src-address-list=**!**safe and thus this chain=input action=drop … rule drops them, whereas packets with the same source address are accepted in forward chain by the rule mentioned above because that rule doesn’t care about source address at all.
To check that, put a rule action=log log-prefix=abcdefgh protocol=tcp dst-port=80,8291 chain=input right before the chain=input action=drop … rule, connect the client, and try to connect to 192.168.160.1 or 192.168.161.1 using web browser or Winbox, then check the log using by log print where message~“abcdefgh”. You should see there the actual source IP address of the packets which came from the client.
An easier check is to issue /ip route print where gateway~“l2tp” while the LT2P client is connected - you’ll probably see a different /32 IP in the DST-ADDRESS column than one from the pool L2TP.