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

ivan03rus · Tue Sep 04, 2018 7:35 am

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

mducharme · Tue Sep 04, 2018 8:41 am

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

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

ivan03rus · Tue Sep 04, 2018 10:43 am

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 ?

sindy · Tue Sep 04, 2018 11:14 am

It is extremely unusual to block anything on the output chain of any router,

True

these rules may be related to your issue.

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.

ivan03rus · Wed Sep 05, 2018 5:44 am

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

ivan03rus · Wed Sep 05, 2018 5:52 am

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 ?

mducharme · Thu Sep 06, 2018 12:43 am

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

mducharme · Thu Sep 06, 2018 1:17 am

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

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

ivan03rus · Thu Sep 06, 2018 7:41 am

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 ?

mducharme · Thu Sep 06, 2018 8:06 am

and this address may be any in 192.168.10.0/24 subnet because of dynamicaly created l2tp interfaces and dynamic routes.

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.

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)

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.

mducharme · Thu Sep 06, 2018 8:25 am

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.

ivan03rus · Sat Sep 08, 2018 8:13 am

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 ?!

mducharme · Sat Sep 08, 2018 8:48 am

Thank you a lot, mducharme !

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):

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.

ivan03rus · Sat Sep 08, 2018 10:46 am

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

mkx · Sat Sep 08, 2018 12:59 pm

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?

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.

mducharme · Sat Sep 08, 2018 8:06 pm

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?

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.

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?

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.

ivan03rus · Mon Sep 10, 2018 5:16 am

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?

ivan03rus · Mon Sep 10, 2018 5:17 am

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?

mducharme · Mon Sep 10, 2018 5:44 am

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?

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.

mducharme · Tue Sep 11, 2018 1:59 am

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.

ivan03rus · Thu Sep 13, 2018 11:53 am

Thank you, Mudcharme I can change general CCR settings only at the night when no active users present. So tests get time.
I understand that you say from position of practical network experience. And we want to separate local and remote vpn users in different networks as you propose.
But I something stupidly miss or misunderstand so after a couple of trys this scheme still not work... I think to start from scratch - this is a basic networks statement we re want to make.

192.168.10.0/24 - local users and servers with local gateway: 192.168.10.1
192.168.8.0/24 - C2S (clients-to-site) remote l2tp sessions with 192.168.10.1 as local address
192.168.20.0/24 and so on - S2S (site-to-site) l2tp connections with 192.168.10.1 as vpn gateway
192.168.30.0/24 and so on - networks for IP-CCTV with 192.168.30.1 as local gateway
192.168.40.0/24 and so on - networks for technological lines such as CNC machines, 3D printers etc. with 192.168.40.1 as local gateway

192.168.10.1 on br1-lan with enabled arp as I understand - have a number of attached boats within /32 subnetworks from 192.168.8.0
packets from 192.168.20.1 and all other networks listened above must also come to 192.168.10.1 so hosts in these networks can communicate with server's smb share

I correctly understand that all packets from 192.168.8.0/24 with 192.168.10.1 local address must come into 192.168.10.0/24 networks wih no arp-proxy all other additional actions?
And in case of other networks that we can do for make accessible 192.168.10.0/24 resources for hosts in that networks? I'm completely confused with this...

with 192.168.8.0/24 I try today, check router input-chain and hosts firewall adding by hand 192.168.8.0/24 networks to ICMP v.4 and RDP rules on windows firewall but with no result. I can ping only 192.168.10.1 no further... Tommorow I will try to completely turn off windows firewall on hosts and file server too

And one more question I have single srcnat rule

add action=masquerade chain=srcnat dst-address=!192.168.10.0/24 out-interface=combo

May packets from 192.168.8.0/24 be nated and so on lost for lan ?

ivan03rus · Thu Sep 13, 2018 12:04 pm

I probably did not see an elementary way on the second question
and this set of static rules will work for merging 10.0/24 and 20.0/24 networks is not it ?

add distance=1 dst-address=192.168.20.0/24 gateway=192.168.20.1 pref-src=192.168.10.1
add distance=1 dst-address=192.168.10.0/24 gateway=br1-lan pref-src=192.168.20.1

