To avoid asymmetric routing

Hi,

I have a scenario here

Branch has 1 JSeries & 1 SSG. JSeries is connected to 2MB leased line (IPVPN) & SSG is connected to ADSL (ADSL network & extranet to IPVPN).

Customer requested critical traffics to HQ using leased line & non-critical traffics via ADSL.

branch ---->LL

(IPVPN)

LL--HQ
|

> ADSL ---(DSL net - link to ipvpn)

Problem: returning path for non-critical traffic always go via IPVPN & back to branch's leased line because IPVPN has better preference than ADSL network & it cause asymmetric routing. We need to ensure that the ADSL traffics from branch to HQ will have the same path to go back to branch

Do u have the solutions ? & URL

Find more posts tagged with

SAVE $250 on Your Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Boot Camps

Comments

stuh84

Use more specific routes for traffic destined to not go via the leased line?

Aldur

You're trying to influence how the return traffic will flow, which is not the easiest thing to do. Is BGP in use here? BGP has many functions that'll allow you the flow of return traffic.

chongch01

Ya, not easy because the SP cloud always consider the IPVPN cloud instead of DSL cloud due to their local-pref set by SP. Hence returning traffic will always choose IPVPN. The lab is yet to ready & might consider using tunnel.

thanks

APA

Are you able to ensure the non-critical traffic that is using the extranet VPN via the SSG appears as a source address only reachable via the SSG VPN?

It doesn't sound like you have BGP in operation so that throws that out the window in this instance.

Tunneling could be your answer here but the tunnel endpoint will need to be before the HQ router, therefore encaps\deencaps will occur at this point only, therefore hiding the original src/dst address before routing through the VPN, also you would need to ensure that the tunnel endpoint is only reachable via the SSG VPN...then exposing the real src\dest address of the packet after it has passed through the IPVPN and been de-encapsulated on the SSG VPN.

Very hacky.... but it would work..... Actually routing traffic onto the tunnel could be interesting though.... you could run a routing protocol between the tunnel endpoints and ensure the destinations for non-critical traffic are reachable though it.... or perhaps you would need to policy route the non-critical interesting traffic through the tunnel.

APA

Aldur wrote: »

You're trying to influence how the return traffic will flow, which is not the easiest thing to do.

Ain't that the truth....

chongch01

problem resolved by enabling NAT at SSG