Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 2656 views
  • Users 0 members are here
Options
Suggested
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

VPN Routing to Gateway, not tunnel!

gssincla
I've setup an IPSec vpn tunnel between my office and my house. I've successfully created the tunnel and can pass traffic between my local home network and my office network. My office is part of a bigger network and once I try to extend beyond this, my packets get lost.

After some investigation I found the problem is not my home site, but my office ASL. Here's my set up...

Home: ASL 5.011 - 192.168.x.x/24 network 
|
tunnel
|
Work : ASL 4.017 - 10.0.12.0/24 network
|
ROUTER to other 10.0.0.x networks

What seems to be going on is that work ASL is trying to route packets it recieves for my network (192...) to the default gateway instead of the tunnel. I've looked through the boards here and I can't seem to find any answer.

Can someone please help! 

thanks!

greg.


This thread was automatically locked due to age.
Parents
  • 0
    Is that Astaro the default gateway for your office network?  Are there only 2 interfaces on the Astaro?

    I can't really tell from your description if the traffic that should be sent to your home is getting back to the Astaro that terminates the VPN tunnel.

    If it is a routing issue (that is what it sounds like to me) you should be able to perform a NAT so that your home network will look like a 10.0.12.x address to the office network.  Then you won't need to change the routing of your office network.
  • 0 in reply to Moby
    The box has four interfaces on it, one external, one internal and two DMZ. 

    Well, I was trying to get it set up so that I could access the home network directly using the 192.xxxx subnet. To do this, I set up the routing table at my company to send all 192... traffic to the ASL internal interface. Doing a traceroute i see that everything proceeds as planned toward the ASL and actually enters the internal interface of the ASL as planned. At that point, it is shot out the external interface and becomes lost in the internet never to be seen or heard from again. 

     I checked and the address is not being changed or NAT'd along the way.

     Does this help at all? I'm insanely lost and its driving me insane!

    thanks for any help you gave give!

    greg.
  • 0 in reply to gssincla
     [ QUOTE ]
     Well, I was trying to get it set up so that I could access the home network directly using the 192.xxxx subnet. To do this, I set up the routing table at my company to send all 192... traffic to the ASL internal interface. 

    [/ QUOTE ] 

    Is the above a typo?  I'm wondering because your work Astaro should be pointing the 192.168.x.x traffic towards the Internet (external interface).  Then it should match the tunnel that is being terminated on the external interface and sent along properly.

    If you have a route configured for 192.168.x.x to go back out the internal interface, then you have just created a routing loop.  The internal network will pass the traffic to the Astaro, which will then try and send it back to the internal network.
  • 0 in reply to Moby
    nope, not a typo ... Its like this... At the company, any traffic destined for the 192 segments will be sent to the internal interface (the protected side) and the Internal interface in turn seems to be shipping it out the external interface directly, not through the tunnel. So if I'm on say subnet 10.0.2.0 then the traceroute looks like....

    10.0.2.111 (host) -> 10.0.2.1 (local router #1) -> 10.0.12.1 (corp network router) -> 10.0.12.5 (ASL) -> (at this point, i'm expecting tunneling traffic.. but instead...) External Interface (1.1.1.1) -> and packets die slowly on the internet.

    That make any sense?  [:S]

    thanks!!!!
Reply
  • 0 in reply to Moby
    nope, not a typo ... Its like this... At the company, any traffic destined for the 192 segments will be sent to the internal interface (the protected side) and the Internal interface in turn seems to be shipping it out the external interface directly, not through the tunnel. So if I'm on say subnet 10.0.2.0 then the traceroute looks like....

    10.0.2.111 (host) -> 10.0.2.1 (local router #1) -> 10.0.12.1 (corp network router) -> 10.0.12.5 (ASL) -> (at this point, i'm expecting tunneling traffic.. but instead...) External Interface (1.1.1.1) -> and packets die slowly on the internet.

    That make any sense?  [:S]

    thanks!!!!
Children
  • 0 in reply to gssincla
    Ok, now I understand.  I thought the route you were referring to was on the ASL, but that wasn't the case.  Its the route used in your internal network.

    More than likely the problem is associated with the local and remote subnets that are defined by the VPN tunnel.  You probably configured the home network to be the 192.168.x.x network and the office network to be 10.0.12.x network.  If I remember correctly, you stated that this traffic works properly.  If you want to talk to other networks in your corporate office you have 2 choices:

    1) Re-create your VPN tunnel so that it allows traffic from 192.168.x.x  10.0.0.0 /8 (the whole 10.x network).  You will have to reconfigure both sides.

    OR, if you don't want to add the entire 10 network to the tunnel,

    2) You can create multiple connections with the same local/remote endpoints, but different local/remote subnets.  For example:

    192.168.x  10.0.12.0/24
    192.168.x  10.0.2.0/24
    etc.

    If you've already done this, double check that there aren't any typos in the network definitions.  If the traffic doesn't match the local and remote subnets for a VPN tunnel, it will just follow the default path out to the Internet instead of taking the tunnel.
Cookie Information Banner