Remote (L2TP/IPsec) clients still isolated, how we cam allow smb/rdp access between them?

RouterOS General
1

Have a good day to all experienced microtik users !

We have CCR1009-7G-1C-1S+ router acting as L2TP/Ipsec vpn gateway for remote users can join “main office” network.
37.213.241.55/24 on combo interface see to ISP. Local network 192.168.10.0/24 on br1-lan with proxy-arp
dhcp pool for local clients 192.168.10.50-99, vpn gateway 192.168.10.100, vpn 192.168.10.101-199 i.e. local and remote clients share same addess space.
Remote clients easily connect, have smb / rdp access to the server. Can ping vpn-gateway, main gateway, server and hosts. But not visible from the local network and do not see each other so we can’t have a smb/rdp access between remote clients and even local and remote clients. For example remote receive 192.168.10.199 address and it can’t be pinged from server, hosts and even microtik terminal. We think some problem in firewall rules presumably in the forward chain but can’t understand there exactly… and already many time rewrite rules with no visible result

If someone have experience with this - please help us to solve this problem !

Here is a main parts of config

sep/04/2018 06:58:48 by RouterOS 6.42.7

software id = 3R4P-DLDB

model = CCR1009-7G-1C-1S+

Interfaces

/interface bridge
add arp=proxy-arp name=br1-lan
/interface ethernet
set [ find default-name=combo1 ] comment=“WAN port” name=combo
set [ find default-name=ether1 ] name=eth1
set [ find default-name=ether2 ] name=eth2
set [ find default-name=ether3 ] name=eth3
set [ find default-name=ether4 ] name=eth4
set [ find default-name=ether5 ] name=eth5
set [ find default-name=ether6 ] name=eth6
set [ find default-name=ether7 ] name=eth7
set [ find default-name=sfp-sfpplus1 ] name=sfpplus
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=br1-lan interface=eth2
add bridge=br1-lan interface=eth3
add bridge=br1-lan interface=eth4
add bridge=br1-lan interface=eth1
add bridge=br1-lan interface=eth5
/interface detect-internet
set internet-interface-list=all wan-interface-list=all
/interface l2tp-server server
set authentication=mschap1,mschap2 default-profile=“L2TP C2S” enabled=yes ipsec-secret=xxxxx use-ipsec=yes

IP address

/ip address
add address=192.168.10.1/24 comment=“lan gateway” interface=br1-lan network=192.168.10.0
add address=37.213.241.55/24 comment=“wan gateway” interface=combo network=37.213.241.0
add address=192.168.1.1/24 comment=“kbserver ikvm” disabled=yes interface=eth7 network=192.168.1.0
/ip pool
add comment=“local clients” name=dhcp-lan ranges=192.168.10.50-192.168.10.99
add comment=“remote clients” name=dhcp-vpn ranges=192.168.10.101-192.168.10.199

#Firewall filters
/ip firewall filter
add action=accept chain=input comment=“emergency remote access” src-address-list=remote_access
add action=accept chain=input comment=“local access to winbox, webfig” in-interface=!combo src-address=192.168.10.0/24
add action=drop chain=input comment=“block external dns requests” disabled=yes dst-port=53 in-interface=combo protocol=udp
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1h chain=input comment=“add ssh attempts to ssh_blacklist for 60 min” dst-port=22 protocol=tcp
add action=drop chain=input comment=“block ssh brute forcers” dst-port=22 log=yes log-prefix=" — SSH ATTEMPT — " protocol=tcp src-address-list=ssh_blacklist
add action=accept chain=input comment=“allow established/related connections” connection-state=established,related
add action=drop chain=input comment=“drop invalid connections” connection-state=invalid
add action=accept chain=input comment=“accept ping from remote_access” connection-state=new protocol=icmp src-address-list=remote_access
add action=accept chain=input comment=“accept ike” connection-state=new dst-port=500 protocol=udp
add action=accept chain=input comment=“accept ipsec-esp” connection-state=new protocol=ipsec-esp
add action=accept chain=input comment=“accept ipsec-ah” connection-state=new protocol=ipsec-ah
add action=accept chain=input comment=“accept l2tp” connection-state=new dst-port=1701,4500 protocol=udp
add action=drop chain=input comment=“drop everything else”
add action=accept chain=output comment=“allow only non-invalid connections” connection-state=!invalid
add action=drop chain=output comment=“drop everything else”
add action=accept chain=forward comment=“allow established/related connections” connection-state=established,related
add action=drop chain=forward comment=“drop invalid connections” connection-state=invalid
add action=accept chain=forward comment=“accept from lan to wan” in-interface=!combo out-interface=combo
add action=drop chain=forward comment=“drop everything else” disabled=yes