mducharme · Fri Sep 14, 2018 12:00 am

192.168.10.0/24 - local users and servers with local gateway: 192.168.10.1
192.168.8.0/24 - C2S (clients-to-site) remote l2tp sessions with 192.168.10.1 as local address
192.168.20.0/24 and so on - S2S (site-to-site) l2tp connections with 192.168.10.1 as vpn gateway
192.168.30.0/24 and so on - networks for IP-CCTV with 192.168.30.1 as local gateway
192.168.40.0/24 and so on - networks for technological lines such as CNC machines, 3D printers etc. with 192.168.40.1 as local gateway

I correctly understand that all packets from 192.168.8.0/24 with 192.168.10.1 local address must come into 192.168.10.0/24 networks wih no arp-proxy all other additional actions?

Yes, the packets will get routed with no additional actions without arp proxy.

And in case of other networks that we can do for make accessible 192.168.10.0/24 resources for hosts in that networks? I'm completely confused with this...

This will happen automatically as well. When you add new networks to the MikroTik it automatically adds connected routes, so you have connectivity between the networks without having to do anything, unless there are firewall rules blocking the traffic.

with 192.168.8.0/24 I try today, check router input-chain and hosts firewall adding by hand 192.168.8.0/24 networks to ICMP v.4 and RDP rules on windows firewall but with no result. I can ping only 192.168.10.1 no further... Tommorow I will try to completely turn off windows firewall on hosts and file server too

Traffic from your VPN users on 192.168.8.0/24 to the 192.168.10.0/24 network resources will hit the forward chain, not the input chain. If this is being blocked in the forward chain, it will not work.

And one more question I have single srcnat rule
Code: Select all
add action=masquerade chain=srcnat dst-address=!192.168.10.0/24 out-interface=combo
May packets from 192.168.8.0/24 be nated and so on lost for lan ?

No, because you have specified out-interface=combo, packets from the 192.168.8.0/24 to 192.168.10.0/24 are not going out combo and therefore they will not be natted.

I probably did not see an elementary way on the second question
and this set of static rules will work for merging 10.0/24 and 20.0/24 networks is not it ?
Code: Select all
add distance=1 dst-address=192.168.20.0/24 gateway=192.168.20.1 pref-src=192.168.10.1
add distance=1 dst-address=192.168.10.0/24 gateway=br1-lan pref-src=192.168.20.1

You do not need to add any routes like the above. I do not know what you are trying to do. As soon as you add the IP addresses for the two networks onto the router, you will have routing between the two networks automatically, because the connected routes are automatically installed in the routing table. Adding connected routes manually doesn't make any sense at all because you already have them.

ivan03rus · Fri Sep 14, 2018 6:59 am

It's some kind of stupid confusion..

Firewall rules in windows file server allow ANY networks traffic, but I completely disable windows firewall in both file server and clients.
Output / forward chains rules in microtik firewall are all completely disabled too.

Remote client 192.168.8.100/32 with 192.168.10.1 local address. On br1-lan proxy settings: proxy-arp ( I try to set enabled too)
When this client up l2tp session - an dynamic route 192.168.8.10/32 <l2tp-user@aaa> 0 are automaticaly created.
But in result ping to 192.168.10.1 work and all other 10.0/24 hosts are unaccessible... ping from microtik terminal to 192.168.8.100 not work too.

I understan all logic you give but can't understand what else can cause packets from 192.168.8.100/32 are lost abroad 192.168.10.1...

sindy · Fri Sep 14, 2018 9:26 am

@Иван, please post the export of the current configuration (anonymized following the guidelines in my automatic signature). I would myself not choose an address from 192.168.10.0/24 as the "local" address for L2TP clients but it should not be the cause of your trouble. There must be something else.

Also, while pinging the L2TP clients, use /tool torch your-l2tp-interface-name src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=icmp to see whether the packets are leaving but aren't responded or whether they don't even leave. What does the ping say, timeout or some other error? Try pinging the L2TP client both from the Mikrotik itself and from some device on the LAN.

ivan03rus · Fri Sep 14, 2018 11:53 am

Thank you a lot, I don't know this way to monitor packets

/tool torch <l2tp-aaa@aaa> src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=icmp

