>
> 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 address will successfully route traffic
through the tunnel (at least with Linux kernels >= 2.1.16 which
> fixed a longstanding bug) but since the POSTROUTING -t nat chain is the
last hook in the path it will not heed the source routing rule defined
by table 220. Can you do without a virtual IP on jupiter?
>
Andreas,
Thanks for that swift reply.
I tried setting up the tunnel WITHOUT specifying the sourceip option
in the ipsec.conf.
The tunnel does come up, and the left side of the tunnel is assigned
jupiter's IP address.
However, if I send a ping from jupiter to one of saturn's satellites,
the pings go down the tunnel to the remote
security-gateway (saturn) and onwards to the far subnet (saturn's
satellites), BUT the reply seems to come from saturn back cleartext on the
LAN rather than through the tunnel.
The ping replies are not routed back to the originator on jupiter.
If I send a ping from one of jupiter's satellites to one of saturn's
satellites, this does now go down the tunnel. However, the results are
the same, in that the ping reply is sent cleartext from saturn on the
LAN rather than down the tunnel.
Any ideas what I can do to fix this (only allowed to alter jupiter,
sadly) ?
Regards,
Graham.
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
