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.
  • Please show pictures of the 'IPsec Connection', 'Remote Gateway' and the 'Site-to-site VPN tunnel status'.  Please give an example of what you want to route - I bet you just need a static route, depending on what we see in the pictures.

    Cheers - Bob
  • Bob,
     
    my settings:

      


    KabelDeut=WAN Interface
    imperial_Gateway=10.118.1.85/32 (transfer net)

    My LAN clients are on 10.10.50.0/24

    I want to be able to send packets from my LAN via above mentioned remote gateway of the remote transfer net to a network that is on 170.56.224.0.


    Did that help?

    thank you
    tekuton
  • According to the status display, 10.118.1.85/32 on one side is in the subnet of 10.118.1.0/24 which is the LAN on the other side - that can't work and will cause the routing problem you are seeing.  Your IPsec Connection definition should have "Internal (Network)" in 'Local networks' (I assume that's 10.10.50.0/24).

    I want to be able to send packets from my LAN via above mentioned remote gateway of the remote transfer net to a network that is on 170.56.224.0.


    I'm still a bit confused, so this is a guess...  If 10.118.1.85 is the gateway on the remote site, then a 'Gateway route' '170.56.224.0/24 -> 10.118.1.85' should work once you've fixed your VPN definition.

    Does that do it?

    Cheers - Bob
  • Bob,

    "Your IPsec Connection definition should have "Internal (Network)" in 'Local networks' (I assume that's 10.10.50.0/24)."

    In theory that is what one has to do, but...

    I will try and clear up the mud:
    I was given the 10.118.1.85 which i am supposed to put somewhere/somehow on my astaro - this is how my side is supposed to authenticate for the S2S connection. On the remote side is the gateway 10.118.1.251 which then would route to 170.56.224.0 once my packets would arrive.

    So, my prob is that my clients on 10.10.50.0 send their packets to my astaro and then what? Do i have to SNAT? Where do i put the given foreign IP?

    Hope that helps.
    thx
    tekuton
  • OK, so the 'Gateway route' is '170.56.224.0/24 -> 10.118.1.251' and the IPsec Connection is as described in my previous post.

    I can't see any use for the .1.85 IP unless it were the IP of another device that was your gateway for 170.56.224.0/24 over there.  Are you sure you don't have their internal default gateway (the internal IP of their device) confused with the gateway you're supposed to use to reach the 170. subnet?

    Cheers - Bob
    PS I don't know why they're making you jump through hoops; I may be wrong, but it seems like they could just include 170.56.224.0/24 as a local network they're offering you in addition to 10.118.1.0/24. But, that assumes that the public subnet is connected to an interface on their VPN device.  If it isn't, that would be the reason for needing a gateway route.
  • The thing is:
    when i put my internal network in IPSec Connection under "Local Networks" the IPSec connection breaks. 

    When I put my given IP in their I have a connection. 

    Then comes the routing prob.
    He also said that others add masquerading, so i tried to SNAT my LAN. 

    It looks complicated but makes sense when you have to deal with 60 tunnels and you get overlapping private address ranges which you cannot connect, so he hands out individual IPs to connecting remote endpoints from what he calls and controls "transfer net".

    thx
    tekuton
  • 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 ?
  • ö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
  • if your clients have to directly contact the 170.56.24 ips, then you should just be able to add this network in the "remote networks" of the "remote gateway" definition. then no further static routes are needed. 

    Also, you have to SNAT your outgoing packests behind your ip 10.118.1.85.
  • I tried that but with no success. I will post screenshots later.

    thx
    tekuton