In attachment my config where 11.22.33.1 is ISP gateway and 11.22.33.54 is CCR1009 wan ip.
I would be very grateful if you tell me in which direction to look for a solution. Because it seems that everything is done correctly)

sindy · Fri Sep 14, 2018 1:21 pm

I can see in the export that you've reverted back to the shared subnet approach with arp=proxy-arp on the bridge, but that doesn't make any difference.

However, what was your reason to set use-mpls in the /ppp profile used to yes? I don't say it is related as you can ping the "local" address from the 2TP clients, but it is unusual.

Other than that, I cannot see anything in the export what would explain the behaviour you describe. All chain=forward and chain=output rules are disabled in the firewall filter, firewall nat rules do not interfere, no firewall mangle rules exist, no /ip route rules exist.

So what did the /tool torch actually show you? Don't care so much about "dst-address" and "src-address", they can be confusing, but watch the packet counts. If none are shown on the interface - the echo requests don't even go that way; if only one direction is shown (Rx or Tx) - the requests go out but are not responded so the issue must be on the L2TP clients' side.

mducharme · Fri Sep 14, 2018 4:07 pm

In addition to using torch, it may also be helpful to use firewall "log" rules for troubleshooting this -- ex. create two forward chain rules, one to log ICMP going from 192.168.8.0/24 to 192.168.10.0/24, and the other to log ICMP going the other way. You should get both the echo request and echo reply logged in this way. That way, you can see where something is dropped when you attempt a ping.

ivan03rus · Mon Sep 17, 2018 7:15 am

Thank you all for your help !

I set mpls to default in l2tp profile, launch torch and log icmp on input/forward chains via firewall rules.
Windows firewall on l2tp client is also disabled.

/tool torch <l2tp-aaa@aaa> src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=icmp

When l2tp client connect with 192.168.10.101 all packets are fixed perfectly in torch/firewall log.
But when l2tp clent connected with 192.168.8.101 ping pass to 192.168.10.1 and all other droped as I see from cmd window in remote hosts.
But in torch and log - nothing ! Even when pings to 192.168.10.1 are passed. In firewall log I see only interaction between file server and NTP server.

And now my mind is cpmpletely stumped...

ivan03rus · Mon Sep 17, 2018 7:30 am

Also as I understand routing inside microtik - when I connect from any private network i.e. 192.168.8.0 etc. to br1-lan 192.168.10.0 - I don't need to set special routing rules because of dynamicaly created route, so RouterOs know how to reach 10.0/24

2 ADC  192.168.10.0/24    192.168.10.1    br1-lan                   0

and way for responce to 192.168.10.101/32 is managed by next dynamic route

3 ADC  192.168.10.101/32  192.168.10.1    <aaa@aa...        0

so everythnig must work

but work that way only for 10.0/24 not for 8.0/24 may it caused by nat-traversal=on in peer settings?

mducharme · Tue Sep 18, 2018 1:19 am

But in torch and log - nothing ! Even when pings to 192.168.10.1 are passed. In firewall log I see only interaction between file server and NTP server.

Show the firewall rules that you are using for logging of the pings. You should have a log rule for both the forward chain and the input chain, to log the packets in both directions.

Also make sure that the L2TP client is getting a default route to go through the VPN, otherwise the client may be trying to send packets out some other interface. Try to traceroute from the client to a 192.168.10.x IP (other than 192.168.10.1) while connected via L2TP to make sure that it is trying to send through the L2TP tunnel and not some other way. It might be that the L2TP client has routes for 192.168.8.0/24 to go through the L2TP tunnel and 192.168.10.1/32, but not 192.168.10.0/24 as a whole. I had assumed all this time that you were adding a default route.

EDIT: It looks like the above is likely the problem, I see that if Windows L2TP client has "add default gateway" switched off, it looks at the address class and auto adds a route for that address class to go across the L2TP tunnel. In this case it would add a route for 192.168.8.0/24 and not add a route for 192.168.10.0/24, this would explain why you can only ping 192.168.10.1

