Stuck with L2TP VPN routing

thegoop · Mon Jul 29, 2019 4:31 pm

Trying to setup my router to route traffic from a certain computer to an L2TP VPN tunnel. I have verified the server end of the is working by establishing a connection directly from my computer, but would rather have it down on the router (as more than one client will eventually use the tunnel).

It seems (I could be wrong) that the tunnel is running on the Mikrotik, but when the computer sends packets over the tunnel (I see the Tx on the interface have activity) there is nothing that comes back (the Rx is always 0).

This is my simple configuration:

/interface l2tp-client
add connect-to=gupsters.ddns.net disabled=no ipsec-secret=XXX name=\
    sfo_vpn password=XXX use-ipsec=yes user=XXX
/ip firewall mangle
add action=mark-routing chain=prerouting disabled=yes dst-address-list=!local \
    new-routing-mark=to_sfo_vpn passthrough=yes src-address=10.10.3.155
/ip route
add check-gateway=ping distance=1 gateway=sfo_vpn routing-mark=to_sfo_vpn

Output for my NAT:

Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none 
# ignore other specialized NAT forwards

Here are my filter rules (I am not an expert here, and was playing around with a few items (now disabled) to see if I could get them to work):

Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1 X  ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

 2 X  ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

 3    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related 

 4    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

 5    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

 6    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN 

 7    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 8    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 9    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

10    ;;; For L2TP/IPSec
      chain=input action=accept protocol=udp port=1701,500,4500 

11 X  ;;; For L2TP/IPSec
      chain=input action=accept protocol=ipsec-esp 

12    chain=input action=accept in-interface=all-ppp log=no log-prefix="" 

13    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN

I did notice that the interface sfo_vpn has the following. Does this look normal - especially the remote address?

Local Address		192.168.10.2
Remote Address     10.255.255.0

Any help you can provide is appreciated!

sindy · Mon Jul 29, 2019 5:54 pm

First, for point-to-point tunnels it is nothing unusual that the IP addresses on the two ends of the tunnel are not "similar". The remote address is only used by routing to determine the right interface to use as output one if set as routes' gateway, but you can as well set the interface name as gateway directly if you don't need recursive next-hop search.

Second, from your description it's not clear whether you use a "real" VPN to connect to a remote private network or the (more popular these days) "anonymisation VPN" to connect to servers from other than your usual IP address. In either case it is necessary that the responses from the remote end would "know" that they have to get to the tunnel; for a "real" VPN, it is usually a matter of routing at the other end of the tunnel, whereas for the "anonymisation" VPN, you have to masquerade also what you send to the tunnel so that the IP address of the tunnel would be seen at the remote end instead of the actual address of the host which has sent the request.

thegoop · Mon Jul 29, 2019 6:09 pm

Thanks - this is a VPN into my brother's house, not an anonymization VPN. But, I think I figured out my issue! I wasn't masquerading the outgoing packets on the vpn. Adding a new NAT rule seemed to fix it:

Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
 1    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface=sfo_vpn ipsec-policy=out,none

While it does seem to work, can you please confirm that the fix is the right one?

First, for point-to-point tunnels it is nothing unusual that the IP addresses on the two ends of the tunnel are not "similar". The remote address is only used by routing to determine the right interface to use as output one if set as routes' gateway, but you can as well set the interface name as gateway directly if you don't need recursive next-hop search.

Second, from your description it's not clear whether you use a "real" VPN to connect to a remote private network or the (more popular these days) "anonymisation VPN" to connect to servers from other than your usual IP address. In either case it is necessary that the responses from the remote end would "know" that they have to get to the tunnel; for a "real" VPN, it is usually a matter of routing at the other end of the tunnel, whereas for the "anonymisation" VPN, you have to masquerade also what you send to the tunnel so that the IP address of the tunnel would be seen at the remote end instead of the actual address of the host which has sent the request.

sindy · Mon Jul 29, 2019 6:16 pm

While it does seem to work, can you please confirm that the fix is the right one?

If you don't need that the hosts in your brother's LAN know the actual addresses of hosts in your LAN which connect to them, and if you don't need hosts in your brother's LAN to connect to hosts in your LAN, it is the right "fix". Otherwise, you need to add routing at your brother's side towards your LAN subnet(s) via the tunnel, and if you do that, you don't need the masquerade.

thegoop · Mon Jul 29, 2019 6:45 pm

That makes perfect sense, and this is a one-way connection (so from me into his network but not vice-versa). I appreciate you confirming!

Stuck with L2TP VPN routing

Stuck with L2TP VPN routing

Re: Stuck with L2TP VPN routing

Re: Stuck with L2TP VPN routing

Re: Stuck with L2TP VPN routing

Re: Stuck with L2TP VPN routing

Who is online