Joined: 16 Nov 2015 Posts: 6435 Location: UK, London, just across the river..
Posted: Mon Sep 20, 2021 7:44 Post subject:
eibgrad wrote:
gavsiu wrote:
Code:
root@Router-Gateway:~# iptables -t mangle -A PREROUTING -i ! vlan2 -d $(nvram get wan_ipaddr) -j MARK --set-mark 0x80000000/0x80000000
Bad argument `vlan2'
Try `iptables -h' or 'iptables --help' for more information.
FYI. iptables no longer accepts placing the negation (!) after the option and before the argument. It must now be before the option.
Code:
root@Router-Gateway:~# iptables -t mangle -A PREROUTING ! -i vlan2 -d $(nvram get wan_ipaddr) -j MARK --set-mark 0x80000000/0x80000000
Note, I'm NOT commenting on the efficacy of the rule. Just pointing out the syntax error.
im sorry to high-jack the thread, but just wonder how this rule will be spelled correctly:
iptables -t mangle -I PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
is it going to be
iptables -t mangle -I PREROUTING -p tcp -m conntrack --ctstate NEW ! -m tcpmss --mss 536:65535 -j DROP _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55779 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
root@Router-Gateway:~# iptables -t mangle -A PREROUTING -i ! vlan2 -d $(nvram get wan_ipaddr) -j MARK --set-mark 0x80000000/0x80000000
Bad argument `vlan2'
Try `iptables -h' or 'iptables --help' for more information.
FYI. iptables no longer accepts placing the negation (!) after the option and before the argument. It must now be before the option.
Code:
root@Router-Gateway:~# iptables -t mangle -A PREROUTING ! -i vlan2 -d $(nvram get wan_ipaddr) -j MARK --set-mark 0x80000000/0x80000000
Note, I'm NOT commenting on the efficacy of the rule. Just pointing out the syntax error.
im sorry to high-jack the thread, but just wonder how this rule will be spelled correctly:
iptables -t mangle -I PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP
is it going to be
iptables -t mangle -I PREROUTING -p tcp -m conntrack --ctstate NEW ! -m tcpmss --mss 536:65535 -j DROP
Btw, the last line in the OP's dump of the POSTROUTING chain of the nat table *is* the NAT loopback, and shows hits (29 in fact).
Code:
Chain POSTROUTING (policy ACCEPT 43 packets, 2159 bytes)
num pkts bytes target prot opt in out source destination
1 4905 1085K SNAT all -- * vlan2 192.168.1.0/24 0.0.0.0/0 to:EXTERNAL.IP
2 4161 300K SNAT all -- * vlan2 0.0.0.0/0 0.0.0.0/0 to:EXTERNAL.IP
3 0 0 RETURN all -- * wl1.1 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
4 0 0 MASQUERADE all -- * wl1.1 0.0.0.0/0 0.0.0.0/0
5 0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
6 29 6564 MASQUERADE all -- * br0 192.168.1.0/24 192.168.1.0/24
All that NAT loopback does is force the replies from the target to be returned to the router (thanks to the MASQUERADE) rather than directly back to the client's LAN ip, thus given the router the opportunity to undo the DNAT that forced the reference of the external WAN ip over to the internal LAN ip of the target.
I have no idea why everyone is trying to configure NAT loopback alternatives. If it's not working, there must be some other issue, perhaps w/ that particular service being targeted.
I'm on build 47495 on an Asus RT-AC3200 and I'm seeing the same thing as OP - nat loopback seems completely disabled even though the 'filter wan nat redirection' box is off.
Honestly, I'm pretty far outside of my networking ability so what do I need to do to track this down? I've got this which appears to be correct by your previous comment:
Code:
Chain POSTROUTING (policy ACCEPT 673 packets, 51290 bytes)
pkts bytes target prot opt in out source destination
1 659 MASQUERADE all -- any tun1 anywhere anywhere
753 59802 SNAT all -- any vlan2 10.10.10.0/24 anywhere to:PUBLIC.IP
0 0 RETURN all -- any br0 anywhere anywhere PKTTYPE = broadcast
5 276 MASQUERADE all -- any br0 10.10.10.0/24 10.10.10.0/24
5 276 MASQUERADE all -- any br0 10.10.10.0/24 10.10.10.0/24
The above line is NAT loopback. And it *is* working since it shows hits (5).
FYI, I explain how NAT loopback actually works in the following link (it's specifically regarding tomato, but conceptually it's the same for all third-party firmware).
I have no doubt you're having problems. But based strictly on that rule, and the fact its being hit, tells me it's NOT NAT loopback itself that's the problem. Maybe the targeted device's firewall is specifically rejecting the router's LAN ip (10.10.10.1) for some reason. NAT loopback *assumes* that's not likely to happen. Or perhaps 10.10.10.1 is being routed elsewhere on the target device.
Thanks for that link, you taught me something new!
My problem is twofold: First, none of my exposed services are accessible from internal IPs if I use the domain name. For example I ssh to hostname:22, it works from outside but not inside. That I can fix with a dnsmasq 'address=' setup.
But my second problem is that plex is screwed up. I have a server @ 10.10.10.10:32400 and my client is 10.10.10.150. Even though I'm on the same network, I'm not able to directly connect to the plex server. I cannot put a hostname setting in to fix this because it appears that plex is using IPs.
Anyway, back to my problem, here are my DNAT/SNAT settings:
Chain PREROUTING (policy ACCEPT 21180 packets, 26M bytes)
pkts bytes target prot opt in out source destination
6 264 DNAT icmp -- any any anywhere EXTERNAL_IP to:10.10.10.1 (router)
12 676 DNAT tcp -- any any anywhere EXTERNAL_IP tcp dpt:ssh to:10.10.10.10:22
3 180 DNAT tcp -- any any anywhere EXTERNAL_IP tcp dpt:32400 to:10.10.10.10:32400
518 47816 TRIGGER all -- any any anywhere EXTERNAL_IP TRIGGER type:dnat match:0 relate:0
target prot opt in out source destination
753 59802 SNAT all -- any vlan2 10.10.10.0/24 anywhere to:EXTERNAL_IP
0 0 RETURN all -- any br0 anywhere anywhere PKTTYPE = broadcast
5 276 MASQUERADE all -- any br0 10.10.10.0/24 10.10.10.0/24
If I understand this correctly then that is all setup correctly. However, I cannot ssh from 10.10.10.150 --> 10.10.10.1 (router) but I can go directly to 10.10.10.10 (server).
Could it be that SFE is screwing this up? I've got it set to SFE = CTF and flow acceleration = CTF+FA. There's literally nothing else that I can find that might be the problem and like you said, there are hits to that rule even though it's not working correctly. I've read elsewhere that CTF can affect NAT though again that's beyond my skillset
I'm watching my pre- and post-routing rules to try to see exactly what's happening. When I try to access https://server-ip:32400, my DNAT rule and MASQ rule each increment but the SNAT doesn't. I get no response back, so something but be interfering with the SNAT side of things.
When I can handle a minute of downtime, I'm going to try various values values of SFE/flow acceleration and see if that's actually the cause.
I turned off CTF today and my port forwards/nat loopback started working without any other changes. Digging through the forums, I found that other folks have problems with port forwards even from the WAN side but mine only broke on the LAN. Very strange. I'll have to try all the other options and combinations to see if any of the accelerations work or not.
To make iptables work with bridged interfaces, I suspect you need to enable bridge interface support in iptables at DD-WRT compile time. In the meantime, you might consider using ebtables instead.