If the L2TP client is certainly trying to send this traffic through the tunnel, and still the packets are not hitting the firewall rule and the rule is set up properly, it might be a problem with a cached route on the MikroTik. I have seen it happen before where if a subnet used to exist and it is removed, the router still caches the old subnet in memory and some functions continue to behave like the route is still there - for instance, a device that is on the former broadcast address of a subnet that used to exist but no longer does can have its traffic silently dropped due to this cache behavior. A reboot will clear the cache if this is what is happening.

sindy · Tue Sep 18, 2018 10:44 am

I agree completely with @mducharme, if you cannot see the packets in /tool torch when you ping 192.168.10.1, they must be taking some other path, and you may actually be pinging a completely different device which has the same IP address in the network to which the client PC is connected.

So just a comment on the nat-traversal=yes - this setting only allows the IPsec tunnel to work if one or both peers are behind a NAT, it does not affect how the payload packets transported by the L2TP are handled. So cannot be related to your issue.

ivan03rus · Wed Sep 19, 2018 8:38 am

Guys you both are realy great in networking !!

Thank you very much for not letting my brain to explode in an attempt to understand what else can work ugly in our CCR )))
As mducharme was wrote - problem be on the way that Windows 7 add routes when "use the default gateway on the remote network" was disabled
So when I tracert 192.168.10.10 I see that packets are sended to unexpected 192.168.2.1 via 192.168.3.247 (my lan interface). This can't come into my mind....

I add "route add 192.168.10.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 24" (where IF corespond to INTERFACE# for 192.168.8.101 assigned to vpn connection) so Windows routing table part related to vpn in result look like this:

      192.168.8.0    255.255.255.0     192.168.10.1    192.168.8.101     21
    192.168.8.101  255.255.255.255         On-link     192.168.8.101    276
     192.168.10.0    255.255.255.0     192.168.10.1    192.168.8.101     41

And all other start to work by predictable manner ))
Aggain many thanks, as I see - you both greatly understand networking and, that it is important, be able to look wider and see non-standard nuances in seemingly obvious things))))

ivan03rus · Thu Sep 20, 2018 6:30 am

One more addition - I try to separate hosts in different networks, routing in Microtik work predictable now,
but on remote l2tp clients static routes for communication with different networks must be added like this

route add 192.168.8.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 25 -p

And I'm really happy with result - because have an abulity to control communication between networks now !!!
And about arp on local bride interface br1-lan it seems to work in arp=enabled and arp=proxy-arp, I have right understanding that proxy-arp in this scenario is not really neccessary?

mducharme · Thu Sep 20, 2018 6:35 am

One more addition - I try to separate hosts in different networks, routing in Microtik work predictable now,
but on remote l2tp clients static routes for communication with different networks must be added like this
Code: Select all
route add 192.168.8.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 25 -p
And I'm really happy with result - because have an abulity to control communication between networks now !!!
And about arp on local bride interface br1-lan it seems to work in arp=enabled and arp=proxy-arp, I have right understanding that proxy-arp in this scenario is not really neccessary?

Correct, proxy-arp is not necessary anymore. It was only needed before (when you were using 192.168.10.x IPs for L2TP) because the other hosts on 192.168.10.0/24 mistakenly assumed that your one-person l2tp "lifeboats" were still on the "ship" with them (due to the fact that they seemed to fit in the 192.168.10.0/24 network), and the proxy-arp was like a person explaining that they actually weren't on the "ship" (network) even though it looked like they were, and how to actually reach them. Now that your clients are on 192.168.8.x, the local systems on 192.168.10.x can tell that the 192.168.8.x clients are not on the same "ship" (network) without needing the proxy to inform them, and will correctly send the packets to the router, so they can get to their destination without proxy-arp. I would switch it back to arp=enabled instead of arp=proxy-arp, it is better, places less load on the router.

If you want to avoid having to add static routes on remote L2TP clients, you can use pure IPsec (IKE road warrior mode-config) instead of L2TP/Ipsec since this can do it automatically with split-include -- the only downside is that you no longer have the ability to set WINS servers, only DNS servers. Mode-config in general supports WINS, since Cisco routers can push this, but MikroTik does not yet support this, and they are unlikely to add support since WINS is deprecated and Microsoft has been trying desperately to get all of their customers to move to DNS instead of WINS. You would have to use DNS instead of WINS for netbios name resolution if you switch from L2TP/ipsec to IKE road warrior mode-config on a MikroTik router.

