Yes, this is the AT&T device log, which is likely it's (disabled) firewall log. I commented above it might be an ingress exploit, but I don't understand how or what kind if it has source addresses of active devices on my private lan and public internet destination addresses. How did it even get to the AT&T router without it having its address as the destination?
I would have Wireshark proven it already if I owned a switch with port mirroring capability. I'm pretty sure I know what I'll find though.
Joined: 25 Dec 2020 Posts: 90 Location: Toronto - Canada
Posted: Fri Jan 06, 2023 2:36 Post subject:
ccbrianf wrote:
Yes, this is the AT&T device log, which is likely it's (disabled) firewall log. I commented above it might be an ingress exploit, but I don't understand how or what kind if it has source addresses of active devices on my private lan and public internet destination addresses. How did it even get to the AT&T router without it having its address as the destination?
I would have Wireshark proven it already if I owned a switch with port mirroring capability. I'm pretty sure I know what I'll find though.
It's easy to get the details once you connect to their site. As for the private IPs, I have seen it happen where they are real active ones, too. They actually detect it during the spoof somehow. But the firewall is doing it's job if it is dropping it.
Posted: Thu Jan 12, 2023 1:23 Post subject: Leaking confirmed!
I found what I expected.
I bought a TL-SG105E managed switch, set it up for port mirroring, and made a Wireshark capture. The source MAC is my ea8500 DD-WRT router and the destination MAC is my AT&T BGW210-700 gateway, with private LAN IPs as the source address and internet IPs as the destination:
192.168.2.X is the LAN on eth1. The Wireshark was done on the WAN coming out of eth0 with SPI firewall enabled for the gateway mode router. So far I've only found TCP ACK RST packets with sequence 1 with destination port 443 not having their source IP changed
I do not see a way in the GUI short of specific commands to change NAT on any specific interface other than oet1 or a VAP.
Thank you for the reply, but again, I see no mention of NAT or masquerade on the networking page outside oet1 for Wireguard which is not in use and not in this IP range (nothing on eth0, eth1, or br0).
If you believe this is set wrong, why do all other packets have the public Dd-wrt ea8500 router IP for the source address except these? I guess with respect to NAT/SPI there is no reason to change the source IP of a RST packet since it is killing the connection and won't return anything, but that violates what I presume masquerade should mean and what the AT&T gateway is expecting for single device IP passthrough mode so it seems right to complain.
I can try the command if you think it will matter, but to me it should be redundant or equivalent to the default in use.
You can enter this into the Firewall Script to enable NAT from all interfacing going out the WAN:
iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE
I tested both of the following commands individually in Save Firewall followed by a reboot with no change as expected:
Test 1. iptables -t nat -I POSTROUTING -o `nvram get wan_ifname` -j MASQUERADE
Test 2. iptables -t nat -A POSTROUTING -o `nvram get wan_ifname` -j MASQUERADE
which is I assume what you were recommending.
Joined: 25 Dec 2020 Posts: 90 Location: Toronto - Canada
Posted: Sun Jan 22, 2023 4:18 Post subject:
I still think it's something to do with port triggering causing that, but it's hard to say without it in front of me. Wish I could offer more suggestions, but maybe someone from DD-WRT support can help more now that they can see the table as well?
That, or how DD-WRT functions in gateway mode with another private IP on the WAN port.