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

IPSec with Masquerading

Hi,

I am trying to resolve a routing problem I have with my ASL v7.504.
We try to route packets via a transfer net that the other side uses to interconnect all its customers to avoid LAN 2 LAN problems etc pp.
Our IPSec S2S-Tunnel works but I cannot get a packet over to the other side (dont know what VPN-Gateway he uses); we were given an IP from above mentioned transfer net but I havent got clue how to tell the Astaro to use it tp route packets from our LAN to their transfer net (the guy on the other side maintained he wouldnet see anything from us). 

Any ideas?
thx
tekuton


This thread was automatically locked due to age.
Parents
  • tekuton, you are right, you may not put you internel network definition in "local networks"  because the remote vpn gateway would not accept the IKE negotiation then.
    The fact the tunnel comes up is a good proof that ipsec network definitions on both sides are fine.

    You have to hide your internal net. Normally you would do this with masq nat, but as you cannot select ipsec tunnel interfaces in ther masq nat configuration, you have to use SNAT.
    we have shown this in our last "tipss and tricks" webinar, you should be able to download it at
    Tips & Tricks for Customers - Volume 2


    Some of the things mentioned above are unclear/inconsistent for me [e.g. you mention in one place "imperial_Gateway=10.118.1.85/32", but later on you say "On the remote side is the gateway 10.118.1.251"], so just to clarify MY ASSUMPTION IS:
    your asg ipsec ip shell be 10.118.1.85/32  (= network definition "imperial_somplex", correct?)
    your lan is network 10.10.50.0/24
    remote gw has ipsec ip 10.118.1.251
    remote network which you want to access is 170.56.224.0/24  but this network is not contained in the vpn remote network definition? Your clients will have to access the "real 170.56.224´s" servers adresses by talking to "virtual" addresses out of the 10.118.1 pool? do you have a "mapping list" like "real ip 170.56.224.5 has virtual ip 10.118.1.7, real ip 170.56.224.9 has virtual ip 10.118.1.99, and so ?)

    Is this correct ?
Reply
  • tekuton, you are right, you may not put you internel network definition in "local networks"  because the remote vpn gateway would not accept the IKE negotiation then.
    The fact the tunnel comes up is a good proof that ipsec network definitions on both sides are fine.

    You have to hide your internal net. Normally you would do this with masq nat, but as you cannot select ipsec tunnel interfaces in ther masq nat configuration, you have to use SNAT.
    we have shown this in our last "tipss and tricks" webinar, you should be able to download it at
    Tips & Tricks for Customers - Volume 2


    Some of the things mentioned above are unclear/inconsistent for me [e.g. you mention in one place "imperial_Gateway=10.118.1.85/32", but later on you say "On the remote side is the gateway 10.118.1.251"], so just to clarify MY ASSUMPTION IS:
    your asg ipsec ip shell be 10.118.1.85/32  (= network definition "imperial_somplex", correct?)
    your lan is network 10.10.50.0/24
    remote gw has ipsec ip 10.118.1.251
    remote network which you want to access is 170.56.224.0/24  but this network is not contained in the vpn remote network definition? Your clients will have to access the "real 170.56.224´s" servers adresses by talking to "virtual" addresses out of the 10.118.1 pool? do you have a "mapping list" like "real ip 170.56.224.5 has virtual ip 10.118.1.7, real ip 170.56.224.9 has virtual ip 10.118.1.99, and so ?)

    Is this correct ?
Children
  • ölm,



    You have to hide your internal net. Normally you would do this with masq nat, but as you cannot select ipsec tunnel interfaces in ther masq nat configuration, you have to use SNAT.
    we have shown this in our last "tipss and tricks" webinar, you should be able to download it at
    Tips & Tricks for Customers - Volume 2


    Will do. Thank you.


    Some of the things mentioned above are unclear/inconsistent for me [e.g. you mention in one place "imperial_Gateway=10.118.1.85/32", but later on you say "On the remote side is the gateway 10.118.1.251"], so just to clarify MY ASSUMPTION IS:
    your asg ipsec ip shell be 10.118.1.85/32  (= network definition "imperial_somplex", correct?)

    Correct.


    your lan is network 10.10.50.0/24

    Correct.

    remote gw has ipsec ip 10.118.1.251

    Its a remote GW on the transfer net which i am supposed to be able to ping if my packets would find their way, correct.

    remote network which you want to access is 170.56.224.0/24  but this network is not contained in the vpn remote network definition?

    Correct.

    Your clients will have to access the "real 170.56.224´s" servers adresses by talking to

    My clients packets will have to pass via 10.118.1.85 which is supposed on my astaro and is therefore a part of 10.118.1.0/24. The 10.118.1.251 is somewhere on that transfer net. What happens over there I dont know, and it is not under my control.

     "virtual" addresses out of the 10.118.1 pool? do you have a "mapping list" like "real ip 170.56.224.5 has virtual ip 10.118.1.7, real ip 170.56.224.9 has virtual ip 10.118.1.99, and so ?)


    I have no mapping list, as i have no idea of what is going on the remote net. I do not even know for sure if 10.118.1.251 routes to 170.56.24 - that could be any IP. As i said above, if my packets got through i should be able to ping this machine.

    I really would to like to solve this prob since I am pretty sure I will see this kind of setup again.[:$]

    thx
    tekuton