Remotely connect to LAN via WireGuard on Mango

blancmange · 2021-04-03T06:06:30.766Z

@ueue I’m still on 3.105 and I think I’m able to do this, see how my firewall settings are different to yours, maybe try mine?

Screenshot 2021-04-03 0805491758×610 63.1 KB

ueue · 2021-04-03T21:33:33.949Z

@blancmange Thanks for the reply! The only difference I’m seeing is that for the wan zone you accept forwarding. Isn’t this circumventing the NAT? Feel free to correct me if I’ve misunderstood.

ueue · 2021-04-03T22:02:01.969Z

@blancmange In any case I rolled back to version 3.105 and tried your change. It didn’t work, so this is not the magic incantation (assuming I didn’t miss another difference). Following the KISS principle, I’m going to set up second mango (GL-MT300N-V2) that’s not behind our Palo Alto firewall and test.

ueue · 2021-04-03T22:05:03.043Z

@Riho-shuu Here’s hoping you can see what I’m missing.

Riho-shuu · 2021-04-06T01:49:32.566Z

My apology for the late response.

Your forwarding rule is correct, could we arrange a remote support?

agent_smith · 2021-04-06T21:14:45.489Z

ueue:

I have a new GL.iNET GL-MT300N-V2 and have setup WireGuard. I can access the router’s admin page on 192.168.8.1, but I can’t see anything else on 192.168.8.0/24. What am I missing?

I have the same problem on my GL devices. (AR300M/Slate) . So I am also interested in solution

ueue · 2021-04-09T12:49:56.363Z

@Riho-shuu I know that systems on the lan/wifi can connect via RDP, so here is a tcpdump of an attempt to use RDP across the wireguard connection. Here is the dump on wg0

image2502×326 73.7 KB

and from br-lan

image2494×206 43.9 KB

As you saw with ICMP, there is no return seen on either interface. Interestingly, there is more traffic seen on wg0.

Riho-shuu · 2021-04-16T02:25:31.029Z

So, ueue’s problem has been solved, his windows system has a second firewall client which caused the problem. May I learn about your problem?

ueue · 2021-04-16T13:21:58.142Z

@Riho-shuu @alzhao Thanks for the help!

T3Knical5urg3 · 2022-02-09T05:14:24.048Z

Sorry to revive an old thread but I am having a similar issue without a similar resolution.

I think I am having a similar problem and I don’t think it is a client side firewall since the “client” in this case would be the router itself (I am trying to access the usb storage I have attached to the client gli.net router). Any suggesting on other settings beyond what is discussed here that may be the issue.

> config defaults
>         option input 'ACCEPT'
>         option output 'ACCEPT'
>         option forward 'REJECT'
>         option synflood_protect '1'
> 
> config zone
>         option name 'lan'
>         list network 'lan'
>         option input 'ACCEPT'
>         option output 'ACCEPT'
>         option forward 'ACCEPT'
> 
> config zone
>         option name 'wan'
>         option output 'ACCEPT'
>         option masq '1'
>         option mtu_fix '1'
>         option network 'wan wan6 tethering'
>         option input 'REJECT'
>         option forward 'REJECT'
> 
> config forwarding
>         option src 'lan'
>         option dest 'wan'
>         option enabled '1'
> 
> 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 include
>         option path '/etc/firewall.user'
>         option reload '1'
> 
> config include 'glfw'
>         option type 'script'
>         option path '/usr/bin/glfw.sh'
>         option reload '1'
> 
> config zone 'guestzone'
>         option name 'guestzone'
>         option network 'guest'
>         option forward 'REJECT'
>         option output 'ACCEPT'
>         option input 'REJECT'
> 
> config forwarding 'guestzone_fwd'
>         option src 'guestzone'
>         option dest 'wan'
>         option enabled '1'
> 
> config rule 'guestzone_dhcp'
>         option name 'guestzone_DHCP'
>         option src 'guestzone'
>         option target 'ACCEPT'
>         option proto 'udp'
>         option dest_port '67-68'
> 
> config rule 'guestzone_dns'
>         option name 'guestzone_DNS'
>         option src 'guestzone'
>         option target 'ACCEPT'
>         option proto 'tcp udp'
>         option dest_port '53'
> 
> config rule 'sambasharewan'
>         option src 'wan'
>         option dest_port '137 138 139 445'
>         option dest_proto 'tcpudp'
>         option target 'DROP'
> 
> config rule 'sambasharelan'
>         option src 'lan'
>         option dest_port '137 138 139 445'
>         option dest_proto 'tcpudp'
>         option target 'ACCEPT'
> 
> config include 'gls2s'
>         option type 'script'
>         option path '/var/etc/gls2s.include'
>         option reload '1'
> 
> config include 'glqos'
>         option type 'script'
>         option path '/usr/sbin/glqos.sh'
>         option reload '1'
> 
> config rule
>         option src 'wireguard'
>         option name 'Wireguard passthough'
>         option target 'ACCEPT'
>         option enabled '0'
> 
> config rule 'AllowWireguard'
>         option name 'Allow-Wireguard'
>         option target 'ACCEPT'
>         option src 'wan'
>         option proto 'udp tcp'
>         option family 'ipv4'
>         option dest_port '1771'
> 
> config zone 'wireguard'
>         option name 'wireguard'
>         option input 'ACCEPT'
>         option forward 'DROP'
>         option output 'ACCEPT'
>         option masq '1'
>         option mtu_fix '1'
>         option device 'wg0'
>         option masq6 '1'
> 
> config forwarding 'wireguard_wan'
>         option src 'wireguard'
>         option dest 'wan'
> 
> config forwarding 'wireguard_lan'
>         option src 'wireguard'
>         option dest 'lan'
> 
> config forwarding 'lan_wireguard'
>         option src 'lan'
>         option dest 'wireguard'
> 
> config forwarding 'guest_wireguard'
>         option src 'guestzone'
>         option dest 'wireguard'
> 
> config forwarding 'wireguard_guest'
>         option src 'wireguard'
>         option dest 'guestzone'

alzhao · 2022-02-09T07:19:09.553Z

T3Knical5urg3:

am trying to access the usb storage

How are you aceessing the usb storage? FTP? http? Samba?

T3Knical5urg3 · 2022-02-09T15:04:34.377Z

I am trying though a samba share, but I haven’t been successful in an ICMP ping either.

I should also clarify that I have no issue connecting to anything on the Wireguard server side from the client side.

wcs2228 · 2022-02-09T23:37:59.162Z

Can you check if you are able to log int the router’s Admin portal (GL.Inet UI and/or LuCI UI) and if you are able to SSH into the router?

Also, are connecting a PC/client device remotely to Wireguard server running on your GL-AR750S?

T3Knical5urg3 · 2022-02-10T04:56:20.108Z

When I am in the GLI.net router network yes I can access the admin portal (and luci) and can ssh. It is only when I am on the server side of the wireguard network that I can’t access into the GLI.net network.

T3Knical5urg3 · 2022-02-10T16:18:42.252Z

I spent some more time trying to solve this so I thought I would record that here:

I found my intended setup is referred to as site-to-site.

I ensured that my wireguard approved IPs encompass the range of possible IPs. (0.0.0.0/24)
I had NPV policies on on the GLI.net client router so I disabled that just in case there was some strange routing going on because of it.
Ensured that server side has the option “create routes for allowed IPs for the peer”.
Ensured there is a route in the server side routing table (see: the thrread)

I still have had no luck.

T3Knical5urg3 · 2022-02-10T17:22:31.929Z

Well, I got it to work for a hot second. I could ping across subnets in both directions. I rebooted the GLI and I am back to one way. No idea what changed with reboot to stop working again.

wcs2228 · 2022-02-10T22:22:19.114Z

Are the client and server sides on different subnets? You can try this to see if it helps:

T3Knical5urg3 · 2022-02-10T23:02:01.048Z

Yes server subnet 10.13.37.0/24, client subnet 10.13.38.0/24.

Thanks for the video. Unfortunately it seems like GL.Inet treats wireguard very differently. Going to /etc/config/network there is not the same WG configurations present. I am not sure how it deals with WG. It is the same thing with interfaces. I don’t see a typical WG interface like is on my openwrt server side.

Edit: Maybe this information will help? I have a little raspberry pi on the client GL.Inet network (10.13.38.0/24) for testing purposes and I just found that I can ping and ssh into the Pi but I still can’t access/ping the gateway itself… So is there something in the firewall blocking it to the router but not to other ips on the subnet?

wcs2228 · 2022-02-11T01:07:44.493Z

If you can access the Raspberry Pi on the client side from the server side, then the tunnel appears to be working.

I asked about being able to access the Admin portal and being able to SSH from the server side because the problem may be there is no NAT Loopback on the client’s LAN. I think there is a way to fix this involving iptables, but I am not an expert on how to do that.

Can you do a test by sharing a USB drive on the Raspberry Pi? If you can access it from the server side, then it is probably due to no NAT Loopback.

T3Knical5urg3 · 2022-02-11T01:55:25.790Z

Yes, I was able to create a samba share on the pi and access it from the other subnet. Thanks for the ideas! I will start looking that up. I am not sure why I would manually have to do this, it seems like most people do this without the ‘fuss’.