Hi,
The router is an SXT-LTE running 6.49.1. Internet connection is LTE and it is given a real IPv4 address, not CGNAT. I'm trying to setup a remote access VPN so that I can login remotely. I'm using L2TP and have configured it using IPsec and pre-shared key, with the router's LAN address as "local address" and an address pool from the same subnet for "remote address". I also added firewall rules to permit the VPN to establish.
With all this configured my remote client can connect, and when connected it can ping the LAN interface of the router but nothing else. Looking at the logs it seems that the established connection is being automatically detected as "WAN", which I assume means it's going to blocked by the normal firewall rules.
What's the best way around this, a firewall rule explicitly permitting the VPN client traffic, or disabling that autodetection so that the firewall can be left unchanged?
Re: L2TP Remote client detected as WAN
Add L2TP to LAN list in interfaces.
But if I recall correctly it's a dynamic interface ? So name might change.
If your setup allows it: change default drop rule from !LAN to WAN (which nowadays seems to be best practice)
Everything which is explicitly labeled as WAN will be dropped, the rest not.
And your VPN tunnel will then pass since it's not labeled as WAN.
How I have it:
add action=drop chain=input comment="Drop all input coming from WAN if it got here" in-interface-list=WAN
Last line of the input chain.
But if I recall correctly it's a dynamic interface ? So name might change.
If your setup allows it: change default drop rule from !LAN to WAN (which nowadays seems to be best practice)
Everything which is explicitly labeled as WAN will be dropped, the rest not.
And your VPN tunnel will then pass since it's not labeled as WAN.
How I have it:
add action=drop chain=input comment="Drop all input coming from WAN if it got here" in-interface-list=WAN
Last line of the input chain.
Re: L2TP Remote client detected as WAN
Thanks. The L2TP connection doesn't appear as an interface, except when the client is connected, so I can't manually add it to the LAN interface list.
The proper fix, in my opinion would be to find a way to stop that L2TP being detected as WAN so that all the normal rules can be left in place, however I'm having a hard time finding how this detect actually works.
But that is the problem, the L2TP connection IS labelled as WAN. So it gets dropped whether that rule specifies "WAN" or "!LAN".If your setup allows it: change default drop rule from !LAN to WAN (which nowadays seems to be best practice)
Everything which is explicitly labeled as WAN will be dropped, the rest not.
And your VPN tunnel will then pass since it's not labeled as WAN.
The proper fix, in my opinion would be to find a way to stop that L2TP being detected as WAN so that all the normal rules can be left in place, however I'm having a hard time finding how this detect actually works.
Re: L2TP Remote client detected as WAN
Turn off /detect internet, which sometimes causes odd behaviour, and add the interfaces manually to any desired interface lists
Re: L2TP Remote client detected as WAN
I've just been following up the firewall option, I am not totally sold on it but I think I can get the desired results with a firewall rule permitting by source address. With this in place, these are my filter rules and I would welcome any comments. For clarity I have separated off the four rules that I've added, three to allow the connection to establish and the fourth to permit routing of client traffic. Everything else is Mikrotik default.
I am slightly uncomfortable that my fourth rule can't distinguish between traffic from a client connection, or traffic from the actual Internet interface. Does that leave it open to some form of spoofing, and if so then would it be good practice to put a specific drop rule just before it for traffic from the Internet interface? Something like ...
I need to follow up on the automatic detection as well. That will stop the VPN being automatically added to WAN, and although I can't actually put it into any interface list it still gives some more options for classifying by interface group. For example the forward rule could specify "!WAN" as well as the subnet.
I remember there were some side effects when I disabled detect-internet, but I can't remember what they were. There was definitely some reason why I ended up re-enabling it.
Code: Select all
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" packet-size=0-200 protocol=icmp
add action=accept chain=input comment="*** VPN Establishment - UDP ports ***" dst-port=500,1701,4500 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="*** VPN Establishment - IPsec esp ***" in-interface-list=WAN protocol=ipsec-esp
add action=accept chain=input comment="*** VPN Establishment - IPsec ah ***" in-interface-list=WAN protocol=ipsec-ah
add action=accept chain=forward comment="*** VPN Routing - Allow traffic from remote clients ***" src-address=xxx.xxx.xxx.0/24
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related disabled=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add chain=forward
I am slightly uncomfortable that my fourth rule can't distinguish between traffic from a client connection, or traffic from the actual Internet interface. Does that leave it open to some form of spoofing, and if so then would it be good practice to put a specific drop rule just before it for traffic from the Internet interface? Something like ...
Code: Select all
add action=drop chain=forward comment="*** Anti Spoofing ***" in-interface=lte1 src-address=xxx.xxx.xxx.0/24
add action=accept chain=forward comment="*** VPN Routing - Allow traffic from remote clients ***" src-address=xxx.xxx.xxx.0/24
I remember there were some side effects when I disabled detect-internet, but I can't remember what they were. There was definitely some reason why I ended up re-enabling it.
Re: L2TP Remote client detected as WAN
The topic title is misleading, more likely it is a case of the remote client being treated as WAN (or not LAN) rather than being detected as such.
As @holvoetn says the newer default rules use not LAN as a selector rather than WAN which will block access from any additional networks. If your internal & VPN networks are trusted you can simply change this:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
becomes
add action=drop chain=input comment="drop all coming from WAN" in-interface-list=WAN
Alternatively add the VPN interface to the LAN interface-list. As the interface is created dynamically you can either use a server binding to create a static interface name (the historic way), or specify the interface list in the PPP profile for the VPN - this will dynamically add and remove the VPN interfaces from the specified interface-list.
As @holvoetn says the newer default rules use not LAN as a selector rather than WAN which will block access from any additional networks. If your internal & VPN networks are trusted you can simply change this:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
becomes
add action=drop chain=input comment="drop all coming from WAN" in-interface-list=WAN
Alternatively add the VPN interface to the LAN interface-list. As the interface is created dynamically you can either use a server binding to create a static interface name (the historic way), or specify the interface list in the PPP profile for the VPN - this will dynamically add and remove the VPN interfaces from the specified interface-list.
Re: L2TP Remote client detected as WAN
Thanks, there's a lot of helpful information there. However to start off ..
So once the connection has been so detected, and added to the WAN list it will be affected in exactly the same way by a rule that matches either "WAN" or "!LAN".
My goal here is to allow the remote client to access the network, so my understanding is that it has to be permitted (or not dropped) in the "forward" chain as well as "input".
Finally I am not clear on the server binding option, but I will look that up and give it a go as well.
I was saying "detected", because that is what the router logs, these are the final log entries as a client connects ...The topic title is misleading, more likely it is a case of the remote client being treated as WAN (or not LAN) rather than being detected as such.
Code: Select all
12:37:28 l2tp,ppp,info <l2tp-L2TP-REMOTE>: authenticated
12:37:28 l2tp,ppp,info <l2tp-L2TP-REMOTE>: connected
12:37:34 interface,info <l2tp-L2TP-REMOTE> detect WAN This might be the answer, but it's not working quite the way I expected. If I specify Interface List LAN in the PPP profile, this doesn't stop the connection being detected as WAN, so the connection is in both lists. Presumably that means it will still match any rule specifying "WAN", but maybe it won't match "!LAN". I'm not sure on that, so will have to test.Alternatively add the VPN interface to the LAN interface-list. As the interface is created dynamically you can either use a server binding to create a static interface name (the historic way), or specify the interface list in the PPP profile for the VPN - this will dynamically add and remove the VPN interfaces from the specified interface-list.
Code: Select all
> interface list member print
Flags: X - disabled, D - dynamic
# LIST INTERFACE
0 ;;; defconf
LAN bridge
1 ;;; defconf
WAN lte1
2 LAN *6
3 D ;;; LAN detected
LAN ether1
4 D LAN <l2tp-L2TP-REMOTE>
5 D ;;; WAN detected
WAN <l2tp-L2TP-REMOTE> Finally I am not clear on the server binding option, but I will look that up and give it a go as well.
Re: L2TP Remote client detected as WAN
OK, that is detect-internet getting it wrong, disable it:I was saying "detected", because that is what the router logs, these are the final log entries as a client connects ...
/interface detect-internet
set detect-interface-list=none internet-interface-list=none lan-interface-list=none wan-interface-list=none
and ensure there are appropriate static WAN and LAN interface-list entries - it appears that lte1 is in the WAN list and bridge is in the LAN list which should be sufficient.
Access to services on the Mikrotik itself is handled by input, and access to other devices on the local LAN, or internet via WAN, is handled by forward. As you have spotted it you restrict access by source address there is a possibility it may be spoofed via any interface, likewise if you restrict by source (ingress) interface only devices connected via said interface have access but are able to spoof any source address.My goal here is to allow the remote client to access the network, so my understanding is that it has to be permitted (or not dropped) in the "forward" chain as well as "input".
If the VPN interface is erroneously being added to the WAN list it likely wouldn't help, so fix that first.Finally I am not clear on the server binding option, but I will look that up and give it a go as well.
Re: L2TP Remote client detected as WAN
Thanks, yes interface lte1 is the only direct Internet interface on this router. I wish I could remember what went wrong when I disabled detect internet in the past, I guess I should just do so again and see what happens.
Meanwhile adding interface list LAN to the ppp profile seems to have helped. Traffic from the connected client is still blocked by rules matching "WAN", but is not blocked by rules matching "!LAN". I will need to test tomorrow but it looks as if this removes the need for specific permissions based solely on source address, and therefore removes the need for an anti spoofing rule. Or maybe I can keep the anti-spoofing and use "!LAN" match instead of the explicit interface. I might review that once I've tested with detect internet disabled.
Meanwhile adding interface list LAN to the ppp profile seems to have helped. Traffic from the connected client is still blocked by rules matching "WAN", but is not blocked by rules matching "!LAN". I will need to test tomorrow but it looks as if this removes the need for specific permissions based solely on source address, and therefore removes the need for an anti spoofing rule. Or maybe I can keep the anti-spoofing and use "!LAN" match instead of the explicit interface. I might review that once I've tested with detect internet disabled.
Re: L2TP Remote client detected as WAN
I had a chance for another fiddle around today. For some reason that previous configuration no longer worked, the PPP connection was back to being added to the WAN list and didn't stay in LAN as it should have done. So what I've done is restrict detect-internet so it can only detect on lte1 which is the only possible Internet path. First by creating an interface list LTE for lte1, then reconfiguring detect-internet.
With that configuration in place my L2TP remote client remains as "LAN", while detect-internet still works for the benefit of the mobile app.
Code: Select all
/interface detect-internet
set detect-interface-list=LTE internet-interface-list=LTE lan-interface-list=LAN wan-interface-list=LTEWith that configuration in place my L2TP remote client remains as "LAN", while detect-internet still works for the benefit of the mobile app.
Code: Select all
> interface list member print terse
0 comment=defconf list=LAN interface=bridge dynamic=no
1 comment=defconf list=WAN interface=lte1 dynamic=no
2 list=LTE interface=lte1 dynamic=no
3 D list=LAN interface=<l2tp-L2TP-REMOTE> dynamic=yes
> interface detect-internet state print terse
0 name=lte1 state=wan state-change-time=dec/14/2021 13:28:28