If you want to experiment with this, here is the documentation:

https://wiki.mikrotik.com/wiki/Manual:I ... t_with_NAT

And a wonderful explanatory video by another MikroTik Certified Trainer:

https://www.youtube.com/watch?v=QlkIbx0Jpoo

ivan03rus · Fri Sep 21, 2018 3:47 pm

Thank you a lot !

It'is really work fine now ))

Scheme with IKE we will try for road warior setup, great idea !

I make 192.168.100.0/24 with 192.168.100.1 local-address for l2tp clients, and 192.168.101.0/24 with 192.168.101.1 local address for sstp clients
with "route add 192.168.10.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 14 -p" added in windows routing tables.

But one thing I can't understand is why when I try to connect via sstp with remote 192.168.101.249 I can't ping l2tp connected clients 192.168.100.16
when I add "route add 192.168.100.0 MASK 255.255.255.0 192.168.100.1 METRIC 21 IF 14" to sstp client windows table In tracert and torch on 192.168.101.249 I see icmp packets destinated to 192.168.10.16 but afrer 192.168.101.1 all packets are droped. On br1-lan arp=enabled.

If I correctly understand the way packets being routed inside microtik - all packets in this example coming from 192.168.101.1 and destinated to 92.168.100.16 are routed across 192.168.100.1 and only packets that are not designated to any of registered on microtik interfaces ip's are nated to wan. Thats right ?

sindy · Fri Sep 21, 2018 5:50 pm

One typo is a typo but two similar ones indicate a misconception. So if you say the SSTP clients get their own addresses from 192.168.101.0/24, the gateway you give them to access other subnets should be from their own subnet, not from the destination one.

So instead of your

route add 192.168.10.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 14
route add 192.168.100.0 MASK 255.255.255.0 192.168.100.1 METRIC 21 IF 14

it should actually read

route add 192.168.10.0 MASK 255.255.255.0 192.168.101.1 METRIC 21 IF 14
route add 192.168.100.0 MASK 255.255.255.0 192.168.101.1 METRIC 21 IF 14

However, it most likely doesn't explain what you describe because the SSTP connections are also tunnels so it doesn't really matter what gateway address you've told the Windows to use as the IF ID is what matters.

The arp setting only matters on point-to-multipoint interfaces (like Ethernet) where you need to translate an IP address to a lower-level (MAC) address of the remote device on the same media segment to which the packets should be sent; it is either the MAC address of the device itself or the MAC address of the gateway. On tunnel interfaces, there is only one lower level address - "the remote end of the tunnel", so no arp request is ever sent as it would be useless (leaving aside that this type of protocol message is only defined for point-to-multipoint interfaces).

In another words, the setting of arp on br1-lan is totally irrelevant for traffic between SSTP clients and L2TP clients as that traffic never hits that bridge.

So as usually, the most likely reason is the firewall setup on the Mikrotik or the end devices. Bear in mind that how the NAT behaves is also part of firewall setup, so if your src-nat or masquerade rule(s) do(es)n't check the out-interface, it is well possible that you src-nat the packet from SSTP client to L2TP client as you forward it, meaning that the response is not routed back to the tunnel.

And if there is no route on the L2TP client to 192.168.101.0/24 via 192.168.100.1 and/or the l2tp interface ID, chances are high that this is the reason why the responses never come to the SSTP client. So look at this first, then at your firewall rules on Mikrotikk as they are right now, and post them if you find nothing.

mducharme · Fri Sep 21, 2018 8:09 pm

I make 192.168.100.0/24 with 192.168.100.1 local-address for l2tp clients, and 192.168.101.0/24 with 192.168.101.1 local address for sstp clients
with "route add 192.168.10.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 14 -p" added in windows routing tables.

But one thing I can't understand is why when I try to connect via sstp with remote 192.168.101.249 I can't ping l2tp connected clients 192.168.100.16
when I add "route add 192.168.100.0 MASK 255.255.255.0 192.168.100.1 METRIC 21 IF 14" to sstp client windows table In tracert and torch on 192.168.101.249 I see icmp packets destinated to 192.168.10.16 but afrer 192.168.101.1 all packets are droped. On br1-lan arp=enabled.

