Hello,
I've a problem setting working VPN client on Mikrotik router. I've followed guide for L2TP/IPSec setup of TorGuard VPN service.
After setting proposal and creating L2TP interface I can see that router is connected to TorGuard server ("R" status of interface).
Next, I've created NAT, type "srcnat", out interface "TorGuard" (my new L2TP inteface), action "masquerade".
Then I've setup mangle, chain "prerouting", src address "192.168.0.5" (my testing internal IP), action "mark routing", new routing mark "VPN", passthrough enabled.
Final step was routing setup. My new route is, dst address "0.0.0.0/0", gateway "TorGuard", type "unicast", distance "1", routing mark "VPN".
After this setup I've changed my IP to 192.168.0.5, gateway 192.168.0.1 (router) and DNS 192.168.0.1. I'm able to access router and also ping both sides of VPN tunel. But can't access web. Ping to 8.8.8.8 (Google DNS) or 208.67.222.222 (OpenDNS) fails. Ping directly from Mikrotik fails with error "Can't create socket".
Do you have some idea where could be problem? I tried to completly open firewall (input, output, forward) but no success. Fasttrack firewall rules are disabled.
Thanks
Re: L2TP VPN client routing
Never do this, even for a short while, while the machine is directly connected to internet. The filth from the network can be incredibly fast to squat in. If the device doesn't have a public IP directly on itself but there is some other router with NAT between it and the internet, the risk is lower but not zero.I tried to completly open firewall (input, output, forward)
Apart from the default route with routing-mark=VPN, do you have any other default route? Or does the routing table main (the set of routes with no routing-mark) only contain a route towards the TorGuard server? In either case, what's the outcome if you use ping 8.8.8.8 routing-table=VPN?Ping directly from Mikrotik fails with error "Can't create socket".
Passthrough enabled may or may not be important depending on whether any other rules exist in mangle chain. Although your description is clear regarding the settings related to the task, a complete configuration export is always better because it shows the other settings which may possibly have an impact.Then I've setup mangle, chain "prerouting", src address "192.168.0.5" (my testing internal IP), action "mark routing", new routing mark "VPN", passthrough enabled.
Re: L2TP VPN client routing
Thanks for you replay.
VPN client part:
Yes, also standard default route to my ISP's router exists. Command ping 8.8.8.8 routing-table=VPN works well, all packets received back. Config attached.Apart from the default route with routing-mark=VPN, do you have any other default route? Or does the routing table main (the set of routes with no routing-mark) only contain a route towards the TorGuard server? In either case, what's the outcome if you use ping 8.8.8.8 routing-table=VPN?
VPN client part:
Code: Select all
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc pfs-group=none
/interface l2tp-client
add connect-to=us-ny.torguard.com disabled=no keepalive-timeout=disabled name=\
TorGuard profile=TorGuard use-ipsec=yes user=HIDDEN
/ip firewall nat
add action=masquerade chain=srcnat comment=TorGuard out-interface=TorGuard
/ip firewall mangle
add action=mark-routing chain=prerouting comment=TorGuard new-routing-mark=\
TorGuard passthrough=yes src-address=192.168.0.5
/ip route
add check-gateway=ping distance=1 gateway=TorGuard routing-mark=TorGuard
You do not have the required permissions to view the files attached to this post.
Re: L2TP VPN client routing
I cannot see anything wrong in the configuration. So the next step is to run /tool sniffer quick ip-address=8.8.8.8 while pinging 8.8.8.8 from 192.168.0.105 and to watch how the ICMP echo requests and responses traverse through the router. You should see the request at the physical LAN interface, then on the bridge, and then on the TorGuard interface (already with a new source address); the response should be seen on the same interfaces in the reverse order. Check this and come back with the result.
Re: L2TP VPN client routing
I cannot see anything wrong in the configuration. So the next step is to run /tool sniffer quick ip-address=8.8.8.8 while pinging 8.8.8.8 from 192.168.0.105 and to watch how the ICMP echo requests and responses traverse through the router. You should see the request at the physical LAN interface, then on the bridge, and then on the TorGuard interface (already with a new source address); the response should be seen on the same interfaces in the reverse order. Check this and come back with the result.
It seems that problem is on the way back.
Code: Select all
INTERFACE TIME NUM DI SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
Wifi 3.506 1 <- 40:23:43:41:86:31 74:4D:28:83:63:71 192.168.0.5 8.8.8.8 ip:icmp 74 3 no
bridge 3.506 2 <- 40:23:43:41:86:31 74:4D:28:83:63:71 192.168.0.5 8.8.8.8 ip:icmp 74 3 no
TorGuard 3.506 3 -> 10.1.2.2 8.8.8.8 ip:icmp 60 3 no
TorGuard 3.602 4 <- 8.8.8.8 10.1.2.2 ip:icmp 60 0 no
Re: L2TP VPN client routing
It looks like a bug to me. I know there are issues with GRE handling in firewall, but I've never heard of issues with ICMP handling yet.
If you run /ip firewall connection print detail interval=1s where protocol~"icmp" while pinging, what can you see? Does the connection tracking identify the ping responses as part of the tracked connection, i.e. is the repl-packets value equal to the orig-packets value?
And if you put an action=log protocol=icmp rule as the topmost one to chain forward of /ip firewall filter, can you see the ping responses in the log? If yes, what in-interface and out-interface are shown in the log?
If you run /ip firewall connection print detail interval=1s where protocol~"icmp" while pinging, what can you see? Does the connection tracking identify the ping responses as part of the tracked connection, i.e. is the repl-packets value equal to the orig-packets value?
And if you put an action=log protocol=icmp rule as the topmost one to chain forward of /ip firewall filter, can you see the ping responses in the log? If yes, what in-interface and out-interface are shown in the log?
Re: L2TP VPN client routing
Oh wait... rp-filter=strict is likely the reason, as the backward route for these packets (8.8.8.8 to 10.1.2.2) in the main routing table differs from the marked one. So the strict filtering likely drops the received packets due to this.
Re: L2TP VPN client routing
Yes it is identified. One packet out, one packet back :-)If you run /ip firewall connection print detail interval=1s where protocol~"icmp" while pinging, what can you see? Does the connection tracking identify the ping responses as part of the tracked connection, i.e. is the repl-packets value equal to the orig-packets value?
Code: Select all
1 S C s protocol=icmp src-address=192.168.0.5 dst-address=8.8.8.8 reply-src-address=8.8.8.8 reply-dst-address=10.1.2.2 icmp-type=8 icmp-code=0 icmp-id=1 timeout=7s orig-packets=1
orig-bytes=60 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=1 repl-bytes=60 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps
One log event is generated:And if you put an action=log protocol=icmp rule as the topmost one to chain forward of /ip firewall filter, can you see the ping responses in the log? If yes, what in-interface and out-interface are shown in the log?
Code: Select all
forward: in:bridge out:TorGuard, src-mac 40:23:43:41:86:31, proto ICMP (type 8, code 0), 192.168.0.5->8.8.8.8, len 60
Re: L2TP VPN client routing
No, I've already tried this but tested one more time now without success. Filtering 'loose' or 'no' doesn't change anything.Oh wait... rp-filter=strict is likely the reason, as the backward route for these packets (8.8.8.8 to 10.1.2.2) in the main routing table differs from the marked one. So the strict filtering likely drops the received packets due to this.
Really strange... looks like bug for me too :-(
Re: L2TP VPN client routing
Well, if a packet is seen by connection tracking, but not by the filter, it is still possible that it wasn't routed for some reason. So the next place to put a similar log rule is the top of the prerouting chain of mangle, it should show the un-src-nated version of the packet (after connection tracking translates the reply-dst-address back to src-address). What does that one log?
Re: L2TP VPN client routing
Seems that router knows about NAT on the way back.Well, if a packet is seen by connection tracking, but not by the filter, it is still possible that it wasn't routed for some reason. So the next place to put a similar log rule is the top of the prerouting chain of mangle, it should show the un-src-nated version of the packet (after connection tracking translates the reply-dst-address back to src-address). What does that one log?
This is Mangle log:
Code: Select all
prerouting: in:bridge out:(unknown 0), src-mac 40:23:43:41:86:31, proto ICMP (type 8, code 0), 192.168.0.5->8.8.8.8, len 60
prerouting: in:bridge out:(unknown 0), src-mac 40:23:43:41:86:31, proto ICMP (type 8, code 0), 192.168.0.5->8.8.8.8, len 60
prerouting: in:TorGuard out:(unknown 0), proto ICMP (type 0, code 0), 8.8.8.8->10.1.2.2, NAT 8.8.8.8->(10.1.2.2->192.168.0.5), len 60
prerouting: in:TorGuard out:(unknown 0), proto ICMP (type 0, code 0), 8.8.8.8->10.1.2.2, NAT 8.8.8.8->(10.1.2.2->192.168.0.5), len 60
Code: Select all
srcnat: in:(unknown 0) out:TorGuard, src-mac 40:23:43:41:86:31, proto ICMP (type 8, code 0), 192.168.0.5->8.8.8.8, len 60
Re: L2TP VPN client routing
I suspect the TorGuard may not like you to use a router as their client. Look at this picture, there's the [TTL=TTL-1] box - the purpose of the TTL field is to prevent packets from circulating forever if a routing loop exists in the network, but it can be misused this way.
So run /tool sniffer quick ip-protocol=icmp interface=TorGuard, try the ping to 8.8.8.8 from the 192.168.0.5 for a while, then stop sniffing and run /tool sniffer packet print detail where src-address~"8.8.8.8". I assume you'll see ttl=1 at the end of each line.
As for only one message logged by the NAT rule, that's normal, the NAT table is only consulted for the first packet of each connection, and if it assigns a NAT handling for the connection, the connection tracker stores it for the rest of the connection lifetime.
So run /tool sniffer quick ip-protocol=icmp interface=TorGuard, try the ping to 8.8.8.8 from the 192.168.0.5 for a while, then stop sniffing and run /tool sniffer packet print detail where src-address~"8.8.8.8". I assume you'll see ttl=1 at the end of each line.
As for only one message logged by the NAT rule, that's normal, the NAT table is only consulted for the first packet of each connection, and if it assigns a NAT handling for the connection, the connection tracker stores it for the rest of the connection lifetime.
Re: L2TP VPN client routing
Yes, I know what TTL is and this is good point... but no TTL is high enough :-) And TorGuard also publish official Mikrotik howto: https://torguard.net/article/243/mikrot ... ipsec.htmlI suspect the TorGuard may not like you to use a router as their client. Look at this picture, there's the [TTL=TTL-1] box - the purpose of the TTL field is to prevent packets from circulating forever if a routing loop exists in the network, but it can be misused this way.
So run /tool sniffer quick ip-protocol=icmp interface=TorGuard, try the ping to 8.8.8.8 from the 192.168.0.5 for a while, then stop sniffing and run /tool sniffer packet print detail where src-address~"8.8.8.8". I assume you'll see ttl=1 at the end of each line.
As for only one message logged by the NAT rule, that's normal, the NAT table is only consulted for the first packet of each connection, and if it assigns a NAT handling for the connection, the connection tracker stores it for the rest of the connection lifetime.
You do not have the required permissions to view the files attached to this post.
Re: L2TP VPN client routing
OK. Copy the log rule from chain=prerouting to both chain=forward and chain=input of mangle, to see whether the packet gets routed at all and if it does, where. If it gets to neither chain, the routing has failed; if you can see it in mangle/forward but not in filter/forward, it's some firewall issue. Are there any dynamically created rules in chain=forward of /ip firewall filter before the logging one?
Re: L2TP VPN client routing
This is log output: Log rules are first everywhere. I've also log rule in firewall input. No dynamic rules in /ip firewall filter nor NAT and mangle.OK. Copy the log rule from chain=prerouting to both chain=forward and chain=input of mangle, to see whether the packet gets routed at all and if it does, where. If it gets to neither chain, the routing has failed; if you can see it in mangle/forward but not in filter/forward, it's some firewall issue. Are there any dynamically created rules in chain=forward of /ip firewall filter before the logging one?
You do not have the required permissions to view the files attached to this post.
Re: L2TP VPN client routing
I also use TorGuard vpn services for some devices in my house and for me works ok,
here's my config regarding Torguard VPN, hope it helps
here's my config regarding Torguard VPN, hope it helps
Code: Select all
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc pfs-group=none
/ppp profile
add change-tcp-mss=yes name=profileTorguard on-down=":do {\r\
\n/ip firewall address-list remove [find where list=VPN-ADDR]\r\
\n}" on-up=":do {\r\
\n/ip firewall address-list add list=VPN-ADDR address=\$\"local-address\"\
\r\
\n}"
/interface l2tp-client
add comment=VPN connect-to=xx.xx.xx.xx disabled=no ipsec-secret=secret \
name=TorGuard password=pass profile=profileTorguard use-ipsec=yes \
user=user@user.com
/ip firewall address-list
add address=192.168.0.41 comment=Roku list=TorGuargList
/ip firewall filter
add action=accept chain=forward comment="Fasttrack Disable VPNList" \
src-address-list=TorGuargList
add action=accept chain=forward connection-state=established,related \
dst-address-list=TorGuargList
/ip firewall mangle
add action=accept chain=prerouting comment="TorGuard Metodo 2" \
dst-address-list=VPN-ADDR in-interface=bridgeLAN
add action=mark-connection chain=prerouting connection-mark=no-mark \
in-interface=TorGuard new-connection-mark=VPN_Conn passthrough=yes
add action=mark-connection chain=prerouting connection-mark=no-mark \
dst-address-type=!local in-interface=bridgeLAN new-connection-mark=\
VPN_Conn passthrough=yes src-address-list=TorGuargList
add action=mark-routing chain=prerouting connection-mark=VPN_Conn \
in-interface=bridgeLAN new-routing-mark=VPN passthrough=yes \
src-address-list=TorGuargList
add action=mark-routing chain=output connection-mark=VPN_Conn \
new-routing-mark=VPN passthrough=yes src-address-list=TorGuargList
/ip firewall nat
add action=masquerade chain=srcnat comment="TorGuard VPN" out-interface=\
TorGuard
/ip route
add distance=1 gateway=TorGuard routing-mark=VPN target-scope=30
Re: L2TP VPN client routing [SOLVED]
Hi, thanks for configuration. Seems little bit confusing for me and doesn't work. But finally I found working setup by only little modification of basic TorGuard howto:I also use TorGuard vpn services for some devices in my house and for me works ok,
here's my config regarding Torguard VPN, hope it helps
Code: Select all/ip ipsec proposal set [ find default=yes ] enc-algorithms=aes-128-cbc pfs-group=none /ppp profile add change-tcp-mss=yes name=profileTorguard on-down=":do {\r\ \n/ip firewall address-list remove [find where list=VPN-ADDR]\r\ \n}" on-up=":do {\r\ \n/ip firewall address-list add list=VPN-ADDR address=\$\"local-address\"\ \r\ \n}" /interface l2tp-client add comment=VPN connect-to=xx.xx.xx.xx disabled=no ipsec-secret=secret \ name=TorGuard password=pass profile=profileTorguard use-ipsec=yes \ user=user@user.com /ip firewall address-list add address=192.168.0.41 comment=Roku list=TorGuargList /ip firewall filter add action=accept chain=forward comment="Fasttrack Disable VPNList" \ src-address-list=TorGuargList add action=accept chain=forward connection-state=established,related \ dst-address-list=TorGuargList /ip firewall mangle add action=accept chain=prerouting comment="TorGuard Metodo 2" \ dst-address-list=VPN-ADDR in-interface=bridgeLAN add action=mark-connection chain=prerouting connection-mark=no-mark \ in-interface=TorGuard new-connection-mark=VPN_Conn passthrough=yes add action=mark-connection chain=prerouting connection-mark=no-mark \ dst-address-type=!local in-interface=bridgeLAN new-connection-mark=\ VPN_Conn passthrough=yes src-address-list=TorGuargList add action=mark-routing chain=prerouting connection-mark=VPN_Conn \ in-interface=bridgeLAN new-routing-mark=VPN passthrough=yes \ src-address-list=TorGuargList add action=mark-routing chain=output connection-mark=VPN_Conn \ new-routing-mark=VPN passthrough=yes src-address-list=TorGuargList /ip firewall nat add action=masquerade chain=srcnat comment="TorGuard VPN" out-interface=\ TorGuard /ip route add distance=1 gateway=TorGuard routing-mark=VPN target-scope=30
Code: Select all
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128-cbc pfs-group=none
/ppp profile
add change-tcp-mss=yes name=TorGuard use-compression=no use-encryption=no use-mpls=no use-upnp=no
/interface l2tp-client
add connect-to=dn.secureconnect.me disabled=no keepalive-timeout=disabled name=TorGuard profile=TorGuard use-ipsec=yes user=HIDDEN_USER_NAME
/ip firewall address-list
add address=192.168.0.5 list=TorGuardList
/ip firewall filter
add action=accept chain=forward src-address-list=TorGuardList
/ip firewall mangle
add action=mark-routing chain=prerouting in-interface=bridge new-routing-mark=TorGuardMark passthrough=yes src-address-list=TorGuardList
add action=accept chain=forward dst-address-list=TorGuardList in-interface=TorGuard
/ip firewall nat
add action=masquerade chain=srcnat comment=TorGuard out-interface=TorGuard
/ip route
add check-gateway=ping distance=1 gateway=TorGuard routing-mark=TorGuardMark
Code: Select all
/ip firewall mangle
add action=accept chain=forward dst-address-list=TorGuardList in-interface=TorGuard
Thank you both for answers and you help with the solution!
Re: L2TP VPN client routing
It's weird. If the action=log rule placed to the very beginning of the forward chain of /ip firewall filter did not see the packets, how can an action=accept rule in the same chain see them? So something must have happened internally as you were adding that rule.
Also, if that accept rule only has the match conditions you've shown, eventual incoming connections via the tunnel are not dropped. It's up to you to consider how big a security risk it is for you.
Also, if that accept rule only has the match conditions you've shown, eventual incoming connections via the tunnel are not dropped. It's up to you to consider how big a security risk it is for you.