L2TP / IPSec

/ppp profile
add change-tcp-mss=yes comment=“Remote VPN clients-to-site with complete lan access” dns-server=192.168.10.1 local-address=192.168.10.100 name=“L2TP C2S”
remote-address=dhcp-vpn wins-server=192.168.10.1
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des
add disabled=yes enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des name=C2S
/ip ipsec peer
add address=0.0.0.0/0 dh-group=modp1024 enc-algorithm=aes-256,aes-192,aes-128,3des exchange-mode=main-l2tp generate-policy=port-strict secret=
XXXXXXXXXXXXXXXXX send-initial-contact=no
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0

2

It is extremely unusual to block anything on the output chain of any router, these rules may be related to your issue.

3

Thank you for this info !
in these rules (as I think, please correct me if this is not really true ))) we accept all connection-state other than invalid


add action=accept chain=output comment="allow only non-invalid connections" connection-state=!invalid disabled=yes
add action=drop chain=output comment="drop everything else" disabled=yes

See screenshot please https://yadi.sk/i/9f8XNgNS3aqQM6
We try to disable all rules related to output and forward chain at all but with no result…

As I understand in input chain we directly allow only L2TP / IPSec related protocols and established/related connection, may be we miss some protocol required for arp right work ?

4

True

False, because the L2TP transport (which is the only traffic relevant to the issue to be handled by chain=output) is working, otherwise the traffic between L2TP clients and the LAN would not get through. So these rules could only affect communication between a client and the Mikrotik itself but not between two clients, and they don’t as connection-state=!invalid is not a very restrictive condition.

So let’s concentrate on the forward rules, and we shall find that the only rule permitting new transit (forward) connections permits them to be established if the output interface is the WAN one:

action=accept chain=forward comment=“accept from lan to wan” in-interface=!combo out-interface=combo

So it is actually quite surprising that at least something works already now.

So to check whether this is the only issue, remove the out-interface=combo condition from the rule above. It will permit any connection to be established except those coming from outside. If it helps two L2TP clients to talk to each other and to make them reachable from the LAN, you can set up more restrictive rules permitting only what really needs to be permitted. Do not test the result from/to Mikrotik itself because these packets are handled by input and ouptut chains, test between a host on LAN and an L2TP client and between two L2TP clients.

But don’t forget that the embedded Windows firewall is very strict so by default the devices don’t even respond to pings, so make sure that response to pings is permitted and/or that the RDP server is allowed to listen on the L2TP interface before testing.

5

Thank you a lot for this explanation !

I really forgot that the ping from the microtik is processed by the output chain rules.
You are also absolutely right about out-interface=combo when drop rule on the bottom of forward chain is active - l2tp really not work ))
But even when we completely disable all rules in output / forward chains and allow full icmp traffic in input section - ping still not come from remote clients to lan…

For example 192.168.10.194/24 client send ping to 192.168.10.198/24 I will see packets in torch monitoring on 192.168.10.194/24 and further is blackhole.
Even in br1-lan bridge I can’t see ANY activity in torch from 192.168.10.194/24

6

And may it be related to L2TP server defenition w/o directly setting an br1-lan bridge ?


add change-tcp-mss=yes comment="Remote VPN clients-to-site with complete lan access" dns-server=192.168.10.1 local-address=192.168.10.100 name="L2TP C2S" remote-address=dhcp-vpn wins-server=192.168.10.1

on the other hand dynamic route to remote L2tp clients is up and I aggain still no idea about roots of this problem…


Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0          37.214.235.80   37.214.235.1		1
 1 ADC  37.214.235.0/24    37.214.235.80   combo		0
 2 ADC  192.168.10.0/24    192.168.10.1    br1-lan		0
 3 ADC  192.168.10.194/32  192.168.10.100  <l2tp-xx@xxxx>	0
 4 ADC  192.168.10.198/32  192.168.10.100  <l2tp-zz@zzzz>	0

