we run multiple sites which are all set-up coherent (mikrotik as gateway, internet dialed up over pppoe on the mikrotik). All sites are connectec site-to-site via IPSec/L2TP. For this i need mainly two firewall rules:
However, we do have a new site I want to connect to. In this setup, the internet dial up is happening on a router I don’t have any access to - so I don’t have any PPPoE-Connection on the Mikrotik. Everything is working fine except the site-to-site connection. In this setup the first rule is slightly different and not working:
As in-interface I configured an ethernet-port and not an PPPoE-connection. The rule isn’t working and I figured already out that it might be related to the ethernet-port. I would have some basic questions to it:
Why are firewall rules on ethernet-ports not working (I considered the difference between chain=forward and chain=input)?
How do I get the connection working? Can i wrap the ethernet-port in some kind of surrogate-pppoe?
Just noticed: on the “non-standard” router the accept filter rule is in chain=forward … should be in chain=input if IPsec is terminated on router itself.
Thank you for your input. Tried also with chain=input - doesn’t work either. I’m under the impression I didn’t explain the setup good enough:
MT <------------------> Internet <------------------> Blackbox Router (enabled routing) <------------> MT
<L2TP/IPSec -------------------------------------------------------------------------------------------L2TP/IPSec>
Just a technical one, for L2TP over IPsec, access to UDP port 1701 need not be permitted on intermediate routers because the L2TP transport packets towards port 1701 are transported encrypted, i.e. either inside plain ESP packets or inside ESP payload encapsulated into UDP packets to port 4500.
So on the intermediate routers, the client must be allowed to establish UDP connection to port 500 on server address. If both the client and the server run directly on public adresses and there is no NAT between them, ESP must be permitted between them as well; if at least one of them is running behind a NAT, the client must be allowed to access port 4500 on server address in addition to port 500.
On the server, the situation is different - access to port 1701 has to be permitted in the input chain, but although a common permissive rule is often used for all three ports (500,1701,4500), the 1701 should actually have a dedicated rule with an additional match condition, ipsec-policy=in,ipsec. The reason is that some VPN clients are configured to fall back to plain L2TP with no IPsec encapsulation, and if access to UDP port 1701 is permitted without checking that the packet comes through the tunnel, you can end up with a plaintext L2TP connection.
Thank you very much for your detailed reply. I adjusted the configuration of the firewall according to your input and the wiki. I tried to cover all possible IPSec setups with this configartion. Therefore, esp, port 500, port 4500 and port 1701 are configured. The setup described is between MT’s without nat-traversal (directly establish internet connection):
Unfortunately, the setup isn’t working. With this configuration, the L2TP-Connetion isn’t established. This is the error log:
initiate new phase (Identity Protection): 172.0.0.1[500]<=>172.0.0.2[500]
phase1 negotation failed due to send error. 172.0.0.1[500]<=>172.0.0.2[500] xxxxxxxxxx
As soon as I remove IPSec policy matcher (in-interface=pppoe-out1) the connection is up and running. Example:
The log shows that IPsec negotiation has failed. I’m not sure why, as your log is too brief. However, the client falls back to L2TP without an IPsec SA to encrypt it, which is why the tunnel gets up if you remove the restriction to IPsec-encrypted connections from the rule.
Thank you for your help!
I looked into detail and didn’t find any solution due to the lack of sufficient log infos. However, I eliminated the L2TP and everything is set up as pure IPSec now. Also the NAT-Traversal is working fine and stable with the IPSec connection.
The reason for L2TP/IPSec was that some sites only have a dynamic wan address. This is now settled with IPSec Policy templates. Just in case someone runs into the same problem here is the configuration:
