To be more explicit, let's get a system with a tunnel, a WAN and a 44net
LAN.
Public Router IP is 1.2.3.4
Router AMPR is 44.128.0.1
LAN is 44.128.0.0/24, web server on 44.128.0.2
Now the routes are:
44.128.0.0/24 on LAN
default is via WAN
table 44 has default via amprgw
44.128.1.0/24 is via 2.3.4.5
Rules are:
Any to 44.0.0.0 via table 44
Now the use cases:
1. Connection from Internet comes via WAN, gets port forward to web
server, replies return via default, because it is not 44net. OK.
2. Connection comes from 44.128.1.2 via tunnel, port forward, reply
follows rule and goes via table 44 and back to sender. OK
3. Connection comes from internet to 44net address. Gets port forward.
But the source address is a public internet address, so the reply does
not follow the rule, goes back via table main and to the WAN.
Which is the failure mode described by Bent.
To go around it, we need connection tracking, incoming connections get a
connection mark in the prerouting chain, get dst-nated to the server.
The replies, due to conntrack will get the same connection mark. Now we
need to additional steps:
- replies with connection mark will get a routing mark.
- replies with routing mark will follow an additional rule like: marked
goes via table 44
This 2 step approach is needed because it is not possible to create
rules based on connection marks, only on routing marks.
I hope this clarifies things a little...
Marius, YO2LOJ
On 04.03.2019 03:25, Marius Petrescu wrote:
No, I mean connection and routing marks. It has
nothing to do with
protocol forwarding.
On 03.03.2019 23:04, Steve L via 44Net wrote:
> You mean protocol forwarding. Ipencap is protocol 4. If your ampr
> gateway is behind a traditional NAT router, you need to find a way to
> forward protocol 4 to it.
ps://mailman.ampr.org/mailman/listinfo/44net