I still dig further and see that vpn-gateway 192.168.10.100 receive ping but communication between remote hosts and main gateway abscent. Any ideas ?

7

Yes I believe I see the problem. Local address for vpn should be 192.168.10.1, not 192.168.10.100

8

Not really - his only non-invalid drop rule on the forward chain was disabled, according to the export above.

9

thank you all for the suggestions !

As I understand local-address in this l2tp profile configuration is the aggress of vpn-gateway


add change-tcp-mss=yes comment="Remote VPN clients-to-site with complete lan access" dns-server=192.168.10.1 local-address=192.168.10.1 name="L2TP C2S" remote-address=dhcp-vpn wins-server=192.168.10.1

and this address may be any in 192.168.10.0/24 subnet because of dynamicaly created l2tp interfaces and dynamic routes.
so as I understand while it work correctly not else mather that local-address is set on l2tp profile. For example let see: route #2 will forward any packets adressed to 192.168.10.0/24 to br1-lan gateway. Also as I understand these packets are not NATed


Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU MAC-ADDRESS      
 0  R  ;;; WAN port
       combo                               ether            1500  1580      10222 B2:64:F4:09:59:9D
 1  RS eth1                                ether            1500  1580      10222 B2:64:F4:09:59:9E
 2   S eth2                                ether            1500  1580      10222 B2:64:F4:09:59:9F
 3   S eth3                                ether            1500  1580      10222 B2:64:F4:09:59:A0
 4   S eth4                                ether            1500  1580      10222 B2:64:F4:09:59:A1
 5  RS eth5                                ether            1500  1580      10222 B2:64:F4:09:59:A2
 6     eth6                                ether            1500  1580      10222 B2:64:F4:09:59:A3
 7  R  eth7                                ether            1500  1580      10222 B2:64:F4:09:59:A4
 8     sfpplus                             ether            1500  1580      10222 B2:64:F4:09:59:9C
 9 DR  <aaa@aa>           l2tp-in          1400
10 DR  <bbb@bb>                  l2tp-in          1400
11 DR  <ccc@cc>                l2tp-in          1400
12  R  br1-lan                             bridge           1500  1580            B2:64:F4:09:59:9E




Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0          27.214.245.14   27.214.245.1             1
 1 ADC  27.214.245.0/24    27.214.245.14   combo                     0
 2 ADC  192.168.10.0/24    192.168.10.1    br1-lan                   0
 3 ADC  192.168.10.197/32  192.168.10.1    <aaa@aa>        0
 4 ADC  192.168.10.198/32  192.168.10.1    <bbb@bb>        0
 5 ADC  192.168.10.199/32  192.168.10.1    <ccc@cc>        0

I try to set 192.168.10.1 and restart router but with no result… and even disable bottom drop rule in firewall inpit chain (in forward and output chains all filters are already disabled)

So I can not take in mind what ever can cause this problem. I understand an static ip in l2tp-secret an static ip-sec-policy, static routes option, but this is hard to handle and I belive that dynamic scheme must work. May this issue be related to ESP pipeline so some packets come non decrypted ?

10

Not exactly true, this address may be any address that the router has in any subnet, because each connected user is on their own /32 network, and the gateway itself can be a /32 as well. It does act as a ‘gateway’ of sorts but not in the traditional sense (due to point-to-point addressing), so any IP that is actually bound to the router will work, but before you were using an address that was not bound to the router. I have seen this work before in some cases, but it is better to do it properly and use an actual IP bound to the router.

Describe what you mean by “no result” - the main network still cannot ping the connected users? is the firewall on the connected systems blocking it? And the users cannot ping each other? If the problem remains (but all users can ping the 192.168.10.1 IP itself) this strongly suggests that the firewalls on the connected users’ systems are blocking the traffic. If IPsec were failing you should not even be able to ping 192.168.10.1 from the connected systems.

Also, your MikroTik cannot act as a WINS server unless you are using something like metarouter to run it in a virtual machine. You would need to have a separate WINS server. So I highly doubt that setting the mikrotik 192.168.10.1 as WINS server will do what you want.

11

