I have two locations setup and working as desired. Setup is almost identical on both sites. Site B connects site A using L2TP/IPsec client. Routes are setup so that both networks are fully reachable (I can ping and access devices on both networks from both networks).
But for some reason I can’t access site B router from site A through winbox (or web). Maybe (I expect) vice versa also.
I can access router B from site A through opened WAN port, but would like to disable this.
Why can’t I access router B from site A if I can access all other devices?
On the /ppp profile row used by the /interface l2tp-client row at the client device, and on the /ppp profile row used by the /interface l2tp-server server or the /ppp secret row on the server device, have you set interface-list=BASE? If not, the rules in chain input of /ip firewall filter at each device drop all incoming connections except ICMP and UDP connections to ports 500,1701,and 4500.
The above is just one possible way, there are other possibilities as well: at client side, you can make l2tp-out1 a member of the interface list BASE manually, or you can add a firewall rule allowing access to the Winbox TCP port directly referring to l2tp-out1 as in-interface. At server side, the same applies, except that you have to reserve a static name of an interface linked to the /ppp secret row representing the client under /interface l2tp-server. The dynamically created interface can be made a member of the list or a rule can refer to it, but when the client disconnects and re-connects, these items will “hang in the air”.
Hi Sindy, I just added interface list as BASE on l2tp client and server profiles. Do I need to reconnect tunnel for new settings to apply? Because currently I am still not getting through.
Thanks Will have to do it later as tunnel is active at the moment. But I have good enough pointers to make this work. Which option do you prefer considering long term and variation in number of remote sites? The first one sounds good to me - “set and forget”. If I remove remote site I don’t have to worry about any other setting.
Just as an aside, the rule
add action=accept chain=input comment=“accept L2TP” dst-port=1701 protocol=udp
also permits access to the L2TP server for traffic which is not encapsulated with IPsec. Whilst the L2TP server should reject these if use-ipsec=require is specified, you can definitively block non-encapsulated traffic by changing the rule to
add action=accept chain=input comment=“accept L2TP/IPsec” dst-port=1701 protocol=udp ipsec-policy=in,ipsec
The sad reality is that use-ipsec=required only prevents the incoming L2TP connection from being accepted if the initial L2TP request doesn’t arrive encrypted via an IPsec SA. But if the IPsec session breaks later, the L2TP session happily continues.
EDIT:
Until recently, the IPsec policy created dynamically for a remote L2TP client used to be placed right below the policy template it has been generated from, so it was possible (and recommended in Mikrotik manual!) to place a policy action=discard protocol=udp src-address=local.ip.used.for.l2tp-ipsec src-port=1701 to the end of the /ip ipsec policy list, causing incoming packets to UDP port 1701 to be dropped if they didn’t match any previous policy on that list. However, several RouterOS releases ago, the policies created dynamically if L2TP is configured with use-ipsec set to yes or required started to be placed to the very end of the policy list, so this method cannot be used any more. And this change has not been compensated by checking all received L2TP packets, not just the first one, for a match to some policy if use-ipse is set to required.
As the Mikrotik manual recommends, this can be prevented by adding an action=discard protocol=udp src-address=local.ip.used.for.l2tp-ipsec src-port=1701 policy to the end of the /ip ipsec policy list at the L2TP server machine, causing incoming packets to UDP port 1701 to be dropped if they didn’t match any previous policy on that list. This is done at packet, not connection, level, hence it works also mid-connection. It takes some time, however, until the server notices that the IPsec connection is dead, and the plaintext L2TP packets continue to travel from the client to the server during that time, so an observer somewhere on the path between the two can see their contents.
You mean top? My dynamic policy is placed at the top, above template.
I would expect tunnel to “collapse” if ipsec session breaks and ipsec is required.
How can it happily continue without ipsec? How does it “encrypt” and continue if there is no ipsec session. Are these “two processes” so independent?
That is way beyond my networking knowledge, just expressing my layman’s curiousity
Lovely, I didn't remember it correctly and made some additional mistakes. The release notes for 6.47 actually state: *) ipsec - place dynamically created IPsec policies by L2TP client at the begining of the table;
and in the release notes for newer versions I could not find anything related.
But nevertheless, my policy table on the 6.47.8 looks as follows:
[me@myTik] > ip ipsec policy print
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 192.168.225.11/32 192.168.234.11/32 all none
1 T * ::/0 ::/0 all
2 DA l2tp-in-server no 192.168.227.47/32 192.168.227.11/32 udp encrypt unique 1
3 192.168.227.47/32 0.0.0.0/0 udp discard
So the method with action=discard policy actually works, and the eventually existing policies before the template are also not shadowed, which is good for other scenarios.
The policy is being added to the bottom of the list in 6.46.8 which is not important any more; maybe the "change" in 6.47 mentioned above was actually a fix of a bug introduced earlier and both the bug and the change were only related to the L2TP client role.
Will have to do it later as tunnel is active at the moment. But I have good enough pointers to make this work. Which option do you prefer considering long term and variation in number of remote sites? The first one sounds good to me - “set and forget”. If I remove remote site I don’t have to worry about any other setting.
How does it “encrypt” and continue if there is no ipsec session. Are these “two processes” so independent?