Reverse SSH tunnel to bypass double NAT

trentmu · August 8, 2020, 9:19am

I have posted previous related queries on this device/setup, and have received amazing assistance from the forum on those topics. Those items have each been individually sorted out, and this is the next stage.
I would like to just check if I'm headed (conceptually) in the right direction.

I have a double NAT'd USB LTE stick in an rpi3 device as WAN. I am told that rain(ISP) does not assign IP addresses to client devices (I don't know how anything works this way, but that's a discussion for elsewhere I guess) so "port forwarding is not possible". I do, however, need to get into the LAN from WAN side. The basic layout looks something like this (sorry the pic is created in dia, so the pics etc are kinda old)...

#Description:____________________________________________________________________
Site A: I currently have 2 OpenWRT pi's

gw1 (192.168.1.1/25)- via DSL (LAN to eth0 and WAN via USB eth)
1. reachable on various levels via port forwards
2. also via wireguard VPN (site-2-site 192.168.1.0/25 <- -> 192.168.1.128/25)
3. ssh port 2201 is open on firewall
gw2 (192.168.1.2/25) - via 4G/LTE usb modem huawei e3772h-320 (I have tried several possibilities to get past the double-NAT but this particular model does not allow usbmode adjustments, so it is in RNDIS mode and working fine except for the WAN inward access).
1. ssh port 2202 is open on firewall
2. I have not yet configured the WG here
  
  I have set up different routes on the LAN machines to use the speed of the 4G line if possible

gw1 for everything
vs
gw2 for WAN traffic and gw1 for WG/LAN traffic

#Description:____________________________________________________________________
Site B: Here there is just 1 OpenWRT x86_64 PC

gw3 (192.168.1.254/25) - via Fibre (LAN to eth0 and WAN via eth1)
1. reachable on various levels via port forwards
2. also via wireguard VPN (site-2-site 192.168.1.0/25 <- -> 192.168.1.128/25)
3. this side I have 1 fixed IP
4. ssh port 2203 is open on firewall

The above works OK in general, but, for example, when I try to sync my NextCloud to the instance on Site A, it can't be found (from outside/site B). If I initiate a connection from NextCloud to a device on the site A LAN (which has the fixed IP gw3), then the sync kicks in, but (for reasons unknown to me) by default it is not activate.
In addition, the speed on the DSL connection is very poor, so even if it was working, it is too slow.

I want to be able to access
• everything on site A from site B via the 4G link.
• some things on site A from WAN side (also via 4G link).

I plan to try tunnels to achieve this, but I am not quite sure at which level I should do so (PC-PC, LAN-LAN,gw-gw?).

I have looked at this post - and the concept seems to be viable. If anyone can advise me which of these is best/correct (if any)...

should I create
1. A tunnel into which the WG is channelled
for example, if I am using WG, with the listener on eg. port 3456

an outgoing tunnel site A -> site B for WG
- on the OpenWRT(siteA:gw2) -> OpenWRT(siteB:gw3)
  - ssh -R 3456:openwrtGW3-siteB.fixed.ip:3456 root@openwrt.fixed.ip -p 2203
- on the OpenWRT(siteB:gw3)
  - endpoint for WG is then 127.0.0.1:3456 ?
- Then use WG for the site-2-site (open 3456 on firewall rules), something like...

2. A tunnel per PortForward
or will it be better to create 1x “-R” tunnel per required port forward from Site A (to Site B)?
for example...

if NextCloud is on say 192.168.1.130/25 port 443
- ssh -R 13443:openwrtGW3-siteB.fixed.ip:443 root@openwrt.fixed.ip -p 2203
- accessed via https://openwrtGW3-siteA.fixed.ip:13443 ?? with a port forward from “this device/WAN”:13443 -> 192.168.1.130:443

3. A tunnel per Host/Server
or would I need to create the outgoing tunnel for/at the actual host/server station?