If I correctly understand the way packets being routed inside microtik - all packets in this example coming from 192.168.101.1 and destinated to 92.168.100.16 are routed across 192.168.100.1 and only packets that are not designated to any of registered on microtik interfaces ip's are nated to wan. Thats right ?

Yes your understanding of the routing is correct. Also I agree with Sindy above when it comes to this issue.

When the L2TP or SSTP client connects up, the only route it is guaranteed to get on its own is to its 'default gateway', i.e. the local address configured on the router.

You had been using the local address 192.168.10.1 for L2TP and I would use the same one for SSTP. You don't need for the L2TP and SSTP local address to be different, it is probably actually easier if they are the same, because then you know what the next hop will always be 192.168.10.1 regardless of whether it is an L2TP or SSTP client. Because the local address is a /32 and the PPP IP of the connected L2TP or SSTP client is a /32 you can use any IP address that the router has as a local address, no matter which subnet it appears to be in. The important thing is that the local address that you use is added to the router as an IP address on some interface (doesn't matter which one) under IP->Addresses (I've seen it work without this, but it is technically required, and it may cause problems if it is not there). Since you already have 192.168.10.1 on an interface, using that as a local-address makes perfect sense instead of adding a new address for a local-address.

It is tempting to think that the local address for 192.168.100.0/24 clients should be 192.168.100.1 or that the local address for 192.168.101.0/24 clients should be 192.168.101.1. However, this stems from a misunderstanding. In fact the PPP clients can get an address of 192.168.100.0 or 192.168.100.255 (because it is not really a network), so by giving the router a local-address of 192.168.100.1, all you are doing is making it impossible to use .0 and .1 addresses for VPN clients and adding a useless extra IP 192.168.100.1 to the VPN concentrator router. The only reason the IP is there is to make the person doing the configuration feel better about their configuration since it makes it look more like the way they expect a network to look. You can use 192.168.10.1 as a local-address both for L2TP clients in 192.168.100.0/24 range and SSTP clients in 192.168.101.0/24 range.

ivan03rus · Wed Oct 03, 2018 6:09 am

Thank you guys for helping to see the real moment of misunderstanding )))

So in result I set local address 192.168.10.1 for both SSTP and L2TP remote clients.
100.1-100.254 pool for trusted clients, who must have an smb-access to local server 1.10 an rdp-access to all remote clients
101.1-101.254 pool for regular users who must mave only smb-access to local server 1.10 and rdp-access to local clients

Just brilliant !!!

But one thing I can't understand is WHY?! it work this manner:

This windows route table I have in SSTP clients:

     192.168.10.0    255.255.255.0     192.168.10.1  192.168.101.249     41
    192.168.100.0    255.255.255.0     192.168.10.1  192.168.101.249     41
    192.168.101.0    255.255.255.0     192.168.10.1  192.168.101.249     21

Static route:
     192.168.10.0    255.255.255.0     192.168.10.1      21

Packets are routed well to local-address 192.168.10.1 and then drops...

C:\Users\i_van>tracert 192.168.100.16

Tracing route to 192.168.100.16 with max jumps 30

  1    75 ms    80 ms   111 ms  192.168.10.1
  2     *        *        *     Packet interval timeout.
  3     *        *        *     Packet interval timeout.
  4     *        *        *     Packet interval timeout.
  5     *        *        *     Packet interval timeout.
  6     *        *        *     Packet interval timeout.
  7     *        *        *     Packet interval timeout.
  8     *        *        *     Packet interval timeout.
  9     *        *        *     Packet interval timeout.
 10     *        *        *     Packet interval timeout.

Although a dynamic route to each L2TP/SSTP client exists:

ip route print
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
 2 ADC  192.168.10.0/24    192.168.10.1    br1-lan                   0
 3 ADC  192.168.100.16/32  192.168.10.1    <aaa@aa>        0
 4 ADC  192.168.101.249/32  192.168.10.1    <bbb@bb>        0