Just as an overall tip, your VPN users are not on the same subnet as the main systems (192.168.10.0/24) even though they may appear to be.

If you imagine your 192.168.10.0/24 network as a ship, each L2TP VPN client that is connected is a sortof “one-man-lifeboat” individually attached to the ship with a rope. Each of these ‘lifeboats’ (connected L2TP clients) are in their own network-of-one, but the computers in the 192.168.10.0/24 network mistakenly think those lifeboats are on the same network as the ship due to their addresses, which seem to fall within the 192.168.10.0/24 range, and therefore they cannot find these addresses when looking on the ‘ship’ for that client.

The proxy-arp setting that you are using is a strange workaround for this problem, it is like someone in the ship (responding to a person mistakenly believing Mr. X or Mrs. Y is actually aboard ship) saying “oh you want Mr. X? He is actually temporarily relocated to Lifeboat X”, “oh you want Mrs. Y? She is actually temporarily relocated to lifeboat Y”, etc.

Instead of using proxy-arp, you would get a similar result by assigning your L2TP VPN clients addresses in a separate subnet, ex. 192.168.11.0/24, then you do not need to use the proxy-arp setting (because the address is different, the computers know that those clients are not on the ‘ship’ without needing to be informed of this fact by a proxy).

Whether you use proxy arp or different networks, the behavior of your overall setup is similar to the idea of different networks per client - your configuration will behave like your connected users are on 192.168.10.0/24, but the VPN users each have their own additional subnet (almost like 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24), except instead of /24’s, these are /32’s in reality, subnets of one.

12

Thank you a lot, mducharme !

Excellent, you are the genius of networking ))
In the firewall rules on my hosts - rdp and icmp-echo v.4/6 are evidently enabled for private networks in the level of windows firewall preset rules.
And I’am stupidly stick to Microtik settings being absolutely sure that everything is passing through the firewall on the hosts…
but when I completely disable firewall - pings and rdp sessions both start to work correctly !

As it turned out Windows firewall treats L2TP traffic as belonging to the “public” network for rdp. And for the icmp-echo in general, the resolution of all preset rules for this type of traffic (i.e.,v. 4/6 for “public” / “private” networks) does not work at all and only after creating a custom rule - ping starts to be correctly accepted on hosts.

How can I buy you a beer ?! :smiley:

13

Glad you got your issue sorted, but do not only thank me – it looks like @sindy also correctly pointed out the possible issue (although I didn’t notice when I was responding to your post at first):

14

Great thanks to all who help to find decision !!!

And in gratitude, here are a few winter photos from places deep in Siberia
https://yadi.sk/i/kDVd6WYm3Uk93q, https://yadi.sk/i/oQik4OT_3Uk9Cj, where we install Microtik hardware now ))

And also please help me to understand two more things about this configuration

  1. When as mducharme advised I put all remote clients in 192.168.8.0/24 network with 192.168.8.1 vpn-gateway and all local clients in 192.168.10.0/24 network with 192.168.10.1 gateway in br1-lan interface - all work fine but remote clients can’t see local network resources when adressing by ip. How I can make ip adresses from local network availlable to remote clients, only by using NAT or may by some more elegant way?
  2. We don’t have a dedicated DNS server in our local networks but host can be accessible by domain name like \mediaserver inside lan. But remote clients can access to local resource only by ip address, why it happens?

Best regards, Ivan

15

This is legacy back from times whe Microsoft implemented their own networking stack for windows for workgroups and didn’t use IP with supporting services (such as DNS). When they started to support IP, they did it in a backward compatible way. And things are still done this way. Part of file services is do called NetBIOS name resolution, so one can use windows machines names to use certain services. However: windows services normally work only inside same network because broadcasts are used for discovery of servers and other workgroup members. This can change if there’s domain controller / active directory server present.

16

You shouldn’t have to use NAT, you also don’t really need to use 192.168.8.1 as a vpn-gateway. You can put all remote clients in 192.168.8.0/24 and use 192.168.10.1 as the local-address for the VPN. I realize that may seem strange, but remember the VPN gateway address is entirely independent of the endpoint addresses, it is not like a traditional gateway. The reason is that the VPN network is not a traditional network, but is instead a collection of individual /32 single-ip networks. VPN clients can get addresses from 192.168.8.0-192.168.8.255 inclusive, since it is not a regular network but instead a collection of /32’s, there is no reserved network address/broadcast address. The router itself does not need to have an address in the 192.168.8.0/24 range. Do not bother to give the router an ip address in the 192.168.8.0/24 range and instead use 192.168.10.1 as the local-address.