NextCloud machine (which is on say 192.168.1.130/25) creates a tunnel to external gw3,
- ssh -R 13443:openwrtGW3-siteB.fixed.ip:443 root@openwrt.fixed.ip -p 2203
- LAN stations on site B would access this via https://openwrtGW3-siteA.LAN.ip:13443 ??

Not sure if the explanations and theories are clear, but I will try to offer some 1-liners below...
To allow #2 to reach #1, is the tunnel created...

#1 -> #2 (and then #2 connecting via localhost)
#1 -> gw3 (with #2 connecting via gw3 with a port forward)
gw2 -> gw3 (with a port forwards on both gw2/gw3)
some other config that is above my pay grade?

Last part...

WG uses UDP, while SSH is TCP. Would this have any affect in terms of tunneling UDP within TCP?
- Would it be advisable to use MoSH instead of SSH (since it is UDP), and is there any increased risk (in terms of UDP openings at the firewall) this way?

vgaetera · August 8, 2020, 9:48am

Using reverse SSH does not sound wise when you already have a VPN.
Set up a site-to-site VPN connection.
Connect to the VPN server and use SSH or any other protocol directly.

trentmu · August 8, 2020, 9:50am

Sorry - part of my explanation is missing...
I am hoping to toss the DSL portion in favour of the 4G (much faster in both directions), but the "price" of that is that I'd lose the site-2-site wgVPN because of the "inaccessible" IP

vgaetera · August 8, 2020, 11:13am

You don't really need public IPs on both peers for using site-to-site.
At least one of your peers should have a public IP.
That one assumes the role of the VPN server.
Then you route the other peer's subnets via the server.

trentmu · August 9, 2020, 9:17am

I apologise for my ignorance...

How does one set up WG's peer without knowing the remote address?
Is there an example I can look at?

vgaetera · August 9, 2020, 9:33am

Omit the peer's endpoint_host and endpoint_port.

WireGuard server + client + site-to-site.

trentmu · August 10, 2020, 12:49pm

Thank you Vlad for the info. I have copied the 3 setups as you recommended almost identically,

WireGuard server + client + site-to-site

changing only this on the server/main

WG_PORT="51820" to WG_PORT="36002"

and this on the client/peer

WG_SERV="SERVER_NAME_OR_IP_ADDRESS" to WG_SERV="openwrt.mydomain.xxx"
WG_PORT="51820" to WG_PORT="36002"

Anyway, both wg's start up perfectly - but there is not handshake between them. I tried
ping 192.168.9.1/2 from each side (I still have access to the remote LAN via the old DSL connection) but I get this...

root@openwrt4g:~# ping 192.168.9.1
PING 192.168.9.1 (192.168.9.1): 56 data bytes
--- 192.168.9.1 ping statistics ---
XX packets transmitted, 0 packets received, 100% packet loss

Similarly on the other side

--- 192.168.9.2 ping statistics ---
XX packets transmitted, 0 packets received, 100% packet loss

The 4G device shows

root@openwrt4g:~# wg
interface: wg0
  public key: o8ny9YIUzQ1gJsQfdKBGgi1xen7Aduwaa4AXP7q2Vm8=
  private key: (hidden)
  listening port: 41431

peer: 7IpvchLobLLI2C/ieJNJRArj/4FtTKkwuwy8mu8B9DM=
  preshared key: (hidden)
  endpoint: aaa.aaa.aaa.aaa:36002
  allowed ips: 0.0.0.0/1, 128.0.0.0/1, ::/0
  transfer: 0 B received, 9.54 KiB sent
  persistent keepalive: every 25 seconds

while the server shows

root@openwrt:~# wg
interface: wg0
  public key: 7IpvchLobLLI2C/ieJNJRArj/4FtTKkwuwy8mu8B9DM=
  private key: (hidden)
  listening port: 36002

peer: o8ny9YIUzQ1gJsQfdKBGgi1xen7Aduwaa4AXP7q2Vm8=
  preshared key: (hidden)
  endpoint: bbb.bbb.bbb.bbb:13044
  allowed ips: 192.168.9.2/32, fdf1:7610:d152:3a9c::2/128
  transfer: 24.57 KiB received, 15.27 KiB sent

