Hello,
i would appreciate if you guys could help me on this.
Lets assume 2 sites, A and B.
I have a RB at site A and a RB at site B, I’ve set up a L2TP vpn server (with ipsec) on site A and a L2TP vpn client on site B connecting to site A - this is working fine
Internal network on site A behind RB is: 172.17.0.0/16
Internal network on site B behind RB is: 172.16.100.0/24
L2TP vpn network is 10.17.0.0/24
server 10.17.0.1
client 10.17.0.101
I have added route 172.17.0.0/16 on site B pointing to GW 10.17.0.1
I have added route 172.16.100.0/24 on site A pointing to GW 10.17.0.101
facts:
from RB at both sides I can reach (icmp ping) any internal host, including L2TP network.
from internal network at site B I can reach any internal host on site A
from internal network on site A I can reach only site B’s L2TP in terface address.
problem:
I can’t reach any internal host of site B from internal network of site A
I have tried setting src-nat and masquerade rules at site A, trying to hide internal net behind L2TP address, but it didn’t work.
Do you guys have any clue how could I achieve this?
Since the routing works bidirectionally (as you can ping anything on server site A from client site B and the responses do come back), I’d assume the rules in chain forward of /ip firewall filter at client site B do not allow packets coming in via the L2TP tunnel to be forwarded to the LAN subnet. This is an expected behaviour of the default firewall rules, you have to modify them appropriately. As the default rules only match on interface names (or, more precisely, interface lists), the src-nat or masquerade rules at the server site A have no effect on this.
I do have accept rules at both sides, but I don’t know if they are correct, I just added an accept for both src and dst fields with respective remote network.
site A filter:
site B filter:
I’m sorry i gave an incorrect information on my post, I can reach both routers from internal networks, but I can’t reach the internal networks from each other
ex:
172.16.100.65 (site B desktop client) can reach 172.17.7.1 (router’s internal interface address), but can not reach 172.17.7.7 which is a server behind router on site A
The same thing happens on site A
I do have routes to remote netwroks on both sides:
Site A routes:
Site B routes:
Another relevant information, when I do a pcap using torchj tool on l2tp interfaces I see the packets coming from the remote internal networks.
Sorry for my bad english, I hope you could understand.
Instead of screenshots on a 3rd party site, please post the export of both routers’ configurations, see my automatic signature below. You can post them as text between [code] and [/code] tags or as a file attachment.
Disable the only static IPsec policy at Site A (RB750Gr3), dst-address=172.17.0.0/16 peer=ccbpinhais src-address=172.16.0.0/16 tunnel=yes.
When a packet matches a traffic selector of an IPsec policy with action=encrypt (which is the default action, hence not shown in export without verbose), it is not sent using the originally chosen gateway even if no security association currently exists for the policy. And if a received packet reverse-matches a traffic selector of an IPsec policy, it is silently dropped by the firewall if it did not arrive via a security association belonging to that policy.
Other than that, the firewall of the 2011 is basically non-existent, does the 2011 get a public IP address on ether5 or a private/CGNAT one?
Removeing those ipsec rules did the trick, now I can access internal nets from both sides.
But those rules were added there dinamically, I didn’t do it, I wasn’t even aware of those rules until now. How to prevent them to be added again?
Regarding RB2011 public ip address, yes it is behind a CGNAT, that’s why it need to be an l2tp client, it can’t receive connections, this was the only way I could set a vpn between those sites, if there is a better option, it would be very welcome.
I can’t imagine how an IPsec peer with a name ccbpinhais, which is used also for other objects in the configuration, and a static policy linked to that peer, could be created in any other than manual way. So either there was another admin of the 750 before you, or you forgot you’ve done some experiments with IPsec.
As for the conection of the 2011 to the 750 some other way - you can use other types of VPNs than L2TP/IPsec but that’s basically it. If you are really concerned about security, IKEv2 with a certificate authentication should be a bit safer than IKE (v1) with a pre-shared key.
I’m pretty sure I’m the only admin, and I didnt add any policy. So much it is true that, after I removed those policies I disabled the l2tp client connection and enabled again and those policies were added back in.
But now the traffic is working even with those policies in place. I really don’t know what happened, maybe after adding the filter rules I should have reset the tunnel to commit changes. I really didn’t understand.
But, anyway, it’s working now and your explanations helped a lot.
It’s two different things. Yes, when you set use-ipsec to yes or required in /interface l2tp-server server settings, a peer and identity are created dynamically, using the default profile; whenever an L2TP/IPsec client connects, a policy is dynamically created using the template policies in policy template group default. All of these are clearly marked as dynamically created ones and not shown in the export. The policy in particular uses the IP address of the WAN through which the L2TP/IPsec connection from the client has arrived as a /32 src-address, and the public IP address from behind which the client connects as a /32 dst-address.
What you had to remove to make it work was a manually created policy, linking the two 172.x.x.x subnets; this policy was shown in the export, was referring to a manually created peer, and matched on those particular subnets, so there was no way for it to be created dynamically.
My understanding was that the peer and policy were remainders of an attempt to create a bare IPsec tunnel between the same sites you’ve now connected using L2TP/IPsec.
