This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing Problem with multiple DSL using NAT-T

Hello,

I am having a bit of a problem with Routing between 2 astaros with 2 different DSL connection with 1 internal network.

My ASCII art is bad but heres basically how it looks.

1. SSH Client is using NAT-T with a predefined IP of 10.1.1.100
2. ASL 3.380 IP 10.1.1.150
3. ASL 3.2xx IP 10.1.1.254
4. Server IP 10.1.1.1 with 10.1.1.254 as standard Gateway

SSH Client  xDSL  ASL 3.380  10.1.1.0 Network (server is here)  ASL 3.2xx  xDSL

ok first the NAT-T/SSH Connection works great. The ESP tunnel is stable. From the client i can ping the internal interface of the ASL 3.380.

However I cant ping into the network.  I am assuming that:

a) my server cant locate the SSH Client at 10.1.1.100 because it is not connected to the actual network.

or

b) my server is sending the packets to the default gateway at 10.1.1.254, which would be the wrong ASL.

anyone have any ideas?


This thread was automatically locked due to age.
  • the only way i have found to solve this problem is to add a Host in the Definitions for my Virtual IP (NAT-T). in this case 10.1.1.100.

    then i had to set up a masquerading from my virtual host to the internal interface of the asl.

    then i could ping across the entire network.

    what or where exactly do a host on my internal network think that my NAT-T address is? apparently the host on the internal network was dropping my icmp reply in the network, but nobody was there to pick it up.

    so im going to try and set up a completely different IP network for the Roadwarriors and do a MASQ on the complete IPSec network to the internal interface of the asl.  this would save having to enter every IP manually..
  • works great. i set a virtual IP network 10.10.10.0/24 and do a MASQ to the internal interface of the asl3.380 10.1.1.150 and then i can reach all host on the 10.1.1.0 network.
  • another alternative, although not quite as transparent is to install a route on all the machines that need to talk to the 10.10.10.0 network to the gateway 10.1.1.150.

    anyway its working great, whichever way its configured.

    thx astaro, we can now impliment a company wide token based security policy