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?
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
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.
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?
Both captures are from the router’s packet sniffer, not from the endpoint.
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.
Phew, thanks for the explanation, that’s some next-level Wireshark mastery.
Now, putting the sniffing aside and getting back to the original issue and its solution, could anyone explain why the connection behaves as expected only when the L2TP IP pool is completely outside my internal network range? And is this even a best practice solution?
I’ve found tons of setup guides, some use a subnet within the rest of the network, others use a completely different one. The problem is that, realistically, both approaches seem to work, but not for my specific requirements.
Thanks!
If the client connected using an IP / layer3 VPN has an address which falls within the subnet used on a local ethernet / layer2 network it requires the use of proxy-ARP. Note the naming of L2TP can be misleading - it refers to layer2 tunneling of PPP packets, not the client IP data itself.
Hi,
Thanks for your help. I figured out what the problem was, largely thanks to our conversation. Proxy-ARP indeed needs to be on the root-bridge, but the “problem” was that all guides logically assume basic settings. However, I also had a VLAN interface in the path, where proxy-ARP also needs to be enabled (the VLAN is in the same subnet as the addresses I was assigning for L2TP).
Thanks again!