I check all the way of icmp packets with torch and find that last place where it can be found is interface dynamicaly created for remote clients.
So packet come from my SSTP host 192.168.101.249 to 192.168.10.1 - received by 192.168.100.16 and sended back, as I understand, to 192.168.10.1 and then droped although I have an dynamic route to 192.168.101.249...

/tool torch <aaa@aa> src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=icmp

ip              icmp        192.168.100.16                              192.168.101.249                                480bps       0bps          1     
MAC-PROTOCOL    IP-PROTOCOL SRC-ADDRESS                                 DST-ADDRESS                                        TX         RX TX-PACKETS RX-PACKETS

Please help me to understand WHY these dynamic routes work in case of L2TP 100.0 clients and not work in case of SSTP 101.0 clients
firewall on the host is set t accept icmp v.4 from 10.0/24, 100.0/24, 101.0/24

ivan03rus · Wed Oct 03, 2018 11:49 am

I want to explain that this behavior of the system is just the desired.
But I want to understand why in one case dynamic routes to remote clients work and not in another to finaly close this question ))

sindy · Wed Oct 03, 2018 12:43 pm

You've again shown just part of the configuration so hard to answer your question. However, when thinking about the icmp travel between the two remote clients from different address ranges (which is a more appropriate name than "subnets" here), you seem to misunderstand the role of IP address 192.168.10.1 in the process:

So packet come from my SSTP host 192.168.101.249 to 192.168.10.1 - received by 192.168.100.16 and sended back, as I understand, to 192.168.10.1 and then droped although I have an dynamic route to 192.168.101.249...

The 192.168.10.1 is only used on the client PCs, and only if it is specified there as a gateway for some route, to identify the tunnel (=point-to-point) interface through which the packet should be sent.

Both SSTP and L2TP tunnels are L3 ones, so only IP headers of the packet are present in the "passenger" packet, no L2 headers. And in the IP header, the source address is the local one of the sender and the destination address is the one of the end recipient. So the 192.168.10.1 is not present in the packet header or data, directly or indirectly; it has been translated to the tunnel interface name (id) at sender and has no other purpose.

Check again your firewall rules and maybe /ppp profile for the explanation why the ping responses do not arrive. From your description it seems that the echo request makes it the whole way from the client to the server, but the echo response from the server arrives to Mikrotik but doesn't leave Mikrotik towards the client. This looks like a misrouting or a firewall rule in the forward chain of the filter, permitting icmp to get in one direction placed before the "accept established,related" rule - hard to be more precise.

mducharme · Wed Oct 03, 2018 9:05 pm

I haven't really worked with SSTP very much. I am actually wondering - why are you using both? You could just use L2TP/IPsec for all clients instead of a mix of L2TP and SSTP. SSTP probably will not perform quite as well as L2TP/IPsec.

Panbambaryla · Fri Apr 03, 2020 7:51 pm

Hi there!

I was struggling with the same problems as Ivan. Finally I decided to do it this way:
1) created another "subnet" for my L2tp/IPSec clients
2) defined forward rules
3) use in Windows 10 PowerShell only once, during initial interface configuration, the command:

Add-VpnConnectionRoute -ConnectionName "VPN Name" -DestinationPrefix "192.168.8.0/24"

with split routing settings on VPN interface (unchecked Use remote gateway in remote network) and therefore I don't need to use:

route add 192.168.8.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 25 -p

every time I connect.

BTW: For Windows 10 it is also worth setting manual metric to 3 in VPN interface, lower than eth interface, to prioritize DNS query to VPN DNS server.

Anyway, I am still interested in using VPN clients IP addresses in the same "subnet" as the LAN device so maybe:
https://wiki.mikrotik.com/wiki/Manual:I ... _Proxy_Arp
is a solution here? I want to make VPN configuration at client's side as simplest as possible that is why I still search for an answer...

But where to set it up to be most usable? On bridge interface it will "forward" all L2 traffic via router's interface. Could someone explain, please?

sindy · Fri Apr 03, 2020 9:10 pm

therefore I don't need to use:
Code: Select all
route add 192.168.8.0 MASK 255.255.255.0 192.168.10.1 METRIC 21 IF 25 -p
every time I connect.

