Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1277 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

IPSEC Lan2Lan incoming over non-default gateway iface

Jochem Berends
Hi.

I have a problem with an incoming IPSEC connection from a secondairy ADSL line that is *NOT* the default gateway interface. Yes, there are two ADSL lines connected to the box and 1 is default gateway, the other is not and I included a policy route to correctly handing the returning IP packets from the astaro box entering from the internet over the secundary iface from that iface back over that ADSL line. Tested with a webadmin over this secundary incoming ADSL connection and tested with PPTP connection connecting on the internet IP of that secundary ADSL line and that seems to work fine.

BUT IPsec connection does not work if I connect it to the IP address of the secundary ADSL line. I changed the IPSec connection to have as local endpoint that interface.

The IPSec connection is brilliantly working when connecting to the IPaddress on of the primary ADSL connection, which is also the default gateway.

What kind of policy routings do I have to provide in order to get a good IPSEC connection on the secundary ADSL line.

See attachment for network diagram.


This thread was automatically locked due to age.
  • 0
    I have the same problem. We use a s-dsl and a a-dsl connection of t-systems. We want to use the s-dsl connection for the ipsec vpn and the a-dsl connection for the rest. When we use the a-dsl as the default gateway, the vpn does not work. If we change the default gateway to the s-dsl connection the ipsec vpn works fine.

    I hope that we can a solution here...

    kind regards

    Dirk
  • 0 in reply to Dirk2508
    I did something like this long ago on a V4.  Can't remember all the details but I simply did a static route over the secondary line/gw for the endpoint IP.  This required that *all* traffic from the far end hit the secondary IP but it worked.

    You might try a static route to get it working then try to figure out what is wrong with the policy routing setup.
  • 0 in reply to pablito
    I found that the best way to handle this is to use policy based routing... using this method, you are able to specifically route IPSec based traffic (Unlike a static route).  Of course you can adapt this method for other protocols on your secondary interface as well, but found it works great for IPSec.

    Try defining a policy route such as this:
    Source:  IP of Secondary External Int
    Service:  ISAKMP
    Destination:  ANY
    Target:  Gateway of Secondary External Int
    Source Interface:  ANY (IMPORTANT)

    Hope this helps.
    -merc
Cookie Information Banner