5 Oct
2016
5 Oct
'16
4:13 a.m.
So in my opinion the best approach would be to send
only traffic with 44
origin and 44 destination not in other routes via ampr-gw, to preserve
your original 44 IP.
All the rest should be NAT-ed to your public gateway IP, not your
gateway's 44 net, in order to circumvent the whole 44net completely.
This will give you better speed, better response times and will ease the
work of the ampr gateway.
I agree that there are situations where you better NAT the traffic than send
it via amprgw. E.g. you are running Windows or Linux systems on 44-net addresses
and you want to fetch operating system- or virus signature updates from an internet
source, and you do not want to needlessly load amprgw with that traffic.
(over here that does not really matter, we have our own gw and it can easily
handle that load for the subnet of users that are in 44.137.0.0/16)
Unfortunately, there are also situations where that NAT is really undesirable.
The best example is Echolink. It simply will not work correctly when your system
partly communicates directly (to other 44net systems) and partly uses NAT to
communicate to internet systems.
Of course it is also possible to use advanced techniques like the packet- and
connection marking that you already mentioned to run a mix between direct and NAT.
For a while I had a connection mark in the gateway that was set for certain
host/port combinations and forced the use of srcnat in the POSTROUTING table.
This was an attempt to work around issues like Echolink and also reachability
of a system that is also running partly with NAT. I have dropped it some time
ago as it was not easy to maintain it.
Rob