Community discussions

MikroTik App
 
Rohllik28
just joined
Topic Author
Posts: 7
Joined: Mon Mar 06, 2023 3:10 pm

Use specific IP in internal network using L2TP

Thu Apr 18, 2024 5:36 pm

Hello,

I am setting up Windows Firewall on VMs and, among other things, I am restricting the range of addresses that can connect via RDP. I encountered a problem that when using L2TP, I can't connect to the VM unless I add the IP of the router itself to the scope, even though I have set a specific address in the secrets to be used for L2TP. It's as if I were connecting to RDP via L2TP from outside rather than from the internal network. What causes this?
 
LdB
Member Candidate
Member Candidate
Posts: 164
Joined: Thu May 20, 2021 4:23 pm

Re: Use specific IP in internal network using L2TP

Sat Apr 20, 2024 6:18 am

The internal RDP traffic is being NAT'ed first to the outside router IP.

The solution is simple on the firewall setup and entry address for the RDP range
So something like
/ip firewall address-list
add list=RDP-Range address=xxx.xxx.xxx.xxx/yy
Now on the outbound NAT goto it's source-address list and tick the NOT box and select RDP-Range in drop down

It now NAT's everything like it always has EXCEPT the source addresses contained in RDP-Range
So your NAT is now selective

You will likely have to do the reverse but same for the VM traffic coming back.
What you are trying to setup is an IP route between the two ranges and only after that does non local router traffic get NAT'ed to internet
 
Rohllik28
just joined
Topic Author
Posts: 7
Joined: Mon Mar 06, 2023 3:10 pm

Re: Use specific IP in internal network using L2TP

Thu May 09, 2024 10:27 am

Thx for answer LdB.
I'm not 100% sure what you meant. I understood that I should add to the masquerade rules so that IPs from the address list, which is the same as the pool for L2TP addresses, are not translated. I did that, but unfortunately, it was unsuccessful.
I did not understand the second part about "reverse for VMs" at all.

However, I managed to achieve what I needed.
I created a new PPP profile for which I set the remote address pool in a different range than my internal network (which is on VLAN if that is relevant). Now I can connect to the VMs without having the router allowed in the inbound rules.
So, I have a working solution, but I would like to know why it didn't work in the first place—fixing something without understanding how it was fixed is useless for the future.

In Wireshark, I see that the ACKs were duplicated—one ACK came from the L2TP interface address and the other from the router. Then some strange retransmissions and finally, the connection was established through the router, what does that mean?? This was captured at a time when I had an active loopback rule.
Image

The second Wireshark capture is without the loopback; there, packets were just retransmitted/discarded. I had some suspicions about MTU or MSS because the IP header had the do not fragment option set, but it wasn’t due to that. I also noticed that VLAN headers appeared, which shouldn't be there, right?
Image

Both captures are from the router's packet sniffer, not from the endpoint.
 
sindy
Forum Guru
Forum Guru
Posts: 10219
Joined: Mon Dec 04, 2017 9:19 pm

Re: Use specific IP in internal network using L2TP

Sun May 12, 2024 11:25 am

A lot of Wireshark output may be confusing until you learn a bit about what it works under the hood.

The router's packet sniffer uses the old PCAP format, not the newer PCAPNG, so there is no information about the interface on which a given packet/frame has been captured. Besides, if your L2TP traffic is encrypted using IPsec and there is no MPPE in the PPP transport packets themselves (which is a correct approach as there is no need for the weak MPPE is you have IPsec), Wireshark can dissect the PPP transport packets all the way to the payload, so since it shows the innermost protocol in the packet list, it displays the plaintext PPP transport packets as TCP ones, and lets the TCP dissector handle them like any other TCP ones. To obfuscate things even more, if you sniff on an interface through which IPsec transport packets come in, the plaintext version of their payload appears in the sniff; the same does not happen in the opposite direction, i.e. the plaintext packets whose IPsec-encrypted version leaves through that interface are not shown in the sniff.

And then there's the fact that the Wireshark TCP dissector doesn't care about interface ID even if it is there, it only looks at the IP addresses and port numbers when matching a packet to a particular TCP session. So if the capture file contains multiple copies of the same packet that have been sniffed on different interfaces, it treats the second and further ones as retransmissions of the first one.

Who is online

Users browsing this forum: Majestic-12 [Bot] and 42 guests