Smartbox turbo+ vpn tunnel OW 22.03.0

psherman · December 2, 2022, 2:05am

I've only skimmed this thread, so apologies if I've missed anything... but a critical question:

Is this router connected directly to the internet?

--> If so, you have opened a massive security hole by allowing input=accept on the wan zone. This should always be reject or drop when the WAN is connected to an untrusted network (i.e. the internet).

Additionally, is the vpn fully trusted (i.e. users/devices on the other side of the tunnel are trusted and should be allowed unrestricted access to the router itself as well as the LAN behind it? Currently, your firewall configuration is such that the remote hosts are assumed to be trusted. If this is not the desired situation, you need to change the vpn zone allowances.

ShadowRunner · December 2, 2022, 6:50pm

thanks, Im aware of it, the router is behind ISPs NAT, and the vpn is fully trusted, it is mine point is that the routers lan should be accessible to all the clients on the vpn but I havent found the solution

psherman · December 2, 2022, 6:55pm

The ISP, despite being behind NAT, should be considered untrusted. Both the ISP itself and potentially other users on your subnet from the ISP could potentially gain access to your router, and that would be bad (to be clear, it could be malicious actions by the company/users directly, or worms/viruses that have infected the ISP or user devices).

Move your VPN to a new zone. Allow that one full access if desired (input = accept, output = accept, forward is not likely relevant). This will ensure that your VPN has access, but your WAN connection does not.

ShadowRunner · December 2, 2022, 7:06pm

sure

I'll do that for sure as soon as i find the solution, thats funny, but keeping everything accepted I still have no access to the lan now thats the main quiestion for me

psherman · December 2, 2022, 7:09pm

My recommendation: do it now. You actually have more flexibility with the VPN in its own firewall zone.

ShadowRunner · December 2, 2022, 7:38pm

you mean like this?
frankly saying, I was keeping everything accepted just to not loose remote access to the router by a mistake because its not near to me
nevertheless its lan is still unaviable to me

ShadowRunner · December 2, 2022, 7:43pm

do you mean this by mooving the vpn to a new zone?

ShadowRunner · December 2, 2022, 8:17pm

mooved the vpn to the new zone vpn in interfaces like in the picture above, the lan is still unaccessible

psherman · December 3, 2022, 12:06am

let's see the latest complete configs:

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

ShadowRunner · December 4, 2022, 10:39am

root@SBT:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option delegate '0'
        option device 'br0'
        option ipaddr '10.0.2.1'

config interface 'wan'
        option proto 'dhcp'
        option metric '5'
        option delegate '0'
        option device 'wan'

config globals 'globals'
        option packet_steering '1'

config device
        option name 'eth0'
        option ipv6 '0'

config device
        option name 'wwan0'
        option ipv6 '0'
        option multicast '0'

config device
        option name 'lan1'
        option ipv6 '0'

config device
        option name 'lan2'
        option ipv6 '0'

config device
        option name 'lan3'
        option ipv6 '0'

config device
        option name 'lan4'
        option ipv6 '0'

config device
        option name 'wan'
        option ipv6 '0'

config device
        option name 'br0'
        option type 'bridge'
        option ipv6 '0'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config device
        option name 'wlan0'
        option ipv6 '0'

config device
        option name 'wlan1'
        option ipv6 '0'

config interface 'white_ip'
        option proto 'l2tp'
        option server '1.2.3.4'
        option username 'name'
        option password 'pass'
        option defaultroute '0'
        option peerdns '0'
        option ipv6 '0'
        option delegate '0'
        option force_link '1'
        option mtu '1400'
        option checkup_interval '10'
        option keepalive '20 5'

config route
        option interface 'white_ip'
        option target '10.0.0.0/16'
        option gateway '10.0.2.2'

root@SBT:~# cat /etc/config/firewall

config defaults
        option output 'ACCEPT'
        option synflood_protect '1'
        option input 'DROP'
        option forward 'DROP'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option output 'ACCEPT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'
        option input 'DROP'
        option forward 'DROP'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

config include
        option fw4_compatible '1'
        option path '/etc/firewall.user'

config zone
        option name 'vpn'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option mtu_fix '1'
        list network 'white_ip'
        option masq '1'

config forwarding
        option src 'vpn'
        option dest 'lan'

config forwarding
        option src 'lan'
        option dest 'vpn'

when it was in the green lan zone there was no access either

psherman · December 4, 2022, 5:04pm

I'll start with a caveat: it has been a very long time since I used any L2 VPN technologies, so it is possible (maybe likely) that I have forgotten the nuances of how to manage L2 tunnels. That said...

So I think the fundamental issue is that you are attempting to route between a VPN and a network interface that have the same IP addresses on the interfaces themselves, and both occupy the same subnet.

You cannot route between networks that are of the same or overlapping subnets (ever, this is a rule of L3/routing in all networks).

It also appears that part of your issue could be the overly broad route you have defined... it overlaps your LAN and that will cause a conflict. Instead, you should configure routes that are targeted... for example, remove the following:

and replace it with:

config route
        option interface 'white_ip'
        option target '10.0.0.0/24'
        option gateway '10.0.2.2'

config route
        option interface 'white_ip'
        option target '10.0.50.0/24'
        option gateway '10.0.2.2'

config route
        option interface 'white_ip'
        option target '10.0.1.0/24'
        option gateway '10.0.2.2'

You should probably define a different LAN address (let's say 10.0.3.1/24) so that your VPN doesn't overlap. Then, you may need corresponding routes back to your OpenWrt router on the other endpoints, or at least on the server.

Or... if you can add the VPN tunnel itself (possibly tap0 or something -- don't know what is happening on your connection) into the lan bridge, that would fulfill the L2 TAP type connection and then you wouldn't need any routing on the OpenWrt side (since it would already be a part of the same subnet).

At the very least, the VPN tunnel address and the LAN address should not be the same.

Beyond that, you currently have masquerading enabled on the vpn firewall zone -- that also will prevent the lan access you are trying to achieve.

So a few questions:

It appears you have full control over the server and endpoints, is that correct?
Do you have a specific reason for needing an L2 VPN solution (vs L3/routed)?
Do you have the option to use a VPN solution that is better suited to this task such as WireGuard or OpenVPN?

ShadowRunner · December 4, 2022, 6:53pm

sir your a warlock in a nice way!!!!!!! its working! ive just moved the vpn from its own zone to the lan in interfaced and changed the ip given by the server to 10.0.80.1 and the route to 10.0.0.0/16 10.0.80.2, this works well! I dont know why RouterOS works with the same subnets perfectly, so I couldnt even think openwrt wouldnt work

Ive no clue about that just did like Maurer said, ive switched it off

Yes I do
The reason is l2tp is clear to me and it works well on RouterOS

I do. I tried to use Openvpn but it seemed too sophisticated to me, though my openwrt has an inbuilt openvpn client, also Ive heard of wireguard its undimanding to resources and RouterOS got it, maybe i'll try it some time
anyway, the solution is found so I can use l2tp for a while, thank you very much! sir Maurer you helped alot thanks to you too!

system · December 14, 2022, 6:53pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.