The -p parameter makes that route a persistent one, so it survives a reboot, hence I cannot see why one method should be better than the other. Except that I usually set the gateway address to 0.0.0.0, as it is the interface number, not the gateway address, what matters in case of a tunnel interface like L2TP and/or SSTP.

Anyway, I am still interested in using VPN clients IP addresses in the same "subnet" as the LAN device so maybe:
https://wiki.mikrotik.com/wiki/Manual:I ... _Proxy_Arp
is a solution here? I want to make VPN configuration at client's side as simplest as possible that is why I still search for an answer...
But where to set it up to be most usable? On bridge interface it will "forward" all L2 traffic via router's interface. Could someone explain, please?

First of all, there is no difference whether the client address fits into the LAN subnet or not, because even if it does, you still have to add a route at the client (if you tell Windows not to add automatically a default route or a class-based route, both of which are usually too wide). The address assigned to the client is a /32 one, so there is no subnet mask associated to it, nor can the client use ARP to determine a MAC address associated to a destination IP as a MAC address is not used at all on L3 tunnels.

Second, if you use IKEv2, you still can use the Win10 embedded VPN client, and you can push a route list to it from the Mikrotik. The VPN client always sends a DHCPINFORM message asking for Option 249 carrying a route list once the tunnel establishes, but Mikrotik currently only responds that request if it comes via an IPsec connection (and generates the route list from the list of prefixes in the split-include parameter of an /ip ipsec mode-config row). Also, certificate-based authentication doesn't require transport of private key from the device which uses it, so in this regard it is superior to any pre-shared-key-based authentication method.

If you still insist on trying the arp-proxy way, third: a "connected subnet" is one which the router can reach directly, with no gateways in between. So all /32 IPs reachable via L3 tunnels are connected subnets (consisting of a single address), and all wider subnets inside which the router has its own IP address attached to some L2 interface (ethernet, bridge, wireless, EoIP tunnel, VPLS ) are also connected subnets. A matching route with distance=0 is dynamically added to router's routing table whenever an interface carrying a connected subnet comes up.

Fourth: setting the arp parameter of the L2 interface, to which an IP address serving as a gateway for devices connected via that interface is attached, to proxy-arp value makes the router respond with the MAC address of that interface to all ARP requests coming to that interface and asking for a MAC address associated to an IP address in any of the other connected subnets (i.e. except the one accessible via the source interface of the request). So if you have active L3 tunnels with assigned remote IPs which fit into a LAN subnet, their associated remote IP addresses constitute exceptions from that subnet, so when an ARP request comes from the LAN, the router responds with its own MAC. Hence the device in LAN sends the frame carrying the packet for the VPN client to the MAC address of the router, and the router handes it just like any other incoming packet and forwards it to the destination using the normal L3 routing. In routing, a longer (more exact) prefix always wins over shorter (wider) ones that also match the destination IP, so the router sends the packet to the L3 tunnel rather than asking for its MAC address using an ARP request sent from the L2 interface carrying the subnet.

But again - this only imitates for the LAN devices that the VPN client's address is in their own subnet although it actually isn't, but it doesn't provide L2 transparency all the way to the client, nor it makes packets with that subnet's broadcast address as destination be delivered to the VPN client. So it neither simplifies the configuration of the client, nor makes Microsoft protocols which depend on broadcast traffic miraculously work across the VPN. So RDP is not an issue (but it is not even if the client's addresses do not fit into the LAN subnet, it may just require some adjustment of Windows firewall on the RDP server if the client's source address is not from server's subnet), whereas SMB may be if it depends on SSDP to work (which is beyond my knowledge).

Panbambaryla · Sun Apr 05, 2020 5:22 pm

Dear Sindy,

Thanky you for your explanation which as a matter of fact were in previous posts in this thread which I read thoroughly. Maybe they will help yet someone else to quickly understand the idea behind using proxy-arp in a future.
I was able to setup MT as I expected with prox-arp mode on bridge interface so now my Windows config is a little bit easier to implement when I don't need to care about routing to LAN network.
BTW - using Windows PowerShell line simplifies the management of specific VPN connection because you don't have to care about it's interface number which can change unexpectedly albeit it's not the "networking way" of doing this.

Who is online