If you can’t get to the local network resources when addressing by IP with the above configuration, it is due to firewall blocking. Perhaps the MikroTik firewall is blocking some traffic if there is a rule set to only allow the 192.168.8.0/24 range, or it could be that the Windows firewall has some setting that prevents connections except from the directly connected network attached to the computer. Either way, the best solution is to adjust the firewall.

To clarify and echo mkx’s comment, it is because inside the LAN it uses broadcasts for name resolution, and those broadcasts will not work for VPN clients due to the fact that they are on different individual /32 networks. You need DNS or WINS for netbios name resolution on a different network.

17

Thank you all !

I understand about dns / wins server and because we now not use domain I’m going to raise up wins server on Windows Server 2012R2

But when I make as mducharme suggest and separate vpn-clients to 192.168.8.0/24 with 192.168.10.1 local-address, gatewey receive pings but all other resources in lan still unaccesible


 
 1   ;;; Remote VPN clients-to-site with complete lan access
name="L2TP C2S" local-address=192.168.10.1 remote-address=dhcp-vpn use-mpls=yes use-compression=default use-encryption=yes only-one=default 
change-tcp-mss=yes use-upnp=default address-list="" dns-server=192.168.10.1 on-up="" on-down=""




 # NAME                                                                                                                        RANGES                         
 0 ;;; local clients
   dhcp-lan                                                                                                                    192.168.10.50-192.168.10.199   
 1 ;;; remote clients
   dhcp-vpn                                                                                                                    192.168.8.50-192.168.8.255

As I understand independent /32 boats by rope come to 192.168.10.1. This is a bridge with proxy-arp so packets must be forwarded to hosts in 192.168.10.0/24. Right?

18

Thank you all !

I understand about dns / wins server and because we now not use domain I’m going to raise up wins server on Windows Server 2012R2

But when I make as mducharme suggest and separate vpn-clients to 192.168.8.0/24 with 192.168.10.1 local-address, gatewey receive pings but all other resources in lan still unaccesible


 
 1   ;;; Remote VPN clients-to-site with complete lan access
name="L2TP C2S" local-address=192.168.10.1 remote-address=dhcp-vpn use-mpls=yes use-compression=default use-encryption=yes only-one=default 
change-tcp-mss=yes use-upnp=default address-list="" dns-server=192.168.10.1 on-up="" on-down=""




 # NAME                                                                                                                        RANGES                         
 0 ;;; local clients
   dhcp-lan                                                                                                                    192.168.10.50-192.168.10.199   
 1 ;;; remote clients
   dhcp-vpn                                                                                                                    192.168.8.50-192.168.8.255

As I understand independent /32 boats by rope come to 192.168.10.1. This is a bridge with proxy-arp so packets must be forwarded to hosts in 192.168.10.0/24. Right?

19

With this configuration you don’t need proxy-arp. Proxy arp is like having a guy on the “ship” redirecting people who think you are actually on the “ship”, letting them know that they can send through them as a proxy to get to you.

The reason why proxy arp is needed with the config you had before is because the computers on the main network think that the VPN client is on the same network as them, they will not send through a router and instead do an ARP request, and that will fail.

Proxy arp is a bandaid fix for this situation. This provides an ARP proxy responding to those requests, telling the computers to send those packets to the router.

You don’t need the bandaid proxy-arp fix when your VPN clients are in the 192.168.8.0/24 range and your local network is in 192.168.10.0/24, because the computers on your local network can tell that the VPN computers are not on the ‘ship’ and know that they have to send packets to the router instead of trying to send them directly. This is the right way of doing it, and it works without proxy arp.

If the other resources in the LAN are still inaccessible with this setup, it is due to an incorrect firewall configuration somewhere.

20

I think I probably know what is happening. I checked my Windows Firewall and many rules default to the traffic being allowed from “local subnet only”, i.e. the subnet that the computer is directly connected to. You might have to change those rules to allow the 192.168.8.0/24 subnet as well.