Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Andrew Pullin]

On 1/31/2020 4:48 PM, Sylvain Rochet wrote:
> > Or how host3/C could be configured for routing a subnet (now
> > 11.0.0.0/32) that is essentially "private" between host2/B and
> > host1/A. That is the "192.168.0.0/24 via 172.16.1.1" route in your
> > example, or "11.0.0.0/32 via 10.0.0.016" in my case.
> >
> > It seems like what I actually do want is NAT capability on host2, so
> > that the host1<->host2 connection would be abstracted away. But it
> > looks like there are only a few few-years-old implementations of NAT
> > for lwip. Uh oh. I would really like to avoid trying to integrate that
> > in from an old branch of lwip.
> >
> > Any idea if I can get this to work without needing to try to bring up
> > NAT?
> It it were me and if I don't need Host2 to reach "outside" and Host1
> software can't be changed, I would just write a big hack to forward
> relevant packets (e.g. no DHCP, no ARP, IP) to the PPP link, pushing the
> DHCP assigned address to the PPP peer Host1 so NAT is not necessary at
> all and nothing have to be done for Host1 to send packets to "outside".
>
> And if it were me and if I need Host2 to reach "outside" and Host1
> software can't be changed, I would write a quick'n'dirty ARP Proxy
> support, probably at the Ethernet low level driver. Note, in this case,
> it is normal for the PPP link to be within the Host2/Host3 subnet, it is
> actually mandatory. But doing so won't work if you need DHCP support
> because you need DHCP server to offer two addresses (one for Host2, one
> for Host1), so you need two MAC addresses and two DHCP clients running.
> It's way more difficult than just hacking the forwarding and sharing the
> same address.
>
> But, above all, if it were me, I would just write a TCP or UDP proxy on
> Host2. Host1 would then only establish TCP or UDP sessions to Host2 with
> a home made proxy protocol (basically packets with two destination IP
> fields), and Host2 would create the real session to the outside world.
>
> Host1 ----------------- Host2 ------------ Host3 ------ Internet
> 192.168.0.1   192.168.0.2   10.0.200.113               192.0.2.1
> <---TCP1---------------->   <---TCP2--------------------------->
>
> TCP1:
> src: 192.168.0.1
> dst: 192.168.0.2
> real-dst: 192.0.2.1 (in TCP payload, e.g. at the
>                       beginning of the TCP session)
>
> TCP2 (created on the fly using payload hidden real-dst):
> src: 10.0.200.113
> dst: 192.0.2.1

Wow, thanks for all the good ideas.
I can mostly change the code on both Host1 and Host2 here, but I am 
really trying to do this with minimal changes to the upper layers, 
especially on Host1. As described: end up with a transparently "working" 
internet connection there.

The ARP proxy case is fascinating. Since Host1 used to be a fully 
internet connected device, it has everything it would need, i.e. a DHCP 
client, DNS client, etc. If I could make Host2 appear to represent two 
devices with two valid (IEEE registered) MAC addresses and the network 
operator was OK with two DHCP clients existing in one physical box, that 
seems like a good solution.
But: modifying the low-level ethernet driver seem daunting.

The TCP proxy case also seems quite interesting, since it should be all 
app layer code, and only need a TCP listener and TCP client.
Alas, we also need UDP for DNS. For TCP, it would be easy enough to 
start the stream with the target IP:port and a verifier, but for UDP, 
the datragram would have to be dissected, deal with the IP 
pseudo-header, etc.

But here's the good news: I found a patch to add NAPT functionality to 
lwip, I am sure it has been linked to somewhere in this mailing list before:
https://gist.github.com/NeoCat/da3c141813980edaa256ad351cab3a2c

Seems pretty interesting, and it seems like it is almost working, too. 
This would be a great solution, since then I can run a private static IP 
subnet between Host1 <-> Host2, and to the upstream router, it should 
just look like a single device Host2 (other than NAT detection via TTL 
or other methods).

The part that I am stuck on presently is that Host2 has no knowledge of 
how to route packets from PPP out to the WAN, say, 8.8.8.8.
Between ip4_forward, IP_FORWARD, ip4_route_src, LWIP_HOOK_IP4_ROUTE, 
LWIP_HOOK_IP4_ROUTE_SRC, and the ESP32 port modifications, I am not 
quite sure where to make the right intervention. It is ... a lot to take in.

As far as I understand the standard usage of the stack for a single 
netif, outgoing packets elide the entire forwarding/routing system 
because they are specified to be transmitted on a particular netif? Is 
that right?

Fundamentally, I only have eth0 and pp1  (to use the lwip netif naming 
system) and anything not specifically with IP dest = eth0 or pp1 should 
be sent on towards Host2's gateway (after NAT source address IP rewriting).
Is that logically complete, and if so, where should it be implemented?

Thanks,
Andrew Pullin