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?
1 Like
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'
How are you aceessing the usb storage? FTP? http? Samba?
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.
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?
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.
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.
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.
Are the client and server sides on different subnets? You can try this to see if it helps:
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?
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.
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’.