> I infer that the kernel does not check the routing table when it selects
> an IP address as the source address.
>
> Try something like
>
> iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -d 172.17.0.0/16 -i
> eth1 -o eth0 -j SNAT --to-source 10.10.2.147
>
> If the address 10.10.2.147 is not sta
Hi Graham,
I believe Andreas is correct. I just tried this here with my own setup.
You can't depend on the MASQUERADE target if you want to source nat to
the gateway's virtual IP address. This is what the man page says about
MASQUERADE:
"Masquerading is equivalent to specifying a mapping to th
Hi Graham,
what if you NAT the clients behind Jupiter to Jupiter's virtual IP?
As far as I remember this should work.
Regards
Andreas
Graham Hudspith wrote:
>> the problem might be that although jupiter's satellites are NAT-ed to
> jupiter's eth0 address 192.168.50.159, jupiter itself uses the
>
> the problem might be that although jupiter's satellites are NAT-ed to
jupiter's eth0 address 192.168.50.159, jupiter itself uses the virtual
IP address 10.10.2.147 within the IPsec tunnel. I know
> from personal experience that NAT-ing clients behind a gateway
> to the gateway's outer IP addres
Hello Graham,
the problem might be that although jupiter's satellites are NAT-ed
to jupiter's eth0 address 192.168.50.159, jupiter itself uses the
virtual IP address 10.10.2.147 within the IPsec tunnel. I know
from personal experience that NAT-ing clients behind a gateway
to the gateway's outer IP
Hi,
I have a situation which I hope someone can please help me with.
I have a machine (called jupiter) on our lan. Using it's eth0 NIC (we're
talking linux, of course), jupiter can ping and connect to other machines
on the lan. One machine it can reach (called saturn) acts as a gateway to
a furth