I noticed that the listening ports don't match, and tried to manually set those, but it made no difference. They seem to recognise each other, but aren't talking?

The "server" machine shows sent AND received
The "client/peer" shows ONLY sent (0 received)

Is there an obvious error? or could this be the modem's DoubleNAT that is restricting things?

logreads look like so...

root@openwrt4g:~# logread -e ${WG_IF}; netstat -l -n -p | grep -e ${WG_PORT}
Mon Aug 10 14:24:16 2020 daemon.notice netifd: Interface 'wg0' is setting up now
Mon Aug 10 14:24:21 2020 daemon.notice netifd: wg0 (654): Try again: `openwrt.mydomain.xxx:36002'. Trying again in 1.00 seconds...
Mon Aug 10 14:24:27 2020 daemon.notice netifd: wg0 (654): Try again: `openwrt.mydomain.xxx:36002'. Trying again in 1.20 seconds...
Mon Aug 10 14:24:34 2020 daemon.notice netifd: wg0 (654): Try again: `openwrt.mydomain.xxx:36002'. Trying again in 1.44 seconds...
Mon Aug 10 14:24:40 2020 daemon.notice netifd: wg0 (654): Try again: `openwrt.mydomain.xxx:36002'. Trying again in 1.73 seconds...
Mon Aug 10 14:27:38 2020 daemon.notice netifd: Interface 'wg0' is now up
Mon Aug 10 14:27:38 2020 daemon.notice netifd: Network device 'wg0' link is up
Mon Aug 10 14:27:38 2020 user.notice firewall: Reloading firewall due to ifup of wg0 (wg0)

#and
root@openwrt:~# logread -e ${WG_IF}; netstat -l -n -p | grep -e ${WG_PORT}
Mon Aug 10 14:19:09 2020 daemon.notice netifd: Network device 'wg0' link is down
Mon Aug 10 14:19:09 2020 daemon.notice netifd: Interface 'wg0' is now down
Mon Aug 10 14:19:09 2020 daemon.notice netifd: Interface 'wg0' is setting up now
Mon Aug 10 14:19:09 2020 daemon.notice netifd: Interface 'wg0' is now up
Mon Aug 10 14:19:09 2020 daemon.notice netifd: Network device 'wg0' link is up
Mon Aug 10 14:19:09 2020 user.notice firewall: Reloading firewall due to ifup of wg0 (wg0)
udp        0      0 0.0.0.0:36002           0.0.0.0:*                           -
udp        0      0 :::36002                :::*                                -

Notably?? there is no listener showing on the 4G device

vgaetera · August 10, 2020, 1:20pm

There is, it's just the client port is dynamic.
I modified the regexp to match the client as well.

It shouldn't be, as it works for me in a VM behind 3 NATs:

NAT by the ISP;
NAT on the main router;
NAT by libvirt.

Verify that you can reach the server:

# Server
opkg update
opkg install tcpdump
tcpdump -i any udp port 36002

# Client
ifup wg0

Also, apply this workaround on the client if your server IP is dynamic:
https://openwrt.org/docs/guide-user/services/vpn/wireguard/extras#dynamic_address

In addition, there are several threads on the forum where it was required to lower the default MTU for WG to work properly.

mk24 · August 10, 2020, 1:23pm

gw2 will initiate the Wireguard connection to gw3. This means that gw2 needs to know the public IP of gw3. If the fiber ISP has it set with a static IP you can access it by number, which the ISP will not change since it is static. But typically this is done with DDNS.

Since it is an outgoing connection from gw2 it will work through the CG-NAT and incoming connection blocking of the 4G ISP. The IP of gw2 need not be known to gw3. So gw3 is set up as a generic listen for any connection.

At Site A you could connect the 4G and the DSL to the same router and use mwan3 to set up failover / load balancing between the two ISPs. Then as far as LAN stuff is concerned it is all one site.

trentmu · August 10, 2020, 2:21pm

A very big thanks to everyone here for the help and patience.
It turns out the problem was me being a dumbass - I didn't have the right PSK on the client/peer machine. As soon as I corrected that, everything worked perfectly.

trentmu · August 10, 2020, 4:41pm

Sorry... seems I broke something here again. Although I can see the remote LAN machines, and they can see me on the LAN, it seems their WAN access is failing.
ie. ping 8.8.8.8 from any of them doesn't work.

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Port Unreachable
From 192.168.1.2 icmp_seq=2 Destination Port Unreachable
From 192.168.1.2 icmp_seq=3 Destination Port Unreachable

Their default gw is the 4G-RPi, which is correct.

Also - thanks mk24

They are unfortunately not on same device - the DSL is inside, and the 4G has to be outside - dismal signal indoors

vgaetera · August 10, 2020, 4:47pm

Verify the default gateway for 4G-RPi is the ISP.

Perhaps you missed the step in the site-to-site how-to before adding the server subnet on he client:

uci -q delete network.wgserver.allowed_ips

So, only the WG subnet and the other peer's subnet should be routed to the VPN tunnel.

trentmu · August 10, 2020, 5:00pm

It shows this - which I think is correct (this is the 4G USB modem internal addr)

root@openwrt4g:~# ip r
default via 192.168.8.1 dev eth1 proto static src 192.168.8.124

I ran/re-ran this

uci -q delete network.wgserver.allowed_ips
uci add_list network.wgserver.allowed_ips="192.168.1.128/25"
uci add_list network.wgserver.allowed_ips="192.168.9.1/32"
uci commit network
/etc/init.d/network restart

Alas - no change

vgaetera · August 10, 2020, 5:05pm

Post the runtime configuration:

# 4G-RPi
ip a; ip r; ip ru; iptables-save

trentmu · August 10, 2020, 5:09pm

root@openwrt4g:~# ip a; ip r; ip ru; iptables-save
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.124/24 brd 192.168.8.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:10ff:fe1f:0/64 scope link 
       valid_lft forever preferred_lft forever
14: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/25 brd 192.168.1.127 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd76:2264:e2c4::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:feab:86a1/64 scope link 
       valid_lft forever preferred_lft forever
15: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 192.168.9.2/24 brd 192.168.9.255 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fdf1:7610:d152:3a9c::2/64 scope global 
       valid_lft forever preferred_lft forever
default via 192.168.8.1 dev eth1 proto static src 192.168.8.124 
openwrt.mydomain.xxx via 192.168.8.1 dev eth1 proto static 
192.168.1.0/25 dev br-lan proto kernel scope link src 192.168.1.2 
192.168.1.128/25 dev wg0 proto static scope link 
192.168.8.0/24 dev eth1 proto kernel scope link src 192.168.8.124 
192.168.9.0/24 dev wg0 proto kernel scope link src 192.168.9.2 
192.168.9.1 dev wg0 proto static scope link 
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default 
# Generated by iptables-save v1.8.3 on Mon Aug 10 19:06:01 2020
*nat
:PREROUTING ACCEPT [1476:170699]
:INPUT ACCEPT [23:2043]
:OUTPUT ACCEPT [47:2994]
:POSTROUTING ACCEPT [189:9714]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -m comment --comment "!fw3: Custom prerouting rule chain" -j prerouting_rule
-A PREROUTING -i br-lan -m comment --comment "!fw3" -j zone_lan_prerouting
-A PREROUTING -i wg0 -m comment --comment "!fw3" -j zone_lan_prerouting
-A POSTROUTING -m comment --comment "!fw3: Custom postrouting rule chain" -j postrouting_rule
-A POSTROUTING -o br-lan -m comment --comment "!fw3" -j zone_lan_postrouting
-A POSTROUTING -o wg0 -m comment --comment "!fw3" -j zone_lan_postrouting
-A zone_lan_postrouting -m comment --comment "!fw3: Custom lan postrouting rule chain" -j postrouting_lan_rule
-A zone_lan_prerouting -m comment --comment "!fw3: Custom lan prerouting rule chain" -j prerouting_lan_rule
-A zone_wan_postrouting -m comment --comment "!fw3: Custom wan postrouting rule chain" -j postrouting_wan_rule
-A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE
-A zone_wan_prerouting -m comment --comment "!fw3: Custom wan prerouting rule chain" -j prerouting_wan_rule
COMMIT
# Completed on Mon Aug 10 19:06:01 2020
# Generated by iptables-save v1.8.3 on Mon Aug 10 19:06:01 2020
*mangle
:PREROUTING ACCEPT [88399:53433158]
:INPUT ACCEPT [50825:43073380]
:FORWARD ACCEPT [35127:9547956]
:OUTPUT ACCEPT [44211:11058101]
:POSTROUTING ACCEPT [65861:19664732]
COMMIT
# Completed on Mon Aug 10 19:06:01 2020
# Generated by iptables-save v1.8.3 on Mon Aug 10 19:06:01 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3:228]
:banIP - [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_dest_REJECT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "!fw3" -j syn_flood
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i wg0 -m comment --comment "!fw3" -j zone_lan_input
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i wg0 -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -m comment --comment "!fw3" -j reject
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o wg0 -m comment --comment "!fw3" -j zone_lan_output
-A banIP -o eth1 -m conntrack --ctstate NEW -m set --match-set whitelist dst -j RETURN
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set whitelist src -j RETURN
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set threat src -j DROP
-A banIP -o eth1 -m conntrack --ctstate NEW -m set --match-set threat dst -j REJECT --reject-with icmp-port-unreachable
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set debl src -j DROP
-A banIP -o eth1 -m conntrack --ctstate NEW -m set --match-set debl dst -j REJECT --reject-with icmp-port-unreachable
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set sslbl src -j DROP
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set myip src -j DROP
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set yoyo src -j DROP
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set drop src -j DROP
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set dshield src -j DROP
-A banIP -i eth1 -m conntrack --ctstate NEW -m set --match-set edrop src -j DROP
-A forwarding_lan_rule -j banIP
-A forwarding_wan_rule -j banIP
-A input_lan_rule -p udp -m udp --sport 67:68 --dport 67:68 -j RETURN
-A input_lan_rule -j banIP
-A input_wan_rule -p udp -m udp --sport 67:68 --dport 67:68 -j RETURN
-A input_wan_rule -j banIP
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
-A syn_flood -m comment --comment "!fw3" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_dest_ACCEPT -o wg0 -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_src_ACCEPT -i wg0 -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
COMMIT
# Completed on Mon Aug 10 19:06:01 2020

vgaetera · August 10, 2020, 5:16pm

Does it work if you stop the WG?

# 4G-RPi
ifdown wg0

Perhaps it is not related to WG.

trentmu · August 10, 2020, 5:21pm

No sir.

user@host:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.2 icmp_seq=1 Destination Port Unreachable
#vs
root@openwrt4g:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=45.604 ms

Just a question...is it relevant that it says port not reachable and not host unreachable?

vgaetera · August 10, 2020, 5:23pm

This is most likely a firewall related issue:

trentmu:

-A banIP -o eth1 -m conntrack --ctstate NEW -m set --match-set threat dst -j REJECT --reject-with icmp-port-unreachable
-A banIP -o eth1 -m conntrack --ctstate NEW -m set --match-set debl dst -j REJECT --reject-with icmp-port-unreachable

trentmu · August 10, 2020, 5:30pm

I temporarily disabled banIP, but still similar result

vgaetera · August 10, 2020, 5:39pm

Wait, your chain zone_wan_dest_ACCEPT is empty, this is not right.
Make sure to enable the LAN to WAN forwarding and restart the firewall service.
It should be similar to this:

# iptables-save | grep -e zone_wan_dest_ACCEPT
:zone_wan_dest_ACCEPT - [0:0]
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_wan_dest_ACCEPT -o eth0 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth0 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT