We have two RB1100xAH2 - with vrrp between them. 1st RB1100 has address x.x.x.203 , 2nd RB1100 - x.x.x.204, the virtual IP is x.x.x.202 vrrp. All work well and when 1st router fails then 2nd begins to work.

The problem is that l2tp clients send the request to virtual address x.x.x.202 , and get the response from "hardware" address from router x.x.x.203 or x.x.x.204, and the connection cannot be established.

Mark L2TP in mangle and reroute it over vrrp interface. And set src-nat rule to change source address to correct one.

Sorry, I'm a newbie trying to do this too. I have the same problem and I'm not sure how to construct the mangle rule. Can you put an example?

/ip firewall mange add chain=output protocol=udp port=1701 action=mark-routing new-routing-mark=vrrp
/ip firewall nat add chain=srcnat action=masquerade out-interface=vrrp

/ip route add gateway=<vrrp-gateway> routing-mark=vrrp

I think I'm getting there. I was getting repeated "first L2TP UDP packet received" messages in the log and the IPSec SA was only in one direction.

Now I see the IPSec SA on both side but no traffic on the outbound SA.

I should note that I have VRRP running on the "LAN" side of the device too but this should not matter in establishing the tunnel. I've tried with and without a local IP on the PPP connection but that seems to be where things are failing. Here is the last thing I see in the debug log:

07:15:06 l2tp,debug,packet ppp: (M) Framing-Capabilities=0x1
07:15:06 l2tp,debug,packet ppp: (M) Bearer-Capabilities=0x0
07:15:06 l2tp,debug,packet ppp: Firmware-Revision=0x1
07:15:06 l2tp,debug,packet ppp: (M) Host-Name="10100001-ipfw1"
07:15:06 l2tp,debug,packet ppp: Vendor-Name="MikroTik"
07:15:06 l2tp,debug,packet ppp: (M) Assigned-Tunnel-ID=220
07:15:06 l2tp,debug,packet ppp: (M) Receive-Window-Size=4
07:15:06 ipsec,debug,packet ppp: KA: PUBLICVRRP[4500]->REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: sockname PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: send packet from PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: send packet to REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: src4 PUBLICVRRP[4500]
07:15:06 ipsec,debug,packet ppp: dst4 REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: 1 times of 1 bytes message will be sent to REMOTECLIENTIP[4500]
07:15:06 ipsec,debug,packet ppp: ff

Any additional suggestions?

This didn't work. I even tried bypassing the mangle and routing all traffic to the remote location to the <vrrp-gateway> which I'm assuming is the IP address of the VRRP public interface? I cannot find a way to get both IPSec and L2TP to use the VRRP IP.

/ip firewall mange add chain=output protocol=udp port=1701 action=mark-routing new-routing-mark=vrrp
/ip firewall nat add chain=srcnat action=masquerade out-interface=vrrp

/ip route add gateway=<vrrp-gateway> routing-mark=vrrp

what you mean by "out-interface=vrrp" and "gateway=<vrrp-gateway>"
are they different interfaces or the same....?

when we make such settings we get the same result.. packets come back not from vrrp but from IP-address of the physical interface...

We could only get this to work on the non-vrrp addresses. We had to set up DNS round-robin to work around the issue. Doesn't seem to work with VIP addresses.

Further testing shows that the DNS round robin doesn't work either. The problem is that if you connect via L2TP to the router that is not the VRRP master, then the traffic doesn't flow to the internal network. I suspect this is due to a mangle that forces the outbound NAT to be the IP address of the VRRP data.

Does anyone have L2TP working using VRRP for the public connection IP? Any idea on why this would not work?

Of course it will not work. You should allow users to connect only to VRRP address, block the rest in firewall.

The connections using the VRRP address are not working, so what do you suggest? The rules provided previously in the post do not resolve the problem. So saying to use the VRRP address, which doesn't work, doesn't resolve the problem.

Here is some more information from packet sniffing:

- Scenario to non-VRRP public IP (VRRP is running, router is the master): IPSec is established and L2TP packets are exchanged using the public IP of the interface, NOT the VRRP address. I can see the packets with destination ports of 1701 establishing the L2TP tunnel. Connection establishes successfully as long as the router is the master. The interface used is ether1. This shouldn't really work since I have a NAT rule that ALL traffic with an outbound interface of ether1 should use my src-nat rule to assign the outbound IP address of the VRRP address. So why would it use the IP address assigned to ether1? The src-nat rule is in position 0 in the firewall NAT listing in Winbox.

- Scenario to VRRP IP: IPSec is established and L2TP packets are received from the remote location. There are NO REPLIES from the MikroTik router to any of the inbound traffic on port 1701 (L2TP). IPSec packets show the outbound IP as the VRRP address which follows the src-nat rule.

It is almost like the L2TP server is not listening on the VRRP address. I also don't understand why the scenario without VRRP works but I don't know if I care either if I can get it to work with the VRRP address. I don't think there is a netstat tool in MikroTik, so how can I verify that L2TP is listening on the VRRP address?

I cleared all connections and rebooted the routers. Now I'm getting replies using the scenario with VRRP. The problem is that the replies are sending the public IP of the ether1 interface, NOT the VRRP IP. This directly violates the NAT rule that I have on the router which says that all traffic going out via the ether1 interface should use the src-nat and assign the VRRP IP.

Does L2TP bypass the NAT rules? If so, why?

Any ideas on why it isn't using the NAT rule? The public IP returned by the L2TP packets is definitely not the VRRP address defined in the NAT rule which is creating the problem.

I'm also open to any possible work around for this issue. Right now, it appears L2TP is broken with VRRP.

Has anyone found out a way around this? I can establish a link using the physical IP on the L2TP Server but if I try and use the VRRP IP the Client just says connecting. All other things are left the same, I can connect with an L2TP Client with the physical WAN IP but not the VRRP IP.

We are phasing out VRRP. The challenge of getting it to work right with outbound NAT, L2TP, STS IPSec tunnels, and various issues we've run into has made it more a problem that a resolution. We're going to create redundancy via the KVM layer instead and in the meantime, rely on backups which we can restore in less than 5 minutes. Our hardware is very resilient (RAID, etc.) and monitored and we have hot spare hardware available.

VRRP in our core routing on the MikroTik 1100's has not been an issue so we're keeping it there. It is only where we use the MikroTik as a firewall.

I know it isn't the